little update (if anyone's checking )

i've been tweaking it heaps, and quatRad will now let you rotate an object by approximately 0.02 degrees

the zip file hasn't been updated yet as i'm still working on little improvements, but i'll post here as soon as i've uploaded the latest version.

julz

Excellent contribution!

I did some tests using your code--- converting level space to view entity space and trying to get an object in each to overlap. This provides good feedback on what is happening, as you know where the object should be (versus where it is) for any given position and orientation.

I encountered two problems. One is that there are singularities (where the object flips orthogonal to where it should be at a particular values), and I found it possible to lock the tilt in such a way that the object pretty much stays flipped until the tilt is changed. You might be able to solve this by adding a gimbal lock check to ang_for_quat. (I have to check, but this may only occur when rotating about multiple axes).

The other seems to occur only when rotating about multiple axes. Getting the orientations of the entities to match between the level space and view space should look something like this: (maybe there is a conceptual error on my part?)

Quote:

---

//get the entity orientation
vec_set(temp_angle2,temp_entity2.pan);
quat_for_ang(quaternion2,temp_angle2);
quat_to_unit(quaternion2);
//rotate by pan
vec_set(temp_angle1,vector(-camera.pan,0,0));
quat_for_ang(quaternion1,temp_angle1);
quat_to_unit(quaternion1);
quat_multiply(quaternion2,quaternion2,quaternion1); //also tried q1 by q2
//rotate by tilt
vec_set(temp_angle1,vector(0,-camera.tilt,0));
quat_for_ang(quaternion1,temp_angle1);
quat_to_unit(quaternion1);
quat_multiply(quaternion2,quaternion2,quaternion1);
//rotate by roll
vec_set(temp_angle1,vector(0,0,-camera.roll));
quat_for_ang(quaternion1,temp_angle1);
quat_to_unit(quaternion1);
quat_multiply(quaternion2,quaternion2,quaternion1);
//update entity orientation
ang_for_quat(temp_angle1,quaternion2);
vec_set(temp_entity1.pan,temp_angle1);

---

The entity orientations match well when the camera angles are in the first quadrant, but they flip or become constrained by 180 degrees (oscillatory) in the other quadrants. The behavior I was trying to duplicate looks like this:

Quote:

---

vec_set(temp_angle1,temp_entity2.pan);
vec_set(temp_angle2,vector(-camera.pan,0,0));
ang_add(temp_angle1,temp_angle2);
vec_set(temp_angle2,vector(0,-camera.tilt,0));
ang_add(temp_angle1,temp_angle2);
vec_set(temp_angle2,vector(0,0,-camera.roll));
ang_add(temp_angle1,temp_angle2);
vec_set(temp_entity1.pan,temp_angle1);

---

I'd love to see SLERP implemented, by the way!

i don't need SLERP for my project, so it isn't a big priority. however, i would be interested in implementing it later.

some of those problems sound like problems i've had when multiplying quaternions the wrong way:
to rotate quaternion2 by quaternion1, use "quat_multiply(quaternion2,quaternion1,quaternion2);"
it might actually be worth writing a function "quat_rotate(q1,q2)" which basically uses quat_multiply to rotate q1 by q2, but without any possibility of logic errors on the programmer's behalf. the quat_multiply system isn't quite intuitive when doing rotations, but it IS how a multiplication actually works.

after that changing the multiplications, try again (though you appear to mention trying this change...)

i'm not an expert so i don't really see how gimbal lock would be possible with quaternions.

i've seen some slight jittering or inaccuracies with certain angles, which i've mostly been able to associate with my custom atan2 -- jcl said a more accurate built-in atan2 will be implemented in a future update.

i'm glad you're giving this a go i'm mostly using quaternions for custom physics (the need for angle-axis rotation instead of pan/tilt/roll).

let me know if there are any more problems or they still persist -- i've been doing a lot of stuff with them and havevn't had any problems more than slight inaccuracies (quaternions remain accurate, just the euler representation that's off) and small jitters

julz

I'm converting quatRad to c-script for Portico.

If anyone has a need for a c-script version, I'll post it "as-is" with Julz approval

this looks like exacly what I need, too bad I don't understand it

G'day Carlos,

Did you have a look at the readme? If I recall it explains how things work. It's been a while, though. The first post just has a .c file -- look a little further down to find a .zip with everything you need in it.

@xXxGuitar511 if you ever come back to this thread -- How'd the conversion go?

I was Googling myself and tried "JulzMighty", and came across this thread, scanned through for nostalgia's sake, and was quite surprised to find a post-2007 post, and another one in the last month!

Jibb

oh, you are still here JulzMighty =)
wanted to say thanks for your great job =)

Thanks mate!

I was just looking through it expecting to see something embarrassing (I've done 1.5 years of uni since then). Nothing really stands out, thankfully. These holidays I'll probably fiddle around with it some more, utilize Lite-C's atan2, and look into slerp.

Jibb

Julz - I was just thinking about putting some sort of quat into a project, and really should have thought to do a search on here.

I for one will be very interested in any update you make; keep us updated.

Don
have a great day

I have exams for the next week and won't be able to do anything else until afterwards, but yesterday and today I was making an example for LunaticX and came across some problems and inaccuracies that I didn't pick up on back in the old days when I first wrote quatRad.c and quaternions.c.

I got the example working (really nothing special), and so next week I'll begin re-writing those functions, hopefully adding more (slerp), and making some nice, simple examples as well.

Jibb