Background:
I am currently implementing a skeletal animation shader in GLSL, and to save space and complexity I am using Quaternions for the bone rotations, using weighted quaternion multiplication (of each bone) to accumulate a "final rotation" for each vertex.
Something like: (pseudo-code, just assume the quaternion math works as expected)
float weights[5];
int bones[5];
vec4 position;
uniform quaternion allBoneRotations[100];
uniform vec3 allBonePositions[100];
main(){
quaternion finalQuaternion;
for(i=0;i<5;i++){finalQuaternion *= allBoneRotations[bones[i]]*weights[i];}
gl_position = position.rotateByQuaternion(finalQuaternion);
}
The real code is complicated, sloppy, and working as expected, but this should give the general idea, since this is mostly a math question anyway, the code isn't of much consequence, it's just provided for clarity.
Problem:
I was in the process of adding "pivot points"/"joint locations" to each bone (negative translate, rotate by "final quaternion", translate back) when I realized that the "final quaternion" will not have taken the different pivot points into account when combining the quaternions themselves. In this case each bone rotation will have been treated as if it was around point (0,0,0).
Given that quaternions represent only a rotation, it seems I'll either need to "add" a position to the quaternions (if possible), or simply convert all of the quaternions into matrices, then do matrix multiplication to combine the series of translations and rotations. I am really hoping the latter is not necessary, since it seems like it would be really inefficient, comparatively.
I've searched through mathoverflow, math.stackexchange, and whatever else Google provided and read the following resources so far in hopes of figuring out an answer myself:
http://shankel.best.vwh.net/QuatRot.html
http://mathworld.wolfram.com/Quaternion.html
plus various other small discussions found through Googling (I can only post 2 links)
The consensus is that Quaternions do not encode "translation" or "position" in any sense, and don't seem to provide an intuitive way to simulate it, so pure quaternion math seems unlikely to be a viable solution.
However it might be nice to have a definitive answer to this here. Does anyone know any way to "fake" a position component of a quaternion, that in some way that would keep the quaternion math efficiency, or some other method to "accumulate" rotations around different origin points that is more efficient than just computing the matrix of the quaternions, and doing matrix translation and rotation multiplications for each and every quaternion? Or perhaps some mathematical assurance that differing pivot points don't actually make any difference, and can, in fact be applied later (but I doubt it).
Or is using quaternions in this situation just a bad idea on the face of it?
Indeed, there is no such thing as a position component of a quaternion, so you'll need to track it separately. Suppose individual transformations end up being like
x' = R(q)*(x-pivot)+pivot = R(q)*x + (pivot-R(q)*pivot) = R(q)*x+p,
where q is your quaternion, R(q) is the rotation matrix built from it, and p=pivot-R(q)*pivot is the position/translation component. If you want to combine two such transformations, you can do it without going full-matrix multiplication:
x'' = R(q2)*x'+p2 = R(q2)*R(q)*x + (R(q2)*p+p2) = R(q2*q)*x + (R(q2)*p+p2).
This way the combined quaternion will be q2*q, and the combined position, R(q2)*p+p2. Note that you can even apply quaternions to vectors (R(q2)*p and so on) without explicitly building rotation matrices, if you want to absolutely avoid them.
That said, there is also a notion of "dual quaternions" which, in fact, do contain a translation component, and are presumably better for representing screw motions. Check them out on Wiki, and here (the last link also points to a paper).
After extensive additional searching, and reading more about quaternions than any sane person should, I finally discovered my answer here:
http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/other/dualQuaternion/index.htm
It turns out Dual Quaternions operate similarly to actual quaternions, with many of the mathematical operations based off of regular quaternion math, but they provide both orientation, and displacement both, and can be combined for any rotation-translation sequence needed, much like Transformation Matrix multiplication, but without the shear/scale ability.
The page also has a section that derives exactly the "rotating around an arbitrary point" functionality that I was requiring by using dual quaternion multiplication. Perhaps I should have researched a bit more before asking, but at least the answer is here now in case anyone else comes looking.
Related
I'm working in the revitalization of an old 3d game (built using Direct3D) and I'm struggling with the game objects animations.
The game has its objects animations stored in binary files that contains transformation matrices for each bone of its meshes at each frame of the animation (in the form of an array of D3DMATRIX).
I've tried using the D3DXMatrixDecompose function to get the position, rotation and scale but it seems that something is wrong with the animation. Some animations almost matches the originals, but there are some strange rotations in the middle of the animations (the scale vector goes from negative to positive values and that causes the whole bone to rotate in an strange way - it is definitely wrong) and for other animations the whole thing is wrong.
I read somewhere that the function D3DXMatrixDecompose assumes the matrix was composed as a SRT matrix and apparently the order in which each component was combined in the matrix matters. So, as the animations are clearly wrong I'm assuming maybe the matrices were not composed in the SRT order and the output of D3DXMatrixDecompose is wrong.
I didn't find much material to read about this without going very deep on math. As I don't have a strong background on math, hopefully someone can point me in the right direction.
So, how can I decompose position, rotation and scale of an unknown transformation matrix? I'm not asking for a unique algorithm that can do that, I'm asking what I can do in this scenario to find the original (or equivalents) values for the position, rotation and scale of each matrix.
Thanks in advance!
I have a 3D point in space, and I need to know how to pitch/yaw/roll my current heading (in the form of a 3d unit vector) to face a point. I am familiar with quaternions and rotation matrices, and I know how to represent the total rotation necessary to get my desired answer.
However, I only have control over pitch, yaw, and roll velocities (I can 'instantaneously' set their respective angular velocities), and only occasional updates on my new orientation (once every second or so). The end goal is to have some sort of PID controller (or three separates ones, but I suspect it won't work like that) controlling my current orientation. the end effect would be a slow (and hopefully convergent) wobble towards a steady state in the direction of my destination.
I have no idea how to convert the current desired quaternion/rotation matrix into a set of pitch-yaw-roll angular velocities (some sort of quaternion derivative or something?). I'm not even sure what to search for. I'm also uncertain how to apply a PID controller to this system, because I suspect there will need to be one controller for the trio as opposed to treating them each independently (although intuitively I feel this should be possible). Can anyone offer any guidance?
As a side note, if there is a solution that just involves a duo (pitch/yaw, roll/pitch, etc), then that works just fine too. I should only need 2 rotational degrees of freedom for this, but that is further from a realm that I am familiar with so I was less confident forming the question around it.
First take a look if your problem can be solved using quaternion SLERP [1], which can let you specify a scalar between 0 and 1 as the control to move from q1-->q2.
If you still need to control using the angular rotations then you can calculate the error quaternion as Nico Schertler suggested.
From that error quaternion you can use the derivative property of the quaternion (Section 4 of http://www.ecsutton.ece.ufl.edu/ens/handouts/quaternions.pdf [2]) to work out the angular rates required.
I'm pretty sure that will work, but if it does not you can also look at using the SLERP derivative (eq. 23 of http://www.geometrictools.com/Documentation/Quaternions.pdf [3]) and equating that to the Right-Hand-Side of the equation in source [2] to again get angular rates. The disadvantage to this is that you need code implementations for the quaternion exponentiation and logarithm operations.
I am currently teaching myself linear algebra in games and I almost feel ready to use my new-found knowledge in a simple 2D space. I plan on using a math library, with vectors/matrices etc. to represent positions and direction unlike my last game, which was simple enough not to need it.
I just want some clarification on this issue. First, is it valid to express a position in 2D space in 4x4 homogeneous coordinates, like this:
[400, 300, 0, 1]
Here, I am assuming, for simplicity that we are working in a fixed resolution (and in screen space) of 800 x 600, so this should be a point in the middle of the screen.
Is this valid?
Suppose that this position represents the position of the player, if I used a vector, I could represent the direction the player is facing:
[400, 400, 0, 0]
So this vector would represent that the player is facing the bottom of the screen (if we are working in screen space.
Is this valid?
Lastly, if I wanted to rotate the player by 90 degrees, I know I would multiply the vector by a matrix/quarternion, but this is where I get confused. I know that quarternions are more efficient, but I'm not exactly sure how I would go about rotating the direction my player is facing.
Could someone explain the math behind constructing a quarternion and multiplying it by my face vector?
I also heard that OpenGL and D3D represent vectors in a different manner, how does that work? I don't exactly understand it.
I am trying to start getting a handle on basic linear algebra in games before I step into a 3D space in several months.
You can represent your position as a 4D coordinate, however, I would recommend using only the dimensions that are needed (i.e. a 2D vector).
The direction is mostly expressed as a vector that starts at the player's position and points in the according direction. So a direction vector of (0,1) would be much easier to handle.
Given that vector you can use a rotation matrix. Quaternions are not really necessary in that case because you don't want to rotate about arbitrary axes. You just want to rotate about the z-axis. You helper library should provide methods to create such matrix and transform the vector with it (transform as a normal).
I am not sure about the difference between the OpenGL's and D3D's representation of the vectors. But I think, it is all about memory usage which should be a thing you don't want to worry about.
I can not answer all of your questions, but in terms of what is 'valid' or not it all completely depends on if it contains all of the information that you need and it makes sense to you.
Furthermore it is a little strange to have the direction that an object is facing be a non-unit vector. Basically you do not need the information of how long the vector is to figure out the direction they are facing, You simply need to be able to figure out the radians or degrees that they have rotated from 0 degrees or radians. Therefore people usually simply encode the radians or degrees directly as many linear algebra libraries will allow you to do vector math using them.
I am quite new to this, and iv'e heard that i need to get my inversed projection matrix and so on to create a ray from a 2D point to a 3D world point, however since im using OpenglES and there are not as many methods as there would be regulary to help me with this. (And i simply don't know how to do it) im using a trigenomeric formula for this insted.
For each time i iterate one step down the negative Z-axis i multiply the Y-position on the screen (-1 to 1) with
(-z / (cot(myAngle / 2))
And the X position likewise but with a koefficent equally to the aspect ratio.
myAngle is the frustum perspective angle.
This works really good for me and i get very accurate values, so what i wonder is: Why should i use the inverse of the projection matrix and multiply it with some stuff instead of using this?
Most of the time you have a matrix lying around for your OpenGl camera. Using an inverse matrix is simple when you already have a camera matrix on hand. It is also (oh so very slightly at computer speeds) faster to do a matrix multiply. And in cases where you are doing a bajillion of these calculations per frame, it can matter.
Here is some good info on getting started on a camera class if you are interested:
Camera Class
And some matrix resources
Depending on what you are working on, I wouldn't worry too much about the 'best way to do it.' You just want to make sure you understand what your code is doing then keep improving it.
So I have written a Quaternion based 3D Camera oriented toward new programmers so it is ultra easy for them to integrate and begin using.
While I was developing it, at first I would take user input as Euler angles, then generate a Quaternion based off of the input for that frame. I would then take the Camera's Quaternion and multiply it by the one we generated for the input, and in theory that should simply add the input rotation to the current state of the camera's rotation, and things would be all fat and happy. Lets call this: Accumulating Quaternions, because we are storing and adding Quaternions only.
But I noticed that there was a problem with this method. The more I used it, even if I was only rotating on one Euler angle, say Yaw, it would, over some iterations, begin bleeding over into another, say Pitch. It was slight, but fairly unacceptable.
So I did some more research and found an article stating it was better to accumulate Euler angles, so the camera stores it's current rotation as Euler angles, and input is simply added to them each frame. Then I generate a Quaternion from them each frame, which is in turn used to generate my rotation matrix. And this fixed the issue of rotation bleeding into improper axes.
So do any Stackoverflow members have any insight into this problem? Is that a proper way of doing things?
Multiplying quaternions is going to suffer from accumulation of floating-point roundoff issues (even simple angles like 45 degrees won't be exact). It's a great way to composite rotations, but the precision of each of your quaternion components is going to drop-off over time. The bleed-through is one side-effect, a visually worse one though is your quaternion could start incorporating a scale factor - to recover that, you'd have to renormalize back to Euler angles in any case. A fixed-point Euler angle isn't going to accumulate roundoff.
Recalculating the quaternion per-frame is minimal. I wouldn't bother trying to optimize it out. You could probably allow a few quaternions to accumulate before you renormalized to get the accuracy back, but it really isn't worth the effort.
Accumulation is an inexact process. Accumulating lots of incremental rotations will accumulate roundoff error whether you do it with quaternions or matrices.
I imagine something like this: you got your code up and running, but noticed that after a certain amount of navigation your camera was heeling over annoyingly -- violating an invariant you hadn't thought of in advance. Effectively, you've realized you don't want to accumulate rotations; instead you want to do something else.
You can look at this as more of an interface design issue than a numerical accuracy issue. Basically, people expect a camera to navigate according to pitch, yaw, and roll, so choosing to control and represent the angles directly can avoid a lot of problems.
The bummer here is that the quaterions seem to have become redundant (for this particular usage, at least). You still want the quaternions, though -- interpolating with the raw pitch/yaw/roll angles can be ugly. Again, it's an interface design question: you need to figure out where you'll need the quaternions, and how to get them in and out...
I've seen both argued for. I think the real question you'll have to deal with is flexibility in your camera system down the line; IMO yaw is generally more interesting in a third-person view (because you're going to rotate about the character's vertical axis). While you can arguably "yaw" around the vertical in first-person view as well, I'm not sure it's really the same thing.
However, I do think it's kind of a waste to recalculate your quaternions per-frame. Perhaps it would be better to store the latest quaternions and mark them dirty if your frame receives input?