Hello All

I have implemented ArcBall Rotation Control, Revisited By Terence J. Grant (tjgrant@tatewake.com) Lesson 47

with my own textures successfully

How does one figure out the exact roll / pitch / yaw of the final object [the globe?]

I tried from GL_MODELVIEW_MATRIX with inconsistent results

I also tried GLUUNPROJECT - confusing

How can I keep track of the exact axes [double precision] for some post-arcball mathematics I have in mind

Season's Greetings & Happy New Year 2017

Frankie

I don't know the lesson, so I don't know what you're talking about, but one solution is to keep that data in your code, and from it, derive the matrices to display the object.

That is, do it the other way around. Have the axes data, and compute visualization from it.

This in turn raises the question if you can get the axes data from your input. Due to my lack of knowledge about your lessons, I cannot answer that unfortunately.

It's lesson #48 in the NeHe archive here.

The current axis and angle exist temporarily during dragging the mouse, but in the end all rotations (means a couple of click-drag-release cycles) are accumulated in a rotation matrix. If the overall rotation angles should be extracted from the matrix, then some kind of matrix decomposition has to be done. Such a decomposition depends on how one defines a formula that expresses the composition.

Ah, thanks for finding the lesson. Looks interesting, I think I was looking for an example of such code. Too bad the "drag" code isn't there.

However, "arcball drag" produced a paper describing it https://www.talisman.org/~erlkonig/misc/shoemake92-arcball.pdf which seems useful.

Given the use of quaternions, I agree that reverse engineering the rotations from the transformation matrix is the way to go.

After some pondering about it, it may be less difficult than it seems. That matrix transforms anything, including unit vectors with 0 yaw, 0 roll, or 0 pitch. The simple straight-forward way is to construct those vectors, apply the transform matrix on them, project the result vector onto the plane you are looking at (so both the input vector and the result vector are in the same plane), compute the angle between the original vector and the projected vector, and you're done.

[Everything below is untested, but afaik it should work]

More concretely, let's assume a xyz space, with Z going up, ie yaw rotation is around the Z axis. Also, let's assume 0 yaw is the U = (1, 0, 0) vector (vector should be in the Z=0 plane, for the angle computation to make sense). Apply this to the transformation matrix [1]. Let's assume the answer is (a, b, c). For the yaw, we project the vector to the Z=0 plane, ie vector Y = (a, b, 0).

The angle is computed with the dot-product. Since the dot-product uses length of the vectors, let's normalize Y too (U is already normalized), and create vector Y' with length 1: Y' = normalize(Y) = (d, e, 0). Note this will fail if Y is the null vector. Now you can compute cos(yaw) with the dot product: cos(yaw) = dot(U, Y') = 1 * d + 0 * e + 0 * 0 = d (both U and Y' vectors have length 1, therefore dividing by length doesn't change the result). The yaw can be computed by taking acos(d).

[1] While you can apply the full Transform matrix to a unit vector like U, a simpler way to get the result is just take the the corresponding column of the matrix (x unit vector means 1st column, y unit vector 2nd column, z unit vector means 3rd column).

... Too bad the "drag" code isn't there.

It is there, although a bit hidden: Below the article from the download links.

It is there, although a bit hidden: Below the article from the download links.

Theoretically, you could use the quaternion to do the calculations I described (it's just a rotation, only described differently), which should give you additional rotation with each drag.

Maybe even both vectors used to construct the quaternion can be used, since those are also "before" and "after" rotation and should have the same angles relative to each plane of yaw/pitch/roll rotation. However, there are likely some edge cases there where you may not get a proper rotation angle for all three angles, just as in my code where you may end up with a null vector after projection.

Thank you everyone

I was hoping to find the opposite of this -> since we know the final rotation can we work in reverse?

void angleToCartesian(double rho, double phi, double theta) {

coords.x = rho * Math.sin(phi) * Math.cos(theta);
coords.y = rho * Math.cos(phi);
coords.z = rho * Math.sin(phi) * Math.sin(theta);

}

Can anyone post some code to convert the final view matrix to yaw/pitch /roll?

Can anyone post some code to convert the final view matrix to yaw/pitch /roll?

Unlikely to happen.

This forum is about you learning to program, which typically includes finding your way from problem to code.

In particular, learning to copy/paste complete coded solutions doesn't count as learning programming here.

Did you try my algorithm to convert the rotation transformation matrix?

Did it work? Is it broken? Is it incomplete? Is it not understandable? Is it not what you are looking for?

Is there something else?

Edit: Rereading your last post, maybe we should discuss why you want to have rotation angles?

I have started to learn that rotation matrices and quaternions are much more efficient representations of rotations, and you should suppress ideas about converting back to angles as much as possible.

I was hoping to find the opposite of this -> since we know the final rotation can we work in reverse?

The mentioned keywords are "rotation matrix decomposition". Putting these into an internet search engine provides you with explanations, formulas, and also code.

However, as is also already indicated, the solution depends on how the axes and order of rotations is defined (together giving the composition of the total rotation matrix). Even the terms yaw / pitch / roll are not ever used clearly. So copying any given code may give results that are wrong for your situation.

void angleToCartesian(double rho, double phi, double theta)

This stuff is a conversion from spherical co-ordinates to cartesian co-ordinates (although using the greek letter rho for the radius / distance is somewhat misleading, since greek letters are by convention often used for angles). There is of course a reverse way as described e.g. here.

However, this is not the same as Euler angles, because spherical co-ordinates describe a position while Euler angles describe an orientation! Notice the mismatch of the radius / distance on the one side and the roll on the other side.

Can anyone post some code to convert the final view matrix to yaw/pitch /roll?

The view matrix is probably not even what you want to decompose. Traditionally the view matrix is the transformation from the world space into the camera space.

Not offending, but Alberth's

This forum is about you learning to program, which typically includes finding your way from problem to code.

is really what you should consider. Without an understanding of what the used code does, your project is about to fail rather sooner than later.

So ... what exactly is the "post-arcball mathematics" you want to do?

[attachment=34322:e.jpg][attachment=34323:e2.JPG]

Thanks for your help every one - I solved it

The final matrix does indeed carry enough information - the problem was in resolving ambiguities

It's a fascinating problem

[attachment=34324:e.jpg][attachment=34325:e2.JPG]