[SVN-2584][Not a bug] Parent->Child node positioning

[Elmaron]

I'm using SVN 2584 atm and ran into an issue with a first node being child node of a second node, which is child node of a main parent node that I am moving around, and then, after calling updateAbsolutePosition() on the first child node and setting the camera to its position.

On irrlicht 1.5, this works fine, the camera is firmly attached to the first node's position, also when the main node is moved around it works just fine.

With the SVN however, the camera lags noticeably behind the position where it is supposed to be when the main node gets moved around, then the absolute position of the first node updated and the camera set at its position.

[Elmaron]

I just noticed I'm also having it in irrlicht 1.5 a bit - just not as much... very strange

[CuteAlien]

It would be nice to post examples which we can compile to reproduce the problem when your report stuff like that. As you can already reproduce this in your system you can write such an example way faster than we can.

[Elmaron]

Ok I sorted the problem out. I have a node that is I think a child of a child of a child of a parent (4 layers). When attempting to access its position, I need to call updateAbsolutePosition() on every node involved starting with the parent node. I don't know if this is intended behaviour, but I always thought just using it on the child you're interested in will make it take care of all the parenting nodes updating their positions aswell before it calculates its own position based on them??

You should add a hint in the documentation that warns about this or change the behaviour so that parenting nodes get forced to update their position aswell before the child's position is caculated.

[CuteAlien]

Hm, good point. I would not like changing the default-behaviour as it's already used a lot and is actually often what is needed. But I see that in many cases users will call it they would probably prefer it to be recursive up to the root.

I've added a comment now, but that might be worth something like a "recursion" or "noRecursion" parameter.

[BlindSide]

I suggest adding another function that does it recursively. Maybe a function to the parent called updateAllAbsolutePositions()?

[CuteAlien]

I also considered another function for that first, but then again - that function is so easy to write when you think of it that it's barely worth putting it in the interface. I suppose the problem here is rather that this is easily missed and using a parameter might help to make this better visible.

[Elmaron]

I've added a comment now, but that might be worth something like a "recursion" or "noRecursion" parameter.

Yea, I guess that would help a lot getting aware of there being a difference. But maybe also two functions that due to their similar names will be put directly below each other in the docs would show it pretty good that there are two ways of doing it. Thanks for picking that up at least so there's hope other users won't run so easily into the same problem (I think it can really take a lot of time until you realize the source for your issues when you're not thinking of multiple possible behaviours existing for this function, at least it did for me).