MultiMaterial and subMeshes docs

[NYCdotNet]

Greetings,

 

I want to improve the documentation for using MultiMaterial and subMeshes.  In order to attempt to understand it myself, I put together this playground which I think has everything required to demonstrate the basic concepts fairly well.

 

http://babylonjs-playground.com/#1GRJLM#1

 

I need help with two things.

 

The first is understanding the difference between vertices and indices.  I know the vertices represent the actual points in 3d space - where do the indices come in to play?  I'm assuming it's the grouping of the points into triangles, right?  Sorry if this is discussed in many places already - I'm having a hard time searching for this stuff.  Does the "Index array" section of this article apply?   https://en.wikipedia.org/wiki/Triangle_mesh

 

Second, when would you NOT specify 0 and the total count of vertices in the mesh for the second and third arguments when constructing a submesh?

All of the answers to the above will go into a docs PR that I'll try to cross-reference liberally.

 

Thank you!!!

[jerome]

Please have a read a this old DK's post : https://www.eternalcoding.com/?p=113

The indices are related to the index buffer.

[NYCdotNet]

Thank you so much, @jerome

[NYCdotNet]

Does this all sound accurate?

 

A vertex is a point in 3D space represented by its x,y,z coordinates.  In Babylon.js, the vertices that make up a mesh are stored in a vertex buffer.
Specifically, a Babylon.js mesh's vertex buffer is a JavaScript array of numbers.
Every three numbers in the vertex buffer represents a point, however there is no implied relationship between different points in a Babylon.js vertex buffer - they are just points floating in 3D space.
You can get the raw position vertex data on a Mesh object by calling its getVerticesData(BABYLON.VertexBuffer.PositionKind) method.
In order to relate the vertices in a mesh, Babylon.js uses an index buffer.
The index buffer is an array of numbers that represent indexes in the vertex buffer that should be related to make triangles.
The length of the index buffer is always divisible by 3 because it takes 3 vertices to make a triangle; three elements from the index buffer taken together are called a face.
You can get the raw index data on a Mesh object by calling its getIndices() method.

[dbawel]

You have a basic undertanding... However the following info will explain this fully.

http://rbwhitaker.wikidot.com/index-and-vertex-buffers

I highly recomend viewinf the source ode for the example - otherwise simply viewing the page may not make sense.

DB

[Wingnut]

Hi guys.

   NYCdotNet, this playground might be useful.

http://www.babylonjs-playground.com/#1UHFAP#67

That is a "color-per-vertex" version.  Go to version #68 to see the UV's and a standardMaterial in-use.  The UV values are "guessed", and it shows. 

The little blue boxes can be removed... after you are done playing with plotting.  They are helper boxes.

Personally, I think this little playground delivers a whole lot of learning... quite quickly.  Hope it helps.  It is certainly a great piece of code... to experiment-with.  Perhaps, take home a ZIP, roll one up, and become one with BJS plotting. 

Two extra things you should know. 

1.  The clockwise/counter-clockwise direction... used to connect 3 verts together with indices.... determines WHICH is the back-face and which is the front-face. For example, change line 62 from 3, 1, 0 (counter-clockwise)... to 3, 0, 1 (clockwise).  One of the faces (on the back of the mesh) will disappear, because its backface is now facing the camera.  It is still view-able... from inside the mesh.  You may wish to set camera.wheelPrecision = 250 (to allow more precise mouseWheeling), and remember that control-mousedragging can be used to move-around the arcCamera.target.  By doing those two things, you can take the camera inside the mesh, and see that affected face... now facing the inside of the mesh.

"Lighting normals" come into play, too.  There is a lighting normal at each vertex.  In #67 demo, pan around until you see vert #7 (in the dent).  See the "green specular light movement" inside the dent area... as you pan?  Specular shine.  This is caused by light2 specular color in line 14.  Change Green() to Blue(), and hit RUN again, and the light reflection will change to blue.  Another similar specular shine happens around the #6 vert, caused by line 19.  Now change line 74...  to 1, 0, 0 (the lighting normal for vert #7.  Hit RUN and do some panning around vert #7 again.  Things have changed, right?  How lights act... their diffuse, specular, etc, near a vert... is affected by its lighting normal direction.

2.  When some madman does... mesh.convertToFlatShadedMesh(), things CAN really go to hell.  The amount of verts, normals, UVs, all increase (but not indices?)  Let's take a look at another playground.  http://www.babylonjs-playground.com/#104HTQ#1   Line 42 does the conversion, as you can see.  Enable/disable it... to see the difference between flat and smooth shading.  Look at console to see the difference in data lengths.... pre-conversion and post-conversion.  Interesting?  Almost, huh?

For fun and adventure, let's de-activate line 33 and activate line 32 (in the #1 playground).  Let's see what these console numbers look-like... with a plain old BJS box.  (click on that link, if you wish... easier than typing).  Also, you can type control forward-slash... which quickly activates/de-activates code lines in our playground's Monaco editor... a handy feature.  Ok, how about those console numbers... when using the box instead of the torus knot?

Fascinating, eh?  24 verts for box.  Why not 8?  We'll talk. 

There is a "rule" in the BJS plotting world.  Only ONE lighting normal allowed per vertex.  When a mesh is converted to flat-shaded, three lighting normals are needed at each vertex position (I think this is true) (I'm far from a pro).  The way BJS accomplishes this... is to add verts atop previous vert positions, and aim their lighting normals at different angles from the original vert's lighting normal angle.  This is how three lighting normals can be placed at the same vert POSITION.  When using our torus knot, we can easily see the difference between flat shaded and smooth shaded (by disabling/enabling line 42). 

But... have you asked yourself WHY... a box... has 24 verts by default, instead of 8?  One would suspect that boxes are ALREADY flat shaded... by default, yes?  Yet, when we converted the box to flat shaded, 12 verts were added.  Why?  I do not know why.    But then again, I do not know why boxes have 24 verts instead of 8.  But I have a theory:

A chap named Jerome... is one of our local superheroes.  He's a nice guy, super-helpful, and has done TONS to advance BJS dynamic mesh generating... by coding something called meshBuilder.  One of the very cool things he did.... was to use a phenomenon called faceUV's... in order to add a feature that allows EACH SIDE of a BJS box... to have a different color or texture.  In order to accomplish this, it was required that BJS boxes have 24 verts, by default.  I THINK that is why our boxes have 24 verts.  Not sure, though.  I'm still learning.

Perhaps, you should return to our original plotting demo, and try to use it to create an 8-vertex box... just to prove it can be done. 

I hope this helps.  Be well, party on!