[solved] ISceneNode::getAbsolutePosition

[utunnels]

I'm wondering why this always returns a zero vector, while getPosition returns the correct value.

[CuteAlien]

Call updateAbsolutePosition when you call getAbsolutePosition directly after changing a position. Otherwise it's not updated before the rendering (some optimization to avoid having to recalculate scenegraphs constantly).

[utunnels]

Oh thank you.
I see the problem now, I just did that before rendering.

[Mel]

I don't know if this may have anything to see or not with this, but i have found a small trouble regarding to the absolute positions of the objects.

Seems that the position of the child objects of a scene node aren't updated that inmediately, so, there is a small delay between the parent and the child, while this doesn't happen with the bones of a skinned mesh, when a mesh is attached to another via addChild(), it happens. If updating manually the absolute position is the workaround, then, what is the best way to attach nodes so this delay didn't happened and i don't have to call the updating for all the nodes out there? traversing the scene isn't that hard, but shouldn't this be automatic?

the scenario is this: I have a character, and i want to attach a special effect to the legs, and an object to the hands, so i add these nodes to the scene, and via addChild, i attach them to the proper places. and while the attachement works correctly, the objects aren't totally synced, as they should. How could this be solved?

edit: just in case you've been touching something. I am currently using the SVN 4309

[CuteAlien]

Updating childs manually is currently the only way when you need the updated position before rendering.

[Mel]

Is it very costly? could the update absolute position happen twice, before the render and after?

[CuteAlien]

Sorry, I really don't know... but I guess if you really need it to happen completely at some other point the easiest way is updating the whole scene nodes ones in a function starting with the root.

[hendu]

One matrix multiply per node, on the cpu. Fairly expensive, yes.

On the very latest Intel cpus it can be done in only four instructions, with supporting code (Intel's math lib). Irr uses the simple open-coded multiply with normal floats, which is pretty slow in comparison, but works everywhere.

[Mel]

I have read the source code, and more or less, can understand what is the problem behind, What i don't understand is that, according to the code, this delay shouldn't happen at all because the absolute update of all the positions happens just before the rendering process, in the drawAll method (The "OnAnimate(os::Timer::getTime());" call near the begining is what performs this).

I will investigate more.

It can be confusing, but couldn't there be another way, for instance, the drawAll() method performs all the operations like always, and maybe it was useful that there were another methods for finer tuning of the rendering operations, so, perhaps, the getAbsolutePosition() didn't return an incorrect value before the rendering.