scene node rotation interface for quaternion

[kevin_shanghai]

Hi
Don't know why there is no rotation interface for quaternion in scene node?
will it be implemented in future?

Thanks!

[CuteAlien]

There are quaternion classes and conversion functions between quaternions and euler-angles and matrices. We need matrices in the end - that's what is used for graphic card transformations. That Irrlicht keeps internally the data as position, rotation, scale vectors is probably because that way it's possible to keep those values independent. There is a IDummyTransformationSceneNode which is about working directly with matrices instead of those 3 vectors. I guess it would be possible to have a IQuaternionTransformationSceneNode which works similar like that - but it still would have to return transformation matrices in the end. Putting it directly into ISceneNode would only be confusing (you don't want to update several independent variables in one of the most time-critical parts of a 3D engine unless you need to).

There is currently no plan for adding a IQuaternionTransformationSceneNode, but it would not be hard to implement. So if you need it in your code you can make a customscenenode for that. I don't know if it would be added to the engine (I'm not making those decisions for the core-parts), but I guess if you could show a concrete need for that and there's a good patch for it (with tests!) it might have a chance.

edit: It might have been interesting implementing the transformation part as template parameter ... but I guess that's more the kind of stuff to consider when writing a new engine.

[kevin_shanghai]

thanks for your reply.

Definitely it think there is need for this interface, euler can cause a problem of Gimbal lock.
In my program, i need to control the camera rotation, that's where the problem happens.

you can refer to this article, which provides implementation proposals in irrlight.
http://staraban.com/en/adding-quaternio ... ht-engine/

BTW, ogre supports rotation interface for quaternion, not for euler, that's better in my opinion.

[mongoose7]

The point is, you can use quaternions for rotation. Once you compute the rotation, convert the quaternion into Euler angles. There is no gimbal lock. Gimbal lock is caused by performing calculations in Euler angles, but you would be performing the calculations in quaternions.

[kevin_shanghai]

thanks,

the actual issue i have is that when i create a FPS camera and set the rotation with 90 degrees along X axis, the result is no as what i expected, when i set with less than 90 degrees, such as 89.9, it is ok.

I don' t why. i doubt it was caused by problem like gimbal lock, so i asked the question.

do you know the issue about this?

Thanks!

[thanhle]

I might be wrong.
For camera, you might need to update the new up vector.

[AReichl]

The solution in Irrlicht is not that bad.

What i could think of is a collection of utility / helper functions like the ones you find all over this and other forums ( e.g. "LookAtTarget(...)", "RotateAround???(...)", etc. ). It could be an independent module (or class) with only functions for calculating 3d orientation problems. Would not interfere with the rest of the engine and can be maintained independently.

For your consideration, something from the Ogre forum:
--------------------------------------------------------------------
"It's usually best to keep euler angles separate and generate the quaternion when needed, rather than extracting the euler from a quaternion. One reason is because a quaternion has a limit on it's angles (it can only represent a 720 degree rotation range), while euler is infinite. So there's potentially information loss when extracting."
--------------------------------------------------------------------

[kevin_shanghai]

thanks very much!