questions about Mesh.getChildren()

[Kesshi]

Hi, i have two questions.
1. If i look at the sources it looks like all of the parent handling is done in AbstractMesh but getChildren is only available at Mesh.
Why? Shouldn't getChildren be part of AbstractMesh? I mean an InstancedMesh can be also used as a parent and it doesn't have getChildren ... or?

2. If you have a big scene with many meshes a call to getChildren() will be a slow operation because
all scene meshes will be iterated everytime. In my application i need to iterate over the children of my meshes quite often.
Wouldn't it be more effective if Mesh/AbstractMesh manages a list of all its children or atleast caches them?
AbstractMesh.dispose() would also benefit from this becasue its doing the same iteration over the whole scene everytime a mesh is disposed.

[GameMonetize]

1. This will be fixed soooooon

2. You can already save the list of children in your mesh. (Thanks to JS dynamic way of working)

[Kesshi]

17 hours ago, Deltakosh said:

1. This will be fixed soooooon

Nice :-)

17 hours ago, Deltakosh said:

2. You can already save the list of children in your mesh. (Thanks to JS dynamic way of working)

I know, i was thinking about that already. This way i could speedup the "getChildren".
But i still have a bad feeling about the dispose(), Maybe the overhead is not as big as i'm thinking but i have the feeling that its a bit inefficient to iterate the whole scene for every
disposed mesh. Even if i never use the parenting system at all in my scene, the scene will be iterated on dispose.
 

[Wingnut]

Hi.  I'm confused.  Aren't we getting the TWO kinds of parent/child relationship... confused with each other, here?  For example, a box can be a parent-of other mesh, lights, and cameras.  What does .getChildren() return?  Does it return different results, depending upon if it is called on a base class, versus when it is called on other mesh, lights, and cameras?

And then we have other trouble... like isInstanceOf() / getInstances(), and isCloneOf() / getClones(), and maybe even isManagedBy() / getManaged()... for sprites and particles.  *scratch scratch* 

I guess "normal" sprites/particles aren't really standard find-able mesh, but SPS particles are standard mesh, I think. 

Should the new LineSystem be called lineManager instead? 

Maybe particleSystem should become particleManager?

Maybe the current property .parent... should be renamed to .master or maybe .director.  How's that for some "breaking" changes? 

And, of course, when this new "revamped" BJS is released, we 'might just as well' (mizewell) set createSphere's parameters in the correct order, too, with size before subdivs.   

I bet Deltakosh has some "big breakers" in his regrets bag... that he would like to "activate", too.

Let's do it.  Backward-compat is for sissies.  It will only take a few hours to repair all the demos on the BJS site and on github and the docs.

All the broken playgrounds might take a bit longer.  I'll handle all the pissed-off users (bop bag duty).  hehe. 

[Wingnut]

A bit more.

In LambdaCore moos... everything had a number.  About the first 1000 numbers... were reserved for system objects... sometimes called $core objects.  For example, abstract mesh might be #300, and it stays #300 for ever and ever.  Then, on $core object (object #0)... each property on IT... caused a "corified" name/ref.

For example, there would be a property $core.abstractMesh and it would be set to the value #300... an objNumber-type value.  Abstract mesh would then be "corified as $abstractMesh".  Then, anywhere in the framework or scene code... the author could refer-to BABYLON.AbstractMesh...  as '$abstractMesh'... its corified name.  Neat, eh?

You could even refer to abstract mesh by its number, IN code...  #300.children... but that is discouraged and called "hard coding numbers".  Smart coders frown at that. 

Needless to say, .toObjNum(this/that/$someCorified)... was used quite often.  if (this.toObjNum() in $abstractMesh.children) {"its not a light or cam!"}.    Or maybe if (this.typeOf($abstractMesh)) {...}    Corifieds!   Yay!

$thing was a common one... the generic thing object.  $room was common.  @create $room named "MyRoom"...  and $room.children returned an array of objnums.  {#1122, #2389, #6320, ...}.  (moos had a command line interface)  All objects were directly/indirectly... children of $root (#1), which would equate to our node class.   The Generic Programmable Following/Wandering Belching Farting Joke-Telling Robot... was a fairly popular fertile, too.    In fact, $feature was created... the Generic Feature Class Object... designed specifically for... you know... adding features to stuff... overloading.  Users had memory quota on the telnet server, and their objects would persist... via flat ascii db.  This will happen here... after DK builds us a MS-sponsored persistent scene/world server (tile server). 

Value-added rooms, things, vehicles, containers, avatars, bots... were common.  People OFTEN made a child of $robot... and then just overloaded the hell out of it... too fun.  In moos, most user-methods are called "verbs".  Sneeze, fart, punch, kick, talk, send, wander, home, go, jump, toss... common 'verbs' to overload various generic base-classes.  It was just text.  Characters in the story... coming alive and acting retarded... wondering when you will enter the next room.

The .children method had a 2nd parameter... a return-full-inheritence flag.  children(mymesh, 1)... returned the children of mymesh, and IF mymesh.fertile = true... and mymesh had its own children... it would return the children's children, too.  And the children of the children of the children, etc.  Full-drill.

At the command line...   ;children($light) would return all the lights in a scene (as an array of objNums).  It worked inside code, too, because .children() was a method on $root (#1) (root methods)  And if a mesh has a .definesPropertyOrMethod  of "children", calling mesh.children would override $root.children (and $root.children()... wrapper method).  If you ref mesh.somename or call mesh.somename()... and if it returned propNF or methodNF for mesh, the "system" will seek upward through inheritence chain.  Eventually... it checks $root.

I think the moo used .isTypeOf() to determine what class of object... something is.  Can''t remember, too long ago. 

The property named .parent was not used for inheriting position, rotation, or scale.  We didn't have those things... it was a text-based Infocom-like thing.  Later, when we attached VRML scenes to some of the objects... pos, rot, and scale became more important, but then VRML died, which saved our butts. 

Likely, none of this is applicable for the new BabylonX.js project, but... I thought I'd rattle-on about it just the same.  Party on.

[RaananW]

so,

let's organize things a bit.

A camera, a light and a mesh - are all Nodes.

Each node can have a parent (mean also means that each node can also be a parent  ). Kesshi is right - there is no problem moving the getChildren function to the node. It will work the same as it is.

Which is what I did. But only for backward-compatibility  The Node already had geDecendants(), which does the same as the abstract mesh's getChildren(). Having said that - I have extended the getDecendants() function - it now accepts a boolean, whether or not you want direct decendants or to traverse the entire tree. This should speed up a bit, if you want direct children only.

There is also a new function that was just moved from the AbstractMesh to Node - getChildMeshes() (with the same boolean as the getDecedants, defaults to false) which will return meshes only.

I hope this clears things up a bit!

[Kesshi]

Thank you RaananW. Your changes look good. I like the getChildMeshes() ... one "instanceof BABYLON.AbstractMesh" less in my code

And about breaking changes. I also try to avoid them but doing breaking changes from time to time is not a bad thing.
It helps to keep the API clean and simple. Having to much deprecated/old stuff in the API just makes things more complicated.
If the breaking changes are documented i see no problem ... and no one is forced to update to new versions