Somehow I don't understand the logics behind the transformations being used.
Background: I want to "group" nodes which are already positioned with it's own pivot in the scene.
So I create a dummynode and position it somewhere in the scene.
When I just "parent" some child nodes to this dummynode, the childnodes move to the dummynode?! What is the logics behind this?
Grouping nodes
Re: Grouping nodes
Well since you set parent, child node positions/rotations become relative to that parent and not the scene origin. To understand this better I would suggest you to take a look at ISceneNode.h.
Working on game: Marrbles (Currently stopped).
Re: Grouping nodes
The "logic" behind this behavior is that every scene node has its own transformation (position, rotation, scaling) and that that transformation is referred to as its "Relative Transformation". When drawAll() is called, the relative transformation will be offset from the transformation of its parent before being drawn. If a node has no parent, it uses the "root scene node" to calculate this parental offset, and the root scene node has no transformation/offset. So, basically, in this case, the relative transformation is the same as the absolute (world space) transformtion.
So a node sitting at vector(4,1,0) with no parent will appear at vector(4,1,0) because that's the position relative to its parent node (the root scene node) which sits--by definition--at vector(0,0,0). If you set your node to have a parent that itself sits at vector(5,6,10), then the drawAll() call will factor in that your node is supposed to be at vector(4+5, 1+6, 0+10)
This applies to rotations and scaling as well as translation(shifting/moving) of nodes.
In this way, you can set the relative rotations of the children nodes and forget about having to update every single one when you want to move the parent. They'll just magically appear in their new positions (rotations/scalings) relative to the parent when you change the parent's transformation.
In order to get the children not to jump to a new position, you need to "remove" the parent's updated absolute transformation from that of each child's relative transformation whenever you set its parent. Then it will behave like a cute little ducky and follow its parent however the parents moves, turns (scales itself).
Hopefully that made sense and if you don't know how to update a parent's absolute transformation or the children's relative transformation, check the docs or just ask. (Hint: it involves multiplying the parent's inverse matrix by the child's position/rotation/scale before resetting the child position/rotation/scale).
So a node sitting at vector(4,1,0) with no parent will appear at vector(4,1,0) because that's the position relative to its parent node (the root scene node) which sits--by definition--at vector(0,0,0). If you set your node to have a parent that itself sits at vector(5,6,10), then the drawAll() call will factor in that your node is supposed to be at vector(4+5, 1+6, 0+10)
This applies to rotations and scaling as well as translation(shifting/moving) of nodes.
In this way, you can set the relative rotations of the children nodes and forget about having to update every single one when you want to move the parent. They'll just magically appear in their new positions (rotations/scalings) relative to the parent when you change the parent's transformation.
In order to get the children not to jump to a new position, you need to "remove" the parent's updated absolute transformation from that of each child's relative transformation whenever you set its parent. Then it will behave like a cute little ducky and follow its parent however the parents moves, turns (scales itself).
Hopefully that made sense and if you don't know how to update a parent's absolute transformation or the children's relative transformation, check the docs or just ask. (Hint: it involves multiplying the parent's inverse matrix by the child's position/rotation/scale before resetting the child position/rotation/scale).
"Computers don't make mistakes! What they do they do on purpose!!"
-Dale Gribble
-Dale Gribble
Re: Grouping nodes
Of course I can "localize" the coordinate frame but I still don't understand the logics.
Don't flame me now, but after using the DLL for 1 week, I have the personal feeling that somebody started to write a 3d engine without any deep experience on any other 3d software packages or reading books. It is hard to understand why they reinvented the wheel instead of e.g. simply using wildmagic or something else. Also the "left coordinate frame" thing seem to be happened by accident and always requires useless conversions.
Don't flame me now, but after using the DLL for 1 week, I have the personal feeling that somebody started to write a 3d engine without any deep experience on any other 3d software packages or reading books. It is hard to understand why they reinvented the wheel instead of e.g. simply using wildmagic or something else. Also the "left coordinate frame" thing seem to be happened by accident and always requires useless conversions.
Re: Grouping nodes
Never seen a 3D engine use wildmagic, but one easy reason - if you really need one - would be that those libraries got written around the same time. I think they both started around 2003 - at least that's when Irrlicht started and Geometric Tools for Computer Graphics, the book behind wildmagic (fantastic book by the way) was also released in that year.
And left handed coordinate system was most likely simply because Direct3D uses that. The 3D world is pretty much split into using left-handed or right-handed, but I have no idea where you need useless conversions because of that aside from writing a new mesh-loader for a formats using a right-handed system.
I don't know what you mean with group nodes. You can put them in an array if you just want to group them. The scenegraph works pretty much like in any 3D software - child positions, rotations and scaling are relative to parents.
And left handed coordinate system was most likely simply because Direct3D uses that. The 3D world is pretty much split into using left-handed or right-handed, but I have no idea where you need useless conversions because of that aside from writing a new mesh-loader for a formats using a right-handed system.
I don't know what you mean with group nodes. You can put them in an array if you just want to group them. The scenegraph works pretty much like in any 3D software - child positions, rotations and scaling are relative to parents.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Grouping nodes
You're right, I also never saw wildmagic being used somewhere - was just an idea.
Maybe my general understanding problem arise only from the fact, that I started 3D developing before D3D existed. So I never ever used left-hand coordinates at all.
With grouping I expected the "parenting" like in 3dsmax. When I connect there nodes, I do not have to take care about moving their TMs back.
I'm also missing some basic matrix4 operators like:
Maybe my general understanding problem arise only from the fact, that I started 3D developing before D3D existed. So I never ever used left-hand coordinates at all.
With grouping I expected the "parenting" like in 3dsmax. When I connect there nodes, I do not have to take care about moving their TMs back.
I'm also missing some basic matrix4 operators like:
Code: Select all
vec3 = mat4 * vec3