Transforming a quaternion from 3ds max axes to Ogre axes?

[jfaust]

I'm trying to convert a PML file exported from 3ds max, and I'm wondering if anyone knows how to convert quaternions from Z-UP axes to Y-UP axes. It's *almost* right if I swap y and z, and negate w, but not quite. Anyone know how to do this?

Thanks

[jfaust]

Ok, I guess I don't need a math answer like I thought I did. If anyone else tries to do this, here's how:

float3 axis= quat.axis();
float angle= quat.angle();

swap(axis.y, axis.z);
axis.z= -axis.z;

quat = Quaternion(axis, angle);

This is using pmlib's Quaternion class, from the Novodex SDK.

[Chris Jones]

just wondering, why do 3d modelling programs use Z up instead of Y up? because i thought Y up was like a standard way axes are done?

[Raiden]

As far as I know the standard in maths/physics is using Z axis up, or at least in my country, so for me, the extrange thing is using the Y axis up in Ogre.
Anyway, it isn't a big problem once you get used to.


Bye!

[jfaust]

Yeah, Z-up with with +Y going into the screen is the standard in math/physics/art, but Y-up with -Z going into the screen is what OpenGL and DirectX (I think, correct me if I'm wrong about DX) use.

[Chris Jones]

when i did physics and maths ALevels we used Y up tho :S oh well

[Kojack]

Well,, when dealing with 2d on a computer, the screen is x and y. So when going to 3d, it makes sense to keep the x and y axes the same and make the z go into the screen (or out of the screen in ogre's case, but I prefer into).

But in software like autocad and stuff they probably deal with floor plans more, so moving to 3d means extruding upwards, so thats the z axis.

In real life, most positioning is relative to the ground, so the z axis becomes altitude.

At least that's how I always thought about it.

Oh yeah, I was working on a pml to novodex/ogre importer last week too, and got stuck on the quaternions.
Seems I got it right though, but stuffed up something else.

[jfaust]

When I get things "fully" working, I plan on posting the code here. I have convexes, trimeshes, capsules, boxes, spheres and joints working, so if any of those were your problem, I can post the relevant code.

[Kojack]

Got the boxes working fine with body and shape transforms. It was only a couple of stupid errors.

Now for everything else...

And then to link it to octopus in some way.

[madmark]

I get a Quat from an external device (A motion tracker) that has ZUP orientation. I simply swap z and w, negating both and it works fine. Positions have to have some terms swapped as well. Here is a snippet:

Code: Select all

	
m_vBufferVector[index].z  =  pFloats[0];
m_vBufferVector[index].x  =  pFloats[1];
m_vBufferVector[index].y  =  pFloats[2];			
m_qBufferQuat[index].x    =  pFloats[3];
m_qBufferQuat[index].y    =  pFloats[4];
m_qBufferQuat[index].w    = -pFloats[5];
m_qBufferQuat[index].z    = -pFloats[6];

[geekmaster]

"just wondering, why do 3d modelling programs use Z up instead of Y up? because i thought Y up was like a standard way axes are done?"

Back before we had these newfangled I/O devices on our desks, where the keyboard sits was a notepad (quadrilateral ruled, of course), and in our hand was a pencil (mechanical, of course, plus plenty of multi-colored pens in our handy pocket protector (i.e. "nerd pack"). And we had a slide-rule attached to our belt, so PI was just "3.14" back in those days...

When you drew the X axis on your paper on the desk in front of you, X was left and right. Then you plotted Y toward the top of the page (away from you) and toward the bottom of the page (toward you). And in the rare cases you needed to model in 3D with pipe-cleaners and/or toothpicks, that Z axis stuck up off your paper. Just like back in math class in the olden days.

With a keyboard where the notepad used to sit, there is nowhere for the drawing surface to go but vertical in front of you...

Actually, the coordinate system in OpenGL and other CG systems makes more sense when you convert it to Euler angles, because the polar axis is up and down where you would expect it to be. Gimbal lock is straight up and straight down, just like when standing on the North Pole and every direction your look is south. Likewise every direction is north when standing on the South Pole. Look at a globe to see where all the longitude lines converge.

Then we have the Razer Hydra with its own different coordinate system (out of the twelve you can choose from), which in that case makes great sense for a hand held controller. Swapping coordinate systems swaps the polar axis, so you need to choose whichever system suits your needs for a given purpose (GL, HMD, controller, or whatever)... Sadly, the Hydra swaps from a LH system to a RH system and some sections of its 3-space coverage (luckily not where you normally use it with the base sitting in front of you on your desk). You can detect the axis swap when all the quaternion elements swap their signs, then swap them back immediately, or do it later by detecting and dealing with whichever coordinate system it seems to be using at that location.

It is a good thing Ogre does not use multiple coordinate systems that you have to keep track of, eh?

EDIT: Hmm... Posting when I should be sleeping again... I think I had my "math coords" swapped. 2D on paper was X to the right, Y away from you toward the top of the paper. But in 3D I believe that changes to something that is not intuitively obvious to me. And whichever coordinate system you use changes depending on whether you are viewing it on a vertical desktop display sitting in front of you and facing you, or on a tablet computer that is on the desktop or table in front of you and facing the ceiling. Then converting between Euler angles and quaternions only makes it harder to envision.

[c6burns]

inb4 any Greek prefixes describing what just happened

[geekmaster]

inb4 any Greek prefixes describing what just happened

What did "just happen"? I signed up for this forum and posted something I thought would be a useful contribution, in reply to a question. Perhaps I am just adding to the confusion. ???

You could stick these stickers on stuff to keep it straight, maybe:



Greek letters? Σκατά?

[Kojack]

Hey geekmaster.

Gimbal lock is straight up and straight down,

It depends on the euler angle order. There's 6 combinations of euler angles (when each is used once, not counting the form where you use one axis twice such as yaw pitch yaw), only two of those have gimbal lock as up/down.
You can move the gimbal lock position by changing the euler angle that is in the middle.

But yaw pitch roll order (as local transforms left to right) is probably the most useful (in my opinion anyway), so up/down gimbal lock would be typical.

[c6burns]

The Greek prefix I was thinking was "necro" ... it's cool though that you probably found this thread by search engine or something and signed up to post something useful No harm in that, really.

[geekmaster]

I did not refer to my notes when I posted my first post here, so of course, I did not get it right... People who hang out here probably have orders of magnitude more thought time in coordinate space transforms that I, when in fact I am rather a noob at this. My experience is talking direct to framebuffers and such (2D) and many other IO devices. But progress is damn slow that way, so I need to adopt some libraries. Ogre3D looks good to me.

Now, how do I access Ogre3D from my native (kernel) mode RasPi code?

I am spending much more time buried in code these days than in any forums. I have more than 10K posts in a few forums in the past couple of years, so I may contribute here if I have something new and useful to contribute when I get "into" ogre3D...

Regarding gimbal lock being "straight up and straight down" I was referring to typically what is found in OpenGL and other CG documents, and in typical code that does Euler conversions. Up and down makes intuitive sense because when you look down beyond straight down (between your knees) you are actually looking 180-degrees in the other direction with 180-degrees roll too (an alternate way to get to the same position), so the other axes flipping 180 at the gimbal lock singularity makes sense when viewed that way. It makes a lot of sense for an HMD.

I have been working with decoding raw USB HID packets for the Oculus Rift tracker and the Razer Hydra. The Hydra has a strange behavior, where it flips between RH and LH coordinates and some areas of its coverage (all the quaternion values flip sign). Thankfully, that is not in the "normal" operating area in front of your desk when positioned as recommended in its docs. And such a large jump can be easily detected and compensated in software, if you are aware of its existence.

I plan to extend the "Baking Pi" USB HID drivers to support the Rift and Hydra in addition to its current keyboard and mouse. It would be nice to squeeze a miminal subset of Ogre3D in there too. Is there a stripped down "micro-ogre" subset I can use, without needing to figure out where to slice out the fat?