Paul Turowski

When using rotatexyz, a change in rotation around the X axis doesn't affect the orientation of the Y and Z axes; the Y axis is always up and down and Z is always front to back. However, a change in rotation in the Y axis does affect the X axis orientation, but not Z. Furthermore, a change in the Z axis affects the orientation of both X and Y axes. What I would like to do is have rotation be completely relative. In other words, I want the X value of rotatexyz to always flip top to bottom in relation to the camera, regardless of Y and Z values. I've been trying to work around this strange behavior of rotatexyz and can't seem to wrap my head around it. Is there a way to keep rotation strictly relative to the camera? Attached is a basic patch to test what I've described.

When using rotatexyz, a change in rotation around the X axis doesn't affect the orientation of the Y and Z axes; the Y axis is always up and down and Z is always front to back.  However, a change in rotation in the Y axis does affect the X axis orientation, but not Z.  Furthermore, a change in the Z axis affects the orientation of both X and Y axes.  What I would like to do is have rotation be completely relative.  In other words, I want the X value of rotatexyz to always flip top to bottom in relation to the camera, regardless of Y and Z values.  I've been trying to work around this strange behavior of rotatexyz and can't seem to wrap my head around it.  Is there a way to keep rotation strictly relative to the camera?  Attached is a basic patch to test what I've described.

gridshape-rotatexyz-behavior

Sorry, I can't check your patch on this computer but it sounds like your describing a type of "gimbal lock"? Can you add another gimbal(degree of freedom)? There are objects for easy conversion to quaternions.

After some more research I can say it is totally the "gimbal lock" problem and I believe I can achieve what I want in my patch using quaternions. Thanks for pointing me in the right direction. :)

By the way, I stumbled across this in my searching and had my mind blown:

Probably old news to most of you forum folks, but I thought it couldn't hurt to spread the word to those who haven't seen it yet and stumble upon this post. Amazing work Wes and Graham!

After some more research I can say it is totally the "gimbal lock" problem and I believe I can achieve what I want in my patch using quaternions.  Thanks for pointing me in the right direction.  :)

Probably old news to most of you forum folks, but I thought it couldn't hurt to spread the word to those who haven't seen it yet and stumble upon this post.  Amazing work Wes and Graham!


Hey Paul, I think I'm having the same problem. Don't know where to start - quaternions?

Any direction / help would be appreciated

Hey Paul, I think I'm having the same problem.  Don't know where to start - quaternions?
Any direction / help would be appreciated


jitter has changed a lot since 2010. what are you trying to do and what's not working?

Yes, it has changed! I've been reading through the tutorials and there are a few inconsistencies and out dated statements I've come across. I can point those out but first my original question. I'm basically trying to use my PS3 to control grid shape position and rotation. I can successfully rotate around each individual axis, but I really like how the jit.handle object seems to be dealing with "Euler angle" type calculations manipulating the sum of the three axes at once. (Angle float, float, float). I'm looking for direction as to understanding the calculations behind that.

Yes, it has changed! I've been reading through the tutorials and there are a few inconsistencies and out dated statements I've come across.  I can point those out but first my original question.  I'm basically trying to use my PS3 to control grid shape position and rotation.  I can successfully rotate around each individual axis, but I really like how the jit.handle object seems to be dealing with "Euler angle" type calculations manipulating the sum of the three axes at once. (Angle float, float, float).  I'm looking for direction as to understanding the calculations behind that.


Some dated / inconsistent statements I've come across in the Jitter tutorials.

under the heading 'Setting a jit.matrix Destination'

"When drawing into jit.window objects or jit.pwindow objects, the hardware renderer can be used. Unfortunately, due to limitations of the current system software (Mac OS 9) the hardware renderer cannot draw directly into jit.matrix objects."

Same tutorial , under the heading 'Multiple Renderers and Drawing Order'

"You should see a yellow circle within a blue circle in the topmost drawing destination."

This doesn't happen. I think it's because @depthbuffer seems to be set to 1 as default.

"On first inspection, the third example patch may not seem a lot more complicated than the previous one. But don't be fooled -- this unassuming patch will bring even the speediest computer to its knees.

Click the message box countdown.mov to load a movie into the jit.qt.movie object, start the metro object by clicking on the toggle box connected to its inlet and watch the jit.fpsgui object's framerate output display located at the bottom of the patch. If you get more than 10 fps, you have a much nicer computer than we do."

Tutorial 31: Rendering Destinations
under the heading 'Setting a jit.matrix Destination'
"When drawing into jit.window objects or jit.pwindow objects, the hardware renderer can be used. Unfortunately, due to limitations of the current system software (Mac OS 9) the hardware renderer cannot draw directly into jit.matrix objects."

Same tutorial , under the heading 'Multiple Renderers and Drawing Order'
"You should see a yellow circle within a blue circle in the topmost drawing destination."

This doesn't happen.  I think it's because @depthbuffer seems to be set to 1 as default.

and (this one is just nostalgic)
Tutorial 19: Recording QuickTime movies
under the heading 'Off the clock'
"On first inspection, the third example patch may not seem a lot more complicated than the previous one. But don't be fooled -- this unassuming patch will bring even the speediest computer to its knees.
Click the message box countdown.mov to load a movie into the jit.qt.movie object, start the metro object by clicking on the toggle box connected to its inlet and watch the jit.fpsgui object's framerate output display located at the bottom of the patch. If you get more than 10 fps, you have a much nicer computer than we do."


you may be interested in the jit.anim.node and jit.anim.drive objects, specifically the turn message, and the animmode attribute.

yes. if you want to render a scene to a matrix using hardware, use jit.gl.asyncread.

This doesn’t happen. I think it’s because @depthbuffer seems to be set to 1 as default.

This vid is informative for those interested

https://www.youtube.com/watch?v=zc8b2Jo7mno

Thanks Rob, I'll check out those objects.

Thanks Phiol, that video shed some light on the subject.

Thanks Rob, I'll check out those objects.
Thanks Phiol, that video shed some light on the subject.


gridshape rotatexyz behavior