Is there any possibility to limit quaternions to move only in x & y axis (like in Eulers- yaw and pitch, without rolling)? I's there any equation or something similar to do this?
Some example:
Movement should behave like this: http://360.art.pl/experimental/1/
But when I build my player on quaternions it have no limits and I don't know how to fix it http://360.art.pl/experimental/2/
|
|
|||||||||||
|
|
Don't use quaternions. Store yaw and pitch Euler angles, and convert to a quaternion if you need to (for supplying to another piece of code, for example). There are no real advantages to using a quaternion like this (this set up cannot get into a gimbal lock, for example). If you feel the need to use a quaternion, use two: one to represent the pitch and one to represent the yaw. If you ever permanently compose them, you'll have to decompose them at some point to apply the constraints. (Note that two quaternions, one for pitch and one for yaw, is really just obfuscated Euler angles.) |
|||||||
|
|
UPDATE: As pointed out in one of the other answers, you could use Euler angles. Actually, when analyzing the solution given in the first web application, we can see that this is how they do it. They're computing latitude and longitude (spherical coordinates) and from then on, they move by rotating a gimbal rig. You can picture this imagining that the z axis of a frame is pointing towards the ceiling and NEVER moves (can only rotate in place, spinning). Now, you weld an y axis to this z one and let that axis support a ring. Z and Y must be perpendicular. Denote a point X on the cross product end of YxZ. That's where your camera can point. Now try to derive the mathematical equations that allow you to cover the whole sphere by first rotating against the Z, then against the Y axis. REMEMBER: the Y axis has rotated as well, so it's not correct to name it (0,1,0) or whatever convention you have for a world axis. It's actually something in the likes of (cos(t), sin(t), 0), where t is the longitude coordinate of a spherical coordinate system. On the other hand, Z does remain fixed and you can call it (0,0,1) (or, again, whatever convention you choose). Mathematically, to rotate the camera you can first apply a rotation R_z(deltaLongitude) followed by an R_Y(currentLongitude) (endLongitude - currentLongitude). longitude is an angle in radians, in the [0, pi) interval, whereas latitude is in the (0, pi) interval. The only advantage of this rotation system is that it's easier for the human brain to accommodate to: it's pretty much how our head pan/tilts. Our entire body, perpendicular on the ground is the Z axis I was talking about, while the Y axis is free to rotate perpendicular to this axis (picture it as the your shoulder line when it is in its rest position :D). Quats are very similar to an angle-axis representation, nothing more. So if you apply a quat, you imply that the result is the input rotated against the quat's axis by the specified angle. What does that tell us? It tells me this: that the quat's axis must be perpendicular to the camera's lookat axis in order to not rotate the camera against this look at ray. If the axes are not perpendicular, there will be a roll component taking its toll, and hence the OPs problem. If required, I could provide further details (a 3D rep maybe?). This link does explain a trackball rotation concept and how to implement it.. |
|||||||
|