I didn’t explain why I wanted to make that.
Basically, I encountered the gimbal lock problem when I calculated azimuth/elevation for each object relatively to the cam. it happened for position when the object was up above, or under the cam (singularities of atan2 in the azimuth calculation)
Then, I wanted to go further and use quaternion.

The matrix to which I need to apply my quat rot is a global named matrix in which I have ALL my objects’ coordinates.
I doubt I could simplify it.

Attachments:

if it seemed to work, I tested and my azimuths aren't correct :-(
I tested just by looking by the jit.window… 180° or 0° would mean the object projection on cam plane is "in front of me"..
With 2 objects only, in order to not mess all, it doesn't work.

Before to forget about that part and to work on another part because of own saturation, here is exactly what I'm trying to do.
I hope a comprehensive saint guru wise dude could push me into the right way…

I need to calculate azimuth & elevation of objects relatively to my camera direction/plane.
Using only the 3 Euler angles to do that doesn't seem to be enough because of gimbal lock/singularities.

So I decided to go to quaternions.
I attached a snapshot.
I'm requesting position & quaternion in the scheduler (global qmetro)
I'm sending both + the objects matrix to the jit.gen.

Attachments:

I guess the quaternion I’m grabbing is not the good one … I don’t have other explanations and I wouldn’t have more (considering my fresh discovering of quaternion)

btw, I can add something which could sound like a clue.
if the cam is reset by anim_reset message, it came back to initial position BUT especially orientation.
In this orientation and if I stay in the plane of the cam (I mean if I don’t go a bit up or down but only forward/backward/left & right/panning left right, then my system works perfectly : azimuths are relevant etc.

The main point you should take note (in the while loop) is
- The orientation of the camera is a quaternion.
- There are 3 angles corresponding to the keypress. Note the angles are meant to be an on/off switch (not accumulative). I reset them inside the while loop. Of course this is not the best way to do it but as I said, it is a quick job.
- I convert the 3 angles to a temporary quaternion.
- I multiply the temporary quaternion to the camera quaternion to obtain the combined orientation. Note the order of multiplication.
- The camera rotation is then converted to the Axis Angle representation for transforming the final matrix.
When a key is pressed, I generate a temporary quaternion corresponding to the key for a small rotation in that particular axis. I then multiply the temporary quaternion into the camera quaternion. This concatenation of rotations in 4D space will avoid gimbal lock. Try it and see for yourself.

In my system, as shown on the patch picture, I’m grabbing the cam quaternion and this is that one I convert to matrix and I apply it to all my objects coordinates.
This is that resulting vector I’m taking for my atan2 based azimuth calculation.

I don’t use the temporary vector at all. Maybe my problem comes from here.
I don’t use it because my system provides me directly the quaternion from the cam.

An user answered me about the fact I didn’t use the temporary vector and it is very interesting for me :

That’s the key to avoiding gimbal lock. You need to have some representation of the current attitude and modify it with incremental rotations around the axes. Whether you use quaternions or some other representation is secondary.

If you keep track of a cumulative roll, pitch and yaw and then compose them into an overall rotation, you’ll run into gimbal lock regardless of what representation you use.

I’m not sure about "incremental rotations around axes"

Robert, how should I translate it into my system ?
I thought jit.anim.drive would do that.