Why doesn't Node have a position?

[Dal]

All the children of Node have a position,  but Node itself doesn't, so how can I just attach lots of things to a Node and then move the parent?

[adam]

http://www.babylonjs-playground.com/#UDQQ2#0

[Dal]

@adam Cool, that works,... but then if Node is the base class of Mesh, Light and Camera, and all of those have a position, why don't we just define position on Node instead? Then instead of an empty mesh, we can just have a named base node, which would be cleaner wouldn't it?

[Wingnut]

http://doc.babylonjs.com/classes/2.4/Light

Hi Dal!  See a .position on that? 

It's a magical gotcha.  heh

How about http://doc.babylonjs.com/classes/2.4/Bone ? 

I'm ruining all the fun, aren't I?

[Dal]

Hmm, so why not then?

I'm just thinking, if we have a huge scene with lots of different meshes, players, lights etc. and we want to move the whole thing (e.g. so we can have an infinite world size without worrying about the numbers getting too huge), it seems more natural to me to parent them all to a root:Node rather than a dummy empty mesh.

[JCPalmer]

Light does not have position.  That is only at the SpotLight sub-class, which is probably the reason.

As far as your purpose, your customers certainly will not care how big your numbers get.  Adding a "global" parent will add slightly to the overhead of each frame to compute the world matrix of every mesh.  I appreciate elegance, but if you still wish to move everything, I would write code to move every mesh in a loop the same relative amount to avoid paying to this convenience every frame. 

Your customers with marginal hardware might notice the extra drag of just one more parent for every single mesh, which can add up.

[Wingnut]

User:  "Hey forum, why won't my arcRotateCamera...  arcRotate properly?"

Dal:  "Um, cuz it's parented to a master node that has a single position and rotation (and scaling) that is continuously inherited by all scene items including lights and cameras, which aren't even mesh."

User:  "Oh, ok, thanks.  I'm changing frameworks, now." 

I'm just having some fun with ya, Dal. 

Did you ever ponder that maybe you have "extends" mixed-up with parenting?  I used to have the same problem.  But here, in this system, parent/children are not the same as class and extendClass (sub-classes?). 

Generally, the big three parent-handed-down properties are position, rotation, and scaling.  These are PARENT handed-down values, not class-inherited values.  Notice I said value.  Just because abstractMesh has a .position property, doesn't mean we want its position VALUE to be handed-down to its subClasses.  Only parents hand-down position values.  Parent mesh start as siblings of the children (brothers/sisters).  When either sets the other as a parent, the parent does not suddenly become a super-class of the child mesh.  They are still siblings... on the same level.  BJS automatically passes-on the values of the parent's position, rotation, and scaling... to the children.

I think if .parent property... changed names to be .masterPositionRotationScalingController, you'd feel better about it. 

All in all, I'm not really qualified to answer... but I thought I'd stick my nose-in and be talkative and annoying... like I usually am.  The real pros may have more/better answers for you.