Jump to content

Discussion about nodes, meshes, instances


gwenael
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 3 months later...

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...