Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
If you rotate some amount around the X axis, some amount around the Y axis, undo the X-axis rotation then undo the Y-axis rotation, you won't get back to the same place. Take off a shoe and try it. In other words, what you are describing is just not compatible with how 3D rotations work.
Perhaps you can describe what kind of game you are trying to build, or give us the name of some game whose mechanics you would like to imitate.
Ok. I understand that I can't get back using the first way.
In some responses I saw that some of you asked what I'm trying to accomplish when I asked which way should I use. In what situations should I use the first way and in which should I use the second way?
And I'm not building/imitating a game. I'm creating a game engine.
6 hours ago, Orella said:Well. As I said. I want to totate the GameObects, and rotate them around the corresponding axis as you can see in the first way but allowing to rotate them back regardless the rotation order.
Doesn't this mean you want to convert from a global space rotation to the local space? So that rotating around X is always the same no matter what direction the object is looking at?
10 hours ago, Orella said:In some responses I saw that some of you asked what I'm trying to accomplish when I asked which way should I use. In what situations should I use the first way and in which should I use the second way?
And I'm not building/imitating a game. I'm creating a game engine.
This is tangentially sort of why write games, not engines gets thrown around a lot. There's no perfect way to represent rotations without knowing what sort of problem you are trying to solve, and as such an engine shouldn't be proscriptive about this.
Expose whatever the raw unit of rotation is (i.e. the quaternion itself) in code, and let the users figure out how to achieve the rotations they need. As for the UI manipulation, use whatever feels natural to you, and folks will live with it.
as others have already said, there is nothing really wrong with the results you are getting and is perfectly logical once you truly understand how transformations work... BUT... to address what I understand is what you are trying to accomplish, a game engine (and by extension its editors) will usually CHOOSE a defined order to pick rotation axes... for instance, choose to do EULER rotations always using yaw angle first, then pitch and finally roll, and store those values to create a single final rotation matrix (not applying little rotations incrementally)... this way you can simply set the values in ANY order you want and still have a consistent rotation applied.
1 hour ago, Jihodg said:choose to do EULER rotations always using yaw angle first, then pitch and finally roll, and store those values to create a single final rotation matrix
Or let the user chose the X,Y,Z order like Blender does.
(Sometimes, however, the math library (e.g. DirectXMath) has a preference which has way more ready-to-use support/utilities than the others.)
I looks like the problem is one of user interface.
Typically, the way rotations are expressed, are through a transform off identity. Whenever you change a widget, a brand new orientation is created, and the transformation matrix is re-calculated from scratch.
It sounds like you are trying to calculate transformation using increments -- i e, After you rotate X 50 and Y 30, you then keep the result of that, and apply X - 50 to the end of whatever the previous rotation was. This is not how modeling UIs work. Modeling UIs start with 0, and then re-create the rotation matrix from identity each time you update the input parameters. You will note that, if you do this, you will also end up at "identity" when X and Y are back to zero.
In general, the only case where you need incremental rotation is in a physics engine, and when you keep incremental rotations, you have to be very careful to re-normalize the quaternion (or re-orthonormalize the matrix) between each step, or you will suffer build-up of skew.
There's also a question of where the point of reference is. Either the point of reference is the local object, or the point of reference is the world. You will express the same rotation differently, depending on how you think about it. (This is why you have to invert most scene graph matrices to create the model matrix you use for rendering.)
Ok. Thank you for all the answers. I'll choose the second way, not the "Incremental" one.
Just to be clear, that choice is appropriate for some genres and not others. Implementing something like the game X-Wing or Descent with Euler angles would be a nightmare.
