Discussion about nodes, meshes, instances

[gwenael]

Hi everyone,

 

I don't think BabylonJS internally uses instances. Please let me know if I'm wrong.

 

I'm not talking about instances of OO programming language but about instances (animation, camera, geometry, light...) specified within Collada specifications http://www.khronos.org/files/collada_spec_1_5.pdf

 

Let's say you want trees in your scene and that you will pretty much always use the same tree but "plant" it in different locations. You have, let's say, 100 trees to plant. Thus, your babylon file will contain 100 meshes for your trees since you want to check collisions for all of them (that could be one huge mesh with 100 submeshes but the number of vertices must exceed the limit). You have 100 meshes whereas it's the same tree (3d representation) so the only differences between them should be name, id, parentId, position, rotation, scaling, rotationQuaternion, isVisible.

 

What I suggest it's to create new classes, transform, geometry, animation and physics, and to modify node and mesh.

 

transform would contain all information about transformations (position, rotation, scaling, rotationQuaternion).

geometry would contain all information about 3d representation (positions, normals, uvs, uvs2, colors, matricesIndices, matricesWeights, indices, subMeshes)

animation would contain all information about animation (animations, autoAnimate, autoAnimateFrom...)

physcis would contain all information about physics (physicsImpostor, physicsMass...)

 

node would contain parenting mechanism, name and id.

transform would inherit from node as light, camera and mesh would.

mesh would have to have a reference to a geometry instance (OO meaning) and could have a reference to an animation instance (OO meaning) and/or a physics instance (OO meaning) and/or a reference to any other component "class" that could be added later (collisions object...).

 

mesh would be a composition of components (geometry, animation, physics...) and could share these components with other meshes. If a mesh doesn't have physics it wouldn't have to store physicsImpostor, physicsMass and so on but only physicsComponent = null.

 

Thus, for our 100 trees example, we would have 100 transform nodes, each parent of 1 mesh. There would in total 100 meshes, like before BUT each mesh would refer to the same geometry instance (OO meaning), the same animation instance... Thus the file would be smaller and if we would decide to change the geometry, all trees would be affected without having to reimport the file. Thanks to the parent transform node, we would be able to translate, rotate and scale the child tree as wanted.

 

We can actually find this kind of approach in the incremental system since different meshes could point to the same babylonmeshdata file (exporter doesn't do that for now I think) but after importing, meshes do not seem to be considered as instances (Collada meaning).

 

Any thoughts on this?

[gwenael]

Of course, we could use the same light, the same cameras at different locations thanks to different parent transform nodes.

[GameMonetize]

Right now, if you clone a mesh, all webgl buffers are shared (vb and IB) which is a kind of what you are suggesting

[gwenael]

Thank you Deltakosh for the time you spent to read my post certainly too big and not enough clear. But you seem to have understood me

 

I'm happy to learn that cloning a mesh allows to share webgl buffers. It's a good start to share geometries between meshes. Nevertheless, is there a way in the babylon file format to specify that a mesh is a cloned of another one? What about animations, physics and other ones? Does cloning a mesh handle them too?

 

Of course I'm not badly criticizing your engine, I'm far away from that. I'm trying to understand what you've done so far and to see if it would be easy to integrate what I'm suggesting about instances. As far I'm concerned, I think it would be awesome but maybe I didn't take everything into account and no one else is interested in it. Anyone ? I'm be pleased to contribute on this for sure.

[GameMonetize]

When you clone a mesh, animations are cloned too. Physics is not cloned. Skeletons are referenced (no duplication)

 

Right now there is no way to define a clone in the .babylon file format but we could do that easily (we must just ensure that we keep file compatibility)

[gwenael]

Will you be interested in a more global instance mechanism as described in my first post? This mechanism would obviously use the current functions such as BABYLON.Mesh.prototype.clone.

 

I really must be missing something since I'm surprised that anyone else seems interested in it. I noticed it's implemented by several software and it's took into account by standards such as Collada so I thought that could be nice to have it in BabylonJS. At first glance I thought there were only advantages. Does anyone know inconvenients with using instances?

[GameMonetize]

Absolutely no problem with that  

 

My only concern is keeping performances high and compatibility with existing code.

 

Happy to see motivated developers!!!

[gwenael]

Hi,

 

I've started working on it and I was wondering why VertexBuffer needs to keep a reference on the mesh. I saw that it uses to call _resetPointsArrayCache on it while creating/updating the vertex buffer but this is not done for cloned meshes. Could we not store a reference to a mesh inside VertexBuffer and call BABYLON.Mesh.prototype._resetPointsArrayCache when needed in BABYLON.Mesh.prototype.updateVerticesData? Or VertexBuffer should keep track of all meshes sharing it.

[gryff]

Let's say you want trees in your scene and that you will pretty much always use the same tree but "plant" it in different locations. You have, let's say, 100 trees to plant. Thus, your babylon file will contain 100 meshes for your trees since you want to check collisions for all of them (that could be one huge mesh with 100 submeshes but the number of vertices must exceed the limit). You have 100 meshes whereas it's the same tree (3d representation) so the only differences between them should be name, id, parentId, position, rotation, scaling, rotationQuaternion, isVisible.

 

 

From past experience with other 3D systems, this situation may call for an LOD system. Do you want all trees to have checkCollisons true - they maybe far away, on top of a hill etc.

 

Did I not read somewhere that DK talked about developing an LOD system?

 

Hope this comment does not distract from the thrust of you post gwenael.

 

cheers, gryff

[GameMonetize]

Be also aware that as IE11 will soon support hardware instancing, babylon.js will also support it So this system should take it in account

[Wingnut]

Gwenael, I have been thinking about your "share the characteristics" idea...  from the first post in this thread.  As best I can tell, that is some BIG BIG thinking.  You are a mad man!  Is that you?  I think so. 

 

So, we are looking at each mesh... allowing share-able (and/or inheritable) characteristics.

 

A single cloned mesh might...

 

- use/be an instance of mesh1's transform characteristics

     and

- use/be an instance of mesh2's geometry characteristics

     and

- use/be an instance of mesh3's animation characteristics

     and

- use/be an instance of mesh4's physics characteristics

     and maybe...

- use/be an instance of mesh5's material characteristics

 

(all at the same time)

 

Am I thinking about this... in the same way that you are/were?  (thx)

[gwenael]

You are a mad man!  Is that you?  I think so. 

 

Yes it's me at GDC 2009 in SF, but I prefer this angle: http://www.twixco.com/pages/3d_scan.php . Please don't pay attention to my website, I haven't spent time on it from years.

[gwenael]

A single cloned mesh might...

 

- use/be an instance of mesh1's transform characteristics

     and

- use/be an instance of mesh2's geometry characteristics

     and

- use/be an instance of mesh3's animation characteristics

     and

- use/be an instance of mesh4's physics characteristics

     and maybe...

- use/be an instance of mesh5's material characteristics

 

(all at the same time)

 

Am I thinking about this... in the same way that you are/were?  (thx)

 

Not really, but if you modify "cloned mesh" by only "mesh" you get the idea. A cloned mesh should ONLY share the characteristics of the source mesh (only one mesh not several ones) but you could create a new mesh which would share material characteristics of a second mesh and geometry characterics of a third mesh. Keep in mind that some characterics should stay linked though. Sharing animation characterics implies to have a cloned skeleton. I don't think that transform characteristics should be shared, that's not the idea of instancing whereas all your trees would be at the same place except if the don't have the same parent.

[gwenael]

@Wingnut: do you know Collada format file (.dae)? It could help you to understand instances.

[gwenael]

From past experience with other 3D systems, this situation may call for an LOD system. Do you want all trees to have checkCollisons true - they maybe far away, on top of a hill etc.

 

Did I not read somewhere that DK talked about developing an LOD system?

 

Hope this comment does not distract from the thrust of you post gwenael.

 

cheers, gryff

 

You're right, we must keep in mind that instancing system must be usable for LOD system. What I suggest is that a mesh has a geometry, this geometry can be its own geometry or it can be shared with other meshes (it uses the one of another mesh). Only the 3d representation is shared (how it looks like), not other properties for now. If a mesh has a geometry it means that we could dynamically tell it to use another geometry, for example the same geometry as all the trees that are far away from the camera, because now our tree is far away too and once we are close to it, it will share the geometry with the other trees which are close to the camera.

[gwenael]

Just found a good article. For sure, even if I haven't read the whole article, it will be better than any of my posts about the subject.

 

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter03.html

 

They took the same example as I did

[gwenael]

Be also aware that as IE11 will soon support hardware instancing, babylon.js will also support it So this system should take it in account

 

Hmmm, how will it work? What should I take into account?

[gwenael]

Hi,

 

I've started working on it and I was wondering why VertexBuffer needs to keep a reference on the mesh. I saw that it uses to call _resetPointsArrayCache on it while creating/updating the vertex buffer but this is not done for cloned meshes. Could we not store a reference to a mesh inside VertexBuffer and call BABYLON.Mesh.prototype._resetPointsArrayCache when needed in BABYLON.Mesh.prototype.updateVerticesData? Or VertexBuffer should keep track of all meshes sharing it.

 

 

Any answer for this?

[Wingnut]

Hi.  I should have used the term 'traits'.  'Characteristics' is difficult to type.    No, I do not know the .dae format, but will look at it.  Thanks for the further information. Yes, a clone would/should be a perfect copy of its clone-master, but a new created mesh could don (take-on) traits from many share-able sources, but most importantly for now, shape/geometry.  For distance-based LOD 'zones'.  I think I understand. 

 

Sometimes I think that the babylon.js use of .parent... conflicts-with another type of parent-child relationship.  Maybe our current .parent property should have been called .controller or .groupmaster.  Then .parent can be re-defined as meaning the cloning-parent of this mesh.  Maybe...  .clonemaster, and .groupmaster and .shapemaster, etc.    Maybe Wingnut should shut his mouth and go back to his crib toys.    Cool 3D of you on your website, by the way.  I like it.

 

Ok, returning to gwenael's question which needs some kind of answer, or further discussion.  thx gang.

[GameMonetize]

For instancing, I mean that the gl renderer will be able to render multi-instances based on different world matrices.

 

for mesh reference into vertex buffer, I agree with you we can remove it and just call resetPointArrayCache when using setVertexData

[gwenael]

Perfect. I guess I can use a geometry class. A instance of it will store the meshes using it (or a geometryManager will do it) and will be passed to the gl renderer (in some way)

[GameMonetize]

I think so.

[gwenael]

The geometry system is up and running

https://github.com/BabylonJS/Babylon.js/pull/192

https://github.com/BabylonJS/Babylon.js/wiki/Babylon.js-file-format

[gwenael]

Back to my first post. Since, I created the class Geometry (as defined in my first post but without submeshes) and sub-classes of it to handle primitives. And now I would like to talk again about hierarchy and transforms.

 

I would like to consider cameras, lights and meshes as nodes. Yes they already are but as far as I'm concerned they should only be considered as are in the Node class, they shouldn't be considered as cameras, lights and meshes inside the Node class (there shouldn't be this._scene.meshes in getDescendants()). The Node class shouldn't know the names of its sub-classes. What I suggest is to handle hierarchy inside the Node class and that Scene would always have a unique root node (the world). A setParent function in Node would enable to keep track of children of a node. Maybe it's too heavy to store all children of a node on that node nevertheless it would be a lot more efficient to get the descendants of a node. (If it's too heavy, there could be a list of nodes for the scene (in Scene class) and meshes, lights and cameras lists would be bookmarks on it and we could improve getDescendants by using a stack of already tested nodes.)

 

Node class would also store local transform information and would handle cache for it. 'computeWorldMatrix' would be a function of it.

 

Thus, hierarchy and transforms would be handled by the Node class (and sub-classes when overriding is necessary) and a mesh (or a camera or a light) could be parent of a camera and/or a light and/or a mesh. There would be more common code easier to maintain and which would follow the same logics.

[GameMonetize]

The rendering process needs a direct access to a list of meshes, cameras etc.

 

Warning: I'm for pragmatism: I mean if having meshes in node is more efficient or convenient then I do not care about anything else

 

I do not disagree with the idea of optimizing getDescendants() but not at the expense of rendering or ease of access

 

I like the idea of storing worldMatrix in the node. BUT what kind of matrix would you store for an hemispheric light or an oculus camera?