Node::setGlobalPosition/Orientation/scale?

[_tommo_]

Hi,
it's not a big deal, but after messing up as usual with local-to-world transform, i wondered why Ogre doesn't support direct world positioning...
the transformation can become difficult when you have a hierarchy of orientated and scaled nodes, and setting the absolute position of a Bone can be a real pain... and for sure litters the game code with ugly geometry things

So... there's a reason because Ogre doesn't support global setPosition/setOrientation/setScale?
It would be really useful.

[Klaim]

Look for _getDerivedPosition() and similar member functions.

[_tommo_]

Look for _getDerivedPosition() and similar member functions.

Nah. I don't mean Get, I know those functions... I mean a "set" method to place the Node using world coodinates, like:

Code: Select all

mySkeletonInstance->getBone( i )->setWorldPosition( myPhysicObject->getWorldPosition );

A thing like that is long to achieve, when setPosition is restricted to local space... and if the parent bone(s) have a modified scale or orientation, so a method like that would be useful, imo.

[Klaim]

I see... I remember that there was a function like that somewhere but can't find it.

Aynway, you could do something like :

Code: Select all

void Node::setDerivedPosition( const Vector3& position )
{
    const Vector3 derivedPosition( getDerivedPosition() );
    const Vector3 difference( position - derivedPosition );

    setPosition( getPosition() + difference );
}

I didn't tried it, so I may be wrong.

If you try it and it works, you should submit a patch.

[haffax]

Klaim, your solution doesn't take orientation into account.
Here is a working way: http://www.ogre3d.org/forums/viewtopic. ... 91#p324891

There are now world-setters in Ogre because it breaks the parent-child relationship among the nodes. If you have the need set the world position of a node, then it often means it shouldn't be a child of the parent anyway.

Ogre 2.0 will introduce a different concept, abstracted transformation sources, which can be scene nodes or anything else that makes more sense for your kind of world setup.

[_tommo_]

The linked solution looks good, but it doesn't take into account the scaling of the node... so i think it can't go into Ogre right now.

Anyway for me it's only partially true that a setWorld* method breaks the node hierarchy: I mean, often they are needed only once in a setup phase; then you could want the node to move relative to its parent.

And there are other cases where you can't do anything else, for example when setting skeleton bones using external position sources.
For example, i was implementing a 2-bone spring, using a 2-body joint system in PhysX.
It turned out that synching the top (and center) bone with the top body was a difficult task, especially because the spring can have an arbitrary scaling.

So i think that having some general setWorld* methods in Node, while waiting for Ogre 2.0 (which sinbad said would be a long wait) would be good

[jacmoe]

There are now world-setters in Ogre

Don't you mean no world-setters?
I agree that those nodes shouldn't be children if they need to be world positioned. Node hierarchies are a relative concept.

[haffax]

There are now world-setters in Ogre

Don't you mean no world-setters?

Yes.


@_tommo_, I agree that there are a few cases. I guess following Klaim's advice is good, make a patch.

[_tommo_]

Ok i will see how to make a patch

I modified haffax's method to take into account scaling, now i must figure how to do setWorldOrientation/Scale...

[Kojack]

Although it's pretty easy to do manually, if there are get functions then there should be set functions.
While normally it would seem that setting world values of a child could indicate a bad organisation, there are valid uses for it:
- setting the orientation of a child to face at something regardless of the parent, like gun turrets on a vehicle. The parent/child system is correct for position and when there's no target it's also correct for rotation, but once a target is found the turrets would use world orientation.
- ragdolls. Ogre only supports hierarchal skeletons (I once modded it to support flat skeletons), every bone is relative to it's parent. Then the root bone is relative to the containing scene node. But physics engines use world orientation for joints. So you have no choice but to set the world orientation/position of child nodes (each bone is derived from node).

Edit: of course for the first case you could just use setInheritOrientation(false) on the node so position is still local but orientation is world.

[_tommo_]

I made the patch

Instead to put everything into a setWorldPosition method( which would be abused too often ) i made a getLocalPosition(Vector3) method, that returns the local position relative to a node of a given world position.
This way you can get a local position without forcing the node hierarchy and without adding another useless "position node".
To set the world position of a node, you can also call _setDerivedPosition(), that calls getLocalPosition on its parent and uses it with setPosition.

Added also a getWorldPosition method, that does the inverse: given a local position returns the world position... so you can go local<->world at any time.