ISceneNode implementation and gimbal locks
ISceneNode implementation and gimbal locks
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?
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?
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.
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
There is not much to show. I just changed RelativeRotation in ISceneNode.h to:
Then modified setRotation and getRotation:
And made small modification to getRelativeTransformation, so it initializes matrix directly from quaternion:
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...
Code: Select all
core::quaternion RelativeRotation;
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;
}
Code: Select all
...
core::matrix4 mat;
mat = RelativeRotation.getMatrix();
...
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
I'm following this with interest, by the way. Do you think that a backwards compatible solution is possible?
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
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
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
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.
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.
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...
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...
Yup. You are absolutely right.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...
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.or maybe replacing whole orientation/translation/scale with a relative transformation matrix.
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
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
Why, oh why, can't I get the A-Team tune out of my head now?
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way