CreateBox : per face color ?

[jerome]

Would you buy a per-face-color feature in CreateBox() like then per-face-UV one ?

 

something as easy as this for a red face 0 :

var faceCorlors = new array(6);faceColors[0] = new BABYLON.Color4(1,0,0,1);var box = BABYLON.Mesh.CreateBox('box', {faceColors : faceColors}, scene);

NOTE : this feature, like the other per-face ones are extracted from the SPS per-particle features.

NOTE2 : alpha support with color4 !

 

So : faceColor ? faceColors ? any other name ?

 

 

[GameMonetize]

I'm for faceColors

[Wingnut]

Don't boxes have 6 sides/12 faces?  *scratch scratch*

[jerome]

you are right ... I used the worf face,  but it's about the box sides here

everything is expressed from the user point of view : he looks at a box, he can see sides (or faces, whatever) but he doesn't know anything about how it is built in terms of triangles (webgl faces)

 

Should we change all the "face" to "side" ?  Or has "face" still the right meaning from the user POV ?

 

faceUV => sideUV

faceColors => sideColors

 

let me know please, I'll do it if it's more pertinent or less confusing

[Wingnut]

Well, J-man... can you still do colors per face?  12 colors per box?  Probably only in flat-shaded, eh?  hmm. 

 

In my opinion, if you are going to honor 12 colors on flat-shaded boxes, then...  what?  I dunno.    *scratch scratch*  It should be colorPerFace for flat-shaded, and colorPerSide for smooth-shaded.

 

I created a torus knot in your stomach, didn't I?  Just now, you thought about flat-shaded spheres and torus knots, eh?  Tubes and ribbons, too.  A couple hundred triangular faces are found on a medium-rez sphere, yes?  That's one hell of a faceColors array.

 

Are boxes... the only mesh we have... with "sides"?  Nope, grounds and planes, too. 

 

Does an 8-sided cylinder have 8 'sides'?  Or is "8-sided" just a poor way to refer-to 8 width-subdivs? 

(I use the width subdivs term... only to match its height subdivs term. Both could be changed, but we SHOULD do both... consistently, and as consistent with other basic shapes... as possible, imho.)   Let's look at cylinder...

//Creation of a cylinder//(name, height, diamTop, diamBottom, tessellation, [optional height subdivs], scene, updatable)

(from the docs)  Above, we are calling width subdivs ... 'tessellation'. 

 

And we're back to "diameter"... based upon circular things... when instead... we could use 'size'... maybe.  Maybe not.  Cylinders, just like spheres, will likely be size-settable on all three axes.  So, there's lots of potential settings. widthTop, widthBottom, height, depthTop, depthBottom, right?  erf.  And we haven't started talking about segments, yet.  Five settings... just for size.

 

Let's look at sphere...

//Creation of a sphere//(name of the sphere, segments, diameter, scene)

Do we want to give spheres... width subdivs and height subdivs someday/soon?  In other words, someday, can the horizontal subdivs and vertical subdivs (width/height subdivs)... be different values?   How about sphere size?  Maybe use the Oimo format...   size:[height, width, depth]?  Maybe NEVER use the word "diameter" in our parameter names?  Maybe always and only use width, height, and depth, or... size:[x, y, z]?

 

Sorry, I started subject-drifting into the other thread... the one that I killed by getting too meticulous (nit-pick-ulous) or something. 

[jerome]

aarff...

 

Well, it will be colors per ... huu.. whatever you want to name it and what I can do

I can give a color to a box side because each side is built with 2 triangle faces and they have all their own vertices (no shared vertices between sides), so if I give the same color to these 6 vertices, it will be the side color.

I guess the vertex color will then add (or mix in some way) with the material and textures, as they do in the SPS about the per particle color.

 

It is easy then for a user to have a box with different colors on each side, far more easy than dealing with multimaterial and submeshes, so why not to implement such a convinient feature ? (it is quite light to add in the existing code)

 

About the increasing number of options :  well, just remember that options are just  ... optional ! If you don't set them, the default behavior will be executed.

It's easier, imho, to pass an options parameter with just the needed values than to pass many mandatory parameters, even set to null.

 

So... you didn't answer my question : is it better to use the word "face" or "side" for a box ?

[jerome]

it seems that face, side or facet are the right english words : https://en.wikipedia.org/wiki/Cube

 

So let's keep face

[jerome]

PRed

[Wingnut]

You didn't answer my questions, either.  Until you determine if a 3-64 "sided" cylinder.... will have "sides" or "width-segments"... you can't determine a standardization of terms.  And you didn't talk about flat shaded... but that might not be an issue (I was mistaken thinking that we could do triangle-by-triangle colors with flat-shaded.  Flat-shading gets you separate 2-triangle colors, but not per-triangle coloring.)

 

If you want us to just pick between two names...  that's not tending to the issues that can affect the name picking.

 

Are you in some kind of race?  Are you in a hurry to lock something into place that will be a nightmare to change, later?

 

Please, make a html table that shows all the currently used parameter names according to our docs.  Let's see them all on the big screen so we can all cry more easily.    We can also start getting a game plan on the "big picture", too, and please stop trying to hammer things into place.  Let's do the investigation... the research, and see if we can get consistent and standardized.  Any chance?

 

This is also the reason why I asked HOW OFTEN parameter names... will match property names, and asked if we want to strive for matches, or avoid them.  Will we see .getWidthSegments() or .getHeightSegments() or .getDepthSegments() or .getSideColor() on abstractMesh someday?  We have to plan for these things, imho.

[JohnK]

For polyhedron the correct term for each of the polygons that make up the solid is a face. There is no agreed term for shapes made with any non polygons, eg cylinders. In terms of what you might call the parameters within an object to pass to a BJS function then provided the name is well explained any name could be chosen. For example

 

Suppose we make the following definition of 'surface' for BabylonJS at the viewing level (not the construction level)

 

Given a mesh that has a single material applied a surface is a region of the viewable mesh that could be painted without going over an edge. This is so that when for example we talk about a cylinder we know we are talking about as we would see it in real life not as constructed within BJS.

 

In this case a cylinder would have 3 surfaces and a sphere one surface.

 

could the idea be extended to

var surfaceColors = new array(3);surfaceColors[0] = new BABYLON.Color4(1,0,0,1);var cyl= BABYLON.Mesh.CreateCylinder('cyl', {surfaceColors : surfaceColors}, scene);

var surfaceColors = new array(1);surfaceColors[0] = new BABYLON.Color4(1,0,0,1);var sphere = BABYLON.Mesh.CreateSphere('spherebox', {surfaceColors : surfaceColors}, scene);

There is then an issue of which surface is which, ie is surface 0 the top, bottom or the curved one of a cylinder this could be overcome by a user with a little experimentation on the order of the array (or a list in a tutorial)

 

Is this going too far?

 

EDIT for consistency and because it is shorter faceColors rather than surfaceColors could be acceptable

[jerome]

@Wingy : I didn't know about cylinders or other mesh types (face name) just because I focused on the box only.

I can't, for now, guarantee this kind of feature (per face color) is transposable to any other mesh.

Actually it isn't : in order to give a color to a face (or surface), I need this surface to be constructed with its own exclusive vertices (because colors are assigned to vertices). If the vertices are common to many faces in the geometry, the feature won't be possible as is.

I guess it's feasable for a cylinder (top, bottom, rounded surface)... per surface, not per vertical segment or radial segment. I know it's not for a torus or a sphere for instance.

 

But you are right, we need to keep consistency.

Should we use JohnK's suggestion : surfaceColors ? Would it be still acceptable for a box ?

 

Since we are still in alpha release, I can change the parameter names if needed.

[Wingnut]

Ok, so, this is a special box.  It won't replace our standard BJS box, right?  Good.    You are adding power and features to box... that other mesh don't have, and can't have.  You are branching box away from "the template".  Future users will surely create a 3 or 4 side pyramid using a cylinder, and they might/will expect that color-per-side feature to be there, just like it was for the box they made last week.

 

We're right back to "the good ol' days", when Wingnut thought jMesh should be a different KIND of mesh than standard mesh, eh?  If you keep your experiments out of mainline production code... you can experiment your brains out... and do long-term plausibility testing... without screwing-up the "pattern for all basic shapes". 

 

You did this same thing with parametric shapes.  You branched... a good thing.  Similar to now, you thought about using parametrics to do ALL the BJS basic shapes... and it wasn't plausible.  Options objects are great... but overloaded options objects can seriously bastardize the constructor consistencies on vertexData.

 

In other words, if you put jBox into production code, then the box constructor on vertexData will be drastically different than the other basic shape constructors.  Colors/Textures-per-side in the construction phase... is very different.  IF you use a branch, and thus stay out-of-the-way of standard box constructing, you get full power.  Doing that, you can now have your .getSideColor() and .setSideColor(), with your jMesh object sub-classed to baseJMesh (similar to abstactMesh but contoured to Jerome stuff).

 

If you do that, you get freedom... and the BJS community avoids off-template, overloaded options objects... in mainline legacy production code.  And you can keep your docs on a jMesh branch, too... not adding a ton of features-talk to the "createBox" section of the basic shapes docs.

 

Jerome... instead of trying to find "a better way" (a replacement for the default createBox)... could you be happy with "a different way"?  If you stay out of mainline, you won't feel so handcuffed by gestapo folks like me wanting consistency with other shapes   You can sleep at night... knowing your "special box" is not required to follow ANY of the default behaviors of a standard box.  jBox doesn't guarantee ANYTHING.  Nor does jPyramid.  Now you CAN do jSphere and jCylinder... because you have put limits on the number of sides/subdivs...  limits that YOU can handle... and still do sideColorings.  You are allowed to do that... because you stayed clear of mainline shape constructors... just like you did with parametric shapes.  You'd become free.  Set your own parameter names... you are the boss... you make the call.

 

*shrug*  I dunno.  I'm not very educated in these matters... but it looks to me like you have some "I must make mainline things more powerful" and "I must hurry and get this into production" -issues. 

 

Move into your own building, and you won't need to graciously ask for naming suggestions/approvals from whiny people like me, and you won't be concerned with people like Deltakosh asking "Why do this?".  

 

We will still be watching. Your code will be included in the framework.  Your complaints/issues about jMesh will be deflect-able (it's alpha).  And... Deltakosh won't chew his fingernails to the bone worrying about the far-reaching ramifications (fallout) of having a Jerome-fortified box as the default box. 

 

The entire BJS framework will treat your custom mesh... as just that... a custom mesh... that started with a blank Babylon mesh.  Any jMesh handling that Deltakosh needs to do... he just sends it down the trail of a custom mesh... no special handling other than that.  He gains freedom, too.  He has no fallout worries... because HE doesn't guarantee anything or make any promises about jMesh, either. 

 

"If it is a jMesh, talk to Jerome". 

 

He has hand-washing abilities... dump the blame onto Jerome.    Party on!

[jerome]

Aarrff..

Wingy, are you a GOP member ? You seem so conservative ! (joke, of course !)

 

Well, I understand your warnings, but ...

I just want to make things easier than they are.

 

Let me explain : a box is a mesh, ok.

Like other meshes, it has the same global properties. I don't speak about JS properties, but about geometry properties here.

But it's also a box. It is to say a special shape different from a sphere, a plane or a torus. It has 6 different non-continuous sides (or faces).

Is this feature something minor ?

No, it's not ! When dealing with a box, many users come quickly to want a different color or texture per side... because it is rightly a box !

They don't ask this for a sphere, nor for a torus.

These 6 faces are the very essence of a box.

 

So now, how people can change their box face textures or colors ?

They have create a box, then to deal with submeshes and submaterials... just to have finally a red face and green other one, a child cube toy.

Is this simple (Simple & Powerful, remember) ? I don't guess so.

 

So if I can give to a given shape type the feature to do easlily what most people expect from this kind of mesh, even if it's dedicated to this mesh only, why not to do it ?

 

I'm waiting for DK to push the last release in the PG to show you how it is simple to use. I can guarantee you that the changes in the VertexData code were really light to achieve this and it still behaves as formerly if you don't use this new option.

[Wingnut]

Ok, if it's only for boxes (why don't I believe you will stop there)... then why are you in the mesh construction area?  Shouldn't you be working in materials?  Color is a material.  Why not code a sister material to cubeTexture, called cubeColor?  It even works for coloring the walls of skyboxes!   Cool! 

[jerome]

You are right : I will probably add some other shape dedicated features if they have a real interest for each concerned mesh type...probably in ribbons, although I think I will probably add the texture feature when it's pertinent to some other fixed shapes.

Don't you find the texture feature is really simple and useful ? far better than dealing with multimaterials and submeshes if we have a texture atlas ?

 

Please wait and see the PG examples as soon as it is pushed in the PG engine : you'll see it's really simple to set a texture or a color for a given face.

 

I didn't modify the materials, just the vertex colors. So it works well with materials also in the way the vertex colors combine with the material colors.

[JohnK]

Further thoughts about other shapes.

 

Sphere, Torus, Knot and the like

Not a problem since sphere.material, torus.material, knot.material will already cover them as is. These are not seen as having more than one surface.

 

The cone

Usually the flat surface is hidden so cone.material will cover the relevant part of the cone.

 

 

The Cylinder

I might want a can of soup in my game.

 

Could be quite good to use faceColors =[top, label, bottom]

 

Other Polyhedron

Not yet available so no need to worry.

 

Conclusion only box and cylinder need be done.

 

[Wingnut]

  Don't forget about double-sided planes and grounds.  We'll be wanting to play checkers and chess, right?  heh.  Good researching/thinking, John.  Thanks for coming on-board and pondering things with us.

 

I'm curious to see how all this will be done, without setting the mesh flat shaded  (24 vertices in a box, instead of 8).

 

But yeah, I see what Jerome is thinking.  Since Colorkind is part of vertexData... it doesn't need to use a standardMaterial.  It isn't part of materials, it is part of the mesh itself.  pickInfo.getPickedColor(), anyone? 

[jerome]

Yep, the texture per face, segment, ring... anything pertinent for the user from the shape of the mesh is quite feasable. And the atlas aspect is very useful imho.

 

Colors per-stuff are more difficult : the color is per vertex. If a vertex is common to many faces (webgl meaning), the face color will be then interpolated from each of its vertex color. So nothing easy as "just make this part red" for the final user.

 

So I won't do anything about colors on meshes where it's not easily understandable for the user... so on almost every other mesh than the box and the cylinder as John showed it.

 

I will probably do it on the ribbon however : it's a parametric mesh, no predefined shape, very basic and versatile.

The ribbon is a tool for programmatic guys and I think it is acceptable to give them the ability to deal with interpolated (or computed) colors.

[Wingnut]

I'm not feeling good about your use of "face", Jerome.  It's a foggy term.

 

I like segment better.  A segment... is always two triangular faces.  No angle change is possible... at a segment crossline.  (the line where two triangular faces meet)

 

hmm.  Jerome, let's pretend that YOU define "face" as a single triangle.  You cannot get per-face coloring, ever, right?  You can get per-segment coloring, correct?

 

There are 6 segments in a box.  Is it true... that you will need 3 normals at each corner of the box (flat shaded?)... to solid-color the sides of the box?

 

Sorry... but the wandering terminology definitions... are screwing me up a bit.  Thanks for clarifications.

[jerome]

I can change the name to whatever you, all english native people, think is better or more pertinent... before DK freezes everything for v2.2

 

If segment is more universal and still understandable by the users, let's go for segment .

Will this still have the same meaning if we talk about a box and then about a cylinder (top, bottom cap and rolled up surface) ? I don't know... My english is not that accurate to make such kind of choices 

I just can tell what the parameter will do : it gives a plain color to a part of the mesh easily identified by the user as an independent surface (something he could name in current language, because it becomes then a need for him : please color this segment/face/surface/side in green)

the different sides of a box, the caps or the roll of a cylinder

 

note : this parameter would certainly be re-used with the upcoming (2.3) polyhedrons

 

Just let me know the best term to use once you all agree 

[Wingnut]

Oh c'mon... you are jumping ship.  We still need YOUR opinion. 

 

I based my entire "opinion" ... upon the use of the word "segment"... seen in recent constructor options threads.  That's a pretty limp basis to take a stance-upon, eh?  I dunno. 

 

sigh.  Temechon!!  I need help (please!).  No, I really don't need help, I'm just lazy.  I need to search all of our docs... to see how often the term "face" is used to indicate a triangle-o-mesh.  (and also see how often it was used to indicate the "side" of a mesh)

 

Who was it that used "segment" over in that other thread?  Oh yeah... 'twas Kosh of Delta. ( http://www.html5gamedevs.com/topic/17044-evolution-for-out-of-the-box-meshes-creation/#entry95912 )

 

I'll go shake him real hard... and see how well the term "segment" is stuck to him. 

 

I think I'm going to stand firmly in the middle of the road.  I'm not qualified to submit an opinion on this.  I just do simple "what if's" to give the code author more possibilities.  As far as I'm concerned, it's your call, J. 

[JohnK]

Personally I think of a segment as part of something circular as in a segment of a circle or in 3D an orange segment. The use of face depends on the context. Probably the only time the word face would be used with both the 'triangular face' and 'polygon face' meaning would be in describing how a box was constructed within Babylon. Most people working at that level would understand the difference. In fact in this article  the author avoids this by using 'triangle' rather than face.
 

The basic object used in a 3D polygon is a vertex: a point in a 3D space. Two vertices connected creates an edge, and three vertices connected creates a triangle.
Therefore, a 3D polygon is a set a vertices connected to each others to create triangles.
Each vertex has 3 kind of information:

• A position - The vertex position in a 3D space.
• A texture coordinate (called UV coordinate) - Answers to the question "Which part of the texture should be applied on this vertex ?"
• A normal vector - A directional vector, used to determine the vertex orientation toward a light source

Each face of a polygon has its own vertices. A cube for example will have a total of 24 vertices (6 faces, each faces has 4 vertices), because each vertex will have its normal for the corresponding face.

 

 

My preference would be to use face when dealing with a polyhedron such as a box and surface when dealing with non - polyhedron such as a cylinder. If only one was to be to used I could easily live with face.

 

Most people, I would imagine, would be get it from examples and would happily accept for example

 

To colour each face of a box differently use this construction

var faceColors = new array(6);faceColors[0] = new BABYLON.Color4(1,0,0,1);faceColors[1] = ...............................................var box = BABYLON.Mesh.CreateBox('box', {faceColors : faceColors}, scene);

and

 

To colour the top, bottom and curved surface of the cylinder independently use

var faceColors = new array(3);faceColors[0] = new BABYLON.Color4(0.5,0.5,0.5,1); //topfaceColors[1] = new BABYLON.Color4(0.5,0.5,0.5,1); //bottomfaceColors[2] = new BABYLON.Color4(1,0,0,1); //bottom //labelvar can = BABYLON.Mesh.CreateCylinder('can', {faceColors : faceColors}, scene);

or

 

To texture the top, bottom and curved surface of the cylinder independently use

 

something clever with a texture atlas

 

faceTextures = new array(3)

faceTexture[0] from texture atlas  etc   (bit beyond me here )

 

So I would say stick to face.

[jerome]

When the math teacher speaks, everyone listens !

 

I like your suggestions about colors, John.

Sold.

 

For textures, I prefer to keep the UV (coordinate ratios) conventions instead of the index of the texture in an atlas.

Indeed, using an atlas is just a particular (useful) case, we can use a classical texture (no atlas) and choose to display only parts of it on each face.

Thus the atlas (and so index) aspect is only a possibility among many others. 

[jerome]

mmmhh... as another old parameter is called sideOrientation, shouldn't we keep the term side after all ?

sideColors ?

sideUV ?

 

feeling confused now

[jerome]

I think I understand what is confusing :

 

The texture (per-*) feature can be applied quite on every mesh as this mesh has at least one face to display the texture onto.

The color (per-*) feature can be applied only on meshes which have at least one identified side (I don't talk about vertex technical restrictions here) different from the others in the visible geometry for the user. Example : a sphere has no side but a spherical surface. It's eligible to the texture-per-* feature but not to the color-per-* one.

 

And we try from the beginning to use the same term for both... what is not dumb because these two features have the same behavior (to apply something on a part of the mesh surface) but not the same perimeter.

 

So I suggest finally to keep the term face  because of the very good arguments of JohnK, because it's quite understandable at first read by people if they don't think too much (arrf), because it's short and universal (even if sometimes vague). I will write the documentation for each mesh so the users will understand precisely what each feature really does in each case.