ISceneNode implementation and gimbal locks

[3p]

Aren't gimbal locks inherent due to Irrlicht's scene node design?
I checked and I see OGRE uses quaternion for relative scene node orientation, while irrlicht uses a vector.
Even if I use special "orientation" quaternion for my in-game object, I can't force it upon node, since only way to orient irrlicht node is euler angles.

Am I completely wrong about this? If not, is there at least an easy way around it?

[3p]

I modified ISceneNode to use quaternion for RelativeRotation, which isn't that much work, only to find out that cameras, which inherit ISceneNode don't use it at all, but have separate vector based target & up-vector...

To much work for someone not very familiar with Irrlicht.

[garrittg]

greetings 3p if you are willing i would be very interested in seeing your quat rotation code as i am struggling with the same thing right now.

as for the camera rotation issue, for a camera that acts like a scenenode i use a standard camera with an animator. the animator uses the underlying node rotation to rotate the camera correctly. this is not C++ but i think is probably readable to you. this assumes an up vector of 0,1,0.

Code: Select all

Type PositionCameraAnimator Extends ISceneNodeAnimator

	Method animateNode(node:ISceneNode,timeMs:Int)
		Local _cam:ICameraSceneNode=ICameraSceneNode(node)

		Local mat:Matrix4=Matrix4.create()
	
		' get the current rotation of the camera		
	    mat.setRotationDegrees(_cam.GetRotation())
		
		' transform the up vector based on the current rotation
		Local u:Vector3df=_VECTOR3DF(0,1,0)
		mat.transformVect(u)
		_cam.setUpVector(u)
		
		' transform the target point based on the current location
		Local v:Vector3df=_VECTOR3DF(0,0,1000)		
		_cam.getAbsoluteTransformation().transformVect(v)			
		_cam.setTarget(v)
	EndMethod

EndType

[3p]

There is not much to show. I just changed RelativeRotation in ISceneNode.h to:

Code: Select all

core::quaternion RelativeRotation;

Then modified setRotation and getRotation:

Code: Select all

virtual void setRotation(const core::vector3df& rotation)
{
  RelativeRotation = rotation * core::DEGTORAD;   
}

virtual const core::vector3df getRotation() const
{
  core::vector3df euler;
  RelativeRotation.toEuler(euler);        //to euler
  euler *= core::RADTODEG;                //we return degrees
  return euler;
}

And made small modification to getRelativeTransformation, so it initializes matrix directly from quaternion:

Code: Select all

...
  core::matrix4 mat;
  mat = RelativeRotation.getMatrix();
...

This change allows for some compatibility with the rest of code. Then you add methods to directly manipulate quaternion rotation... But that's far from all that needs to be done, since there are some issues with euler / quaternion conversions, which break some other things (like rotation animator in some examples), and the whole camera-not-using-rotation thing...

[rogerborg]

I'm following this with interest, by the way. Do you think that a backwards compatible solution is possible?

[garrittg]

thanks for the reply 3p although i dont think its going to help me. i was essentially looking for something to help with my quaternion based turn code. currently im using a matrix-based method but it gets gimble lock. i know quaternions are what i need to use but i have yet to come up with a functioning turn routine that will initialize the quaternion with the current node matrix rotation, incrementally turn the quaternion by a certain yaw/pitch/roll, and then set the new node rotation using setRotation(). ive been working with this post:

http://irrlicht.sourceforge.net/phpBB2/ ... ion+rotate

and this article:

http://www.gamedev.net/reference/articl ... le1095.asp

but the final solution still evades me

[3p]

garritg: If I am not mistaken, that might be, because you finally set new rotation by setRotation, which operates by euler angles... So again, if first angle is 90 degrees... As I see it there is no way around this in current version of Irrlicht, because node rotation is stored in euler angles, and node's matrix is calculated from that...

rogerborg: I'm not certain, yet. Of course using backwards compatible interface (setRotation, getRotation) will, in case I can make it work at all, still give you gimabal locks, but would not break your code. You would have to use setOrientation, getOrientation (quaternion parameters) to gain advantage.

[3p]

I'm giving up on this. I managed to "fix" scene node and cameras (no extra target or position needed anymore and no gimbal locks - but not 100% implemented), but every change I make breaks more things elsewhere.... I have succeded in messing up some animators and collision detection. I'm not sure how much time fixing this would take me (i'm new to irrlicht).

But I'm now even more sure, this (quat orientation in scene node) is the way to go (or maybe replacing whole orientation/translation/scale with a relative transformation matrix) for upcoming releases of irrlicht engine, if anyone is willing to do it...

[vitek]

But I'm now even more sure, this (quat orientation in scene node) is the way to go for upcoming releases of irrlicht engine, if anyone is willing to do it...

Yup. You are absolutely right.

or maybe replacing whole orientation/translation/scale with a relative transformation matrix.

I don't really see a big benefit in doing this. If this is done, then it becomes expensive to extract the rotation and scale out of this matrix. Of course the way it is it is a little expensive to get the relative transform because you need to assemble two matrices [one translate/rotate matrix and one scale matrix], and then multiply them.

I'm using an old modified version of Irrlicht at home and I'm in the process of changing the rotations over to using quaternions and making the quaternion a bit more user friendly. I'm also adding a caching scheme to avoid recalculating the absolute transformation for scene nodes that haven't moved.

Travis

[rogerborg]

Why, oh why, can't I get the A-Team tune out of my head now?

[vitek]

The quaternion would be pretty useful, but I'm sure the change will require a break in source compatibility somewhere. If, er when, I do finish this, I don't know how useful it will be. I'm using Irrlicht 1.2, so there are quite a few diffs between my code and trunk.

Back to you Hannibal.

Travis