Sign in to follow this  
Dal

Why doesn't Node have a position?

Recommended Posts

@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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.