by date
Plan for Joel Baxter
Plan for Joel Baxter
| Name: | Joel Baxter |  |
|---|---|---|
| Date Posted: | Nov 19, 2002 | |
| Rating: |  3.5 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Joel Baxter |
Blog post
The Daily: Security worries and matrix math, oh my.
The Daily for Nov 18 2002:
Started the day with some more office/home-network logistics, pretty boring, won't summarize here. I'll note though that an Apple AirPort makes a fine wireless access point for PCs of any flavor... it has the exact same guts as our ORiNOCO RG-1000 as far as I know. If any Mac-less households are interested in using an AirPort I can drop some URLs on you (or, just Google away). So, now we have adequate wireless coverage upstairs and down.
--
Tiny bummer about the kvm setup: switching from one system to the other causes the Logitech keyboard to revert to its default state. Which is expected, and would be fine if that state were sensible. Unfortunately the default is that the function keys do not actually act as function keys, but rather as their special Logitech shortcut thingies. You have to press "F-Lock" to make them act normally. Meh, that's kinda dumb.
--
More poking around in the bug trackers for TGE and for Badlands. I see we've got a few more people using the Project Manager here; keep it up. :-)
Now that the PM has been around for a while, are there any complaints about it? I've been pondering:
- Should the default sort be reverse-numeric, to show the most recent bug reports (trivial, I know)?
- We need a better process to make sure that bugs get looked at, and followed up on, by the people that can fix them (vague, I know).
--
Here's a neat thing: a client compiled with DEBUG_NET can crash a server by connecting to it. At least, that's the case with Grav, and probably with TGE too (haven't checked yet). Even if TGE doesn't have that exact crash bug, it will have the same general vulnerability. The general problem is that the DEBUG_NET client sends numbers that the non-DEBUG_NET server is not expecting. The Grav crash, for example, happens in PathManagerEvent::unpack, where it reads the size of a vector from the stream. It gets a ridiculously large number and segfaults trying to allocate too much memory.
Security hole? Hmm. I wonder how much crash-the-server success someone could get using a vanilla TGE client changed to match Grav's protocol version, experimenting with sending junk at Grav servers.
--
I'm fine with the reasoning and actual calculations involved in 3D matrix math, but my intuition isn't 100% solid yet. Here's a problem that bit me today, which might be interesting to other people who are also in that boat.
Objects in Grav, including the player's avatar, are able to rotate on all axes. So I figured that the camera should be this way as well, especially since the camera can attach to and detach from arbitrarily rotated objects.
The original TGE camera has a setPosition method that does this:
Basically, it creates a pitch rotation matrix out of the pitch Euler angle, ditto for a yaw rotation matrix, then composites the rotation matrices and inserts the position information.
I changed the code in our camera to this:
which just creates the matrix directly from all the Euler angles (including roll) and the position.
Then I fired up Grav and briefly fiddled with various controls to see that the camera could rotate on all axes, and that was that. Personally I don't have occasion to use the camera much. Our level-editing peeps, however, started telling me that I had made the camera control exponentially more irritating, so I went back to take a look.
As a matter of fact the camera control was indeed very nonintuitive, even when leaving the roll input untouched. What the heck was going on? And what should be going on? I started investigating on the assumption that intuitively we would expect the yaw input to be interpreted as rotation around the local "up" direction of the POV, pitch interpreted according to the local "right" direction, and roll interpreted according to the local "forward" direction.
It turns out that there are two problems here.
The first problem is that the Euler-angles-to-rotation-matrix conversion is not following that model of rotational behavior. It creates a matrix for yaw-pitch-roll around the global coordinate axes.
So one question that popped up at this point was: why does the TGE camera behave OK? Well, it is doing pitch first, then yaw, rather than vice-versa (which I missed the first time I looked at its code). Which BTW answers why the code isn't the more elegant "MatrixF temp(EulerF(rot.x, 0, rot.z), pos);" ... that would do yaw before pitch, which was not desired. That leads to the second problem, which is that the "intuitive" behavior I first assumed we wanted is not, in fact, very intuitive.
Conceptually, pitch-before-yaw raises the view of the camera to a certain height (starting from an orientation aligned with the global coordinate space) then rotates it around the global Z axis. This is more intuitive that interpreting yaw and pitch relative to the camera, as it mimics the way you would turn your head to look at something. This also keeps the camera from ending up with a perceived roll, regardless of what pitch and yaw input you give it; i.e., the local "right" direction of the POV always stays level in the global coordinate space.
Now, if you were controlling some object in game that you wish to intentionally roll, like an aircraft or spacecraft, the rotation behavior would have to be handled differently. But the free-floating camera, especially when used for editing work, should just be your "surrogate head" in the game, rather than a vehicle that you drive around.
I can just revert that portion of the setPosition code and get a well-behaved camera again, without roll control of course. The lack of roll control makes for problems though when dealing with cameras that have been detached from rolled objects... plus, it's fun to be able to barrel-roll your camera. :-) I do have a solution in mind for this, based on what I've done for player control in zero-G situations, but it requires a basic reworking of the code. Undoubtedly I can pretty much lift this from our player code, but I'm going to triage that for later and just do the simple code reversion for now.
---
Today's accompaniment for keyclicks:
"Damascus", Yazbek
"By Request... The Best of John Williams and the Boston Pops Orchestra"
"Sabsylma", Zap Mama
"Vox P", Vox P
"Bach: Art of the Fugue", Canadian Brass
"Kinky", Hoodoo Gurus
"Stop Making Sense", Talking Heads
"The Edgar Winter Collection", Edgar Winter
Started the day with some more office/home-network logistics, pretty boring, won't summarize here. I'll note though that an Apple AirPort makes a fine wireless access point for PCs of any flavor... it has the exact same guts as our ORiNOCO RG-1000 as far as I know. If any Mac-less households are interested in using an AirPort I can drop some URLs on you (or, just Google away). So, now we have adequate wireless coverage upstairs and down.
--
Tiny bummer about the kvm setup: switching from one system to the other causes the Logitech keyboard to revert to its default state. Which is expected, and would be fine if that state were sensible. Unfortunately the default is that the function keys do not actually act as function keys, but rather as their special Logitech shortcut thingies. You have to press "F-Lock" to make them act normally. Meh, that's kinda dumb.
--
More poking around in the bug trackers for TGE and for Badlands. I see we've got a few more people using the Project Manager here; keep it up. :-)
Now that the PM has been around for a while, are there any complaints about it? I've been pondering:
- Should the default sort be reverse-numeric, to show the most recent bug reports (trivial, I know)?
- We need a better process to make sure that bugs get looked at, and followed up on, by the people that can fix them (vague, I know).
--
Here's a neat thing: a client compiled with DEBUG_NET can crash a server by connecting to it. At least, that's the case with Grav, and probably with TGE too (haven't checked yet). Even if TGE doesn't have that exact crash bug, it will have the same general vulnerability. The general problem is that the DEBUG_NET client sends numbers that the non-DEBUG_NET server is not expecting. The Grav crash, for example, happens in PathManagerEvent::unpack, where it reads the size of a vector from the stream. It gets a ridiculously large number and segfaults trying to allocate too much memory.
Security hole? Hmm. I wonder how much crash-the-server success someone could get using a vanilla TGE client changed to match Grav's protocol version, experimenting with sending junk at Grav servers.
--
I'm fine with the reasoning and actual calculations involved in 3D matrix math, but my intuition isn't 100% solid yet. Here's a problem that bit me today, which might be interesting to other people who are also in that boat.
Objects in Grav, including the player's avatar, are able to rotate on all axes. So I figured that the camera should be this way as well, especially since the camera can attach to and detach from arbitrarily rotated objects.
The original TGE camera has a setPosition method that does this:
MatrixF xRot, zRot;
xRot.set(EulerF(rot.x, 0, 0));
zRot.set(EulerF(0, 0, rot.z));
MatrixF temp;
temp.mul(zRot, xRot);
temp.setColumn(3, pos);
Parent::setTransform(temp);
Basically, it creates a pitch rotation matrix out of the pitch Euler angle, ditto for a yaw rotation matrix, then composites the rotation matrices and inserts the position information.
I changed the code in our camera to this:
MatrixF temp(rot, pos);
Parent::setTransform(temp);
which just creates the matrix directly from all the Euler angles (including roll) and the position.
Then I fired up Grav and briefly fiddled with various controls to see that the camera could rotate on all axes, and that was that. Personally I don't have occasion to use the camera much. Our level-editing peeps, however, started telling me that I had made the camera control exponentially more irritating, so I went back to take a look.
As a matter of fact the camera control was indeed very nonintuitive, even when leaving the roll input untouched. What the heck was going on? And what should be going on? I started investigating on the assumption that intuitively we would expect the yaw input to be interpreted as rotation around the local "up" direction of the POV, pitch interpreted according to the local "right" direction, and roll interpreted according to the local "forward" direction.
It turns out that there are two problems here.
The first problem is that the Euler-angles-to-rotation-matrix conversion is not following that model of rotational behavior. It creates a matrix for yaw-pitch-roll around the global coordinate axes.
So one question that popped up at this point was: why does the TGE camera behave OK? Well, it is doing pitch first, then yaw, rather than vice-versa (which I missed the first time I looked at its code). Which BTW answers why the code isn't the more elegant "MatrixF temp(EulerF(rot.x, 0, rot.z), pos);" ... that would do yaw before pitch, which was not desired. That leads to the second problem, which is that the "intuitive" behavior I first assumed we wanted is not, in fact, very intuitive.
Conceptually, pitch-before-yaw raises the view of the camera to a certain height (starting from an orientation aligned with the global coordinate space) then rotates it around the global Z axis. This is more intuitive that interpreting yaw and pitch relative to the camera, as it mimics the way you would turn your head to look at something. This also keeps the camera from ending up with a perceived roll, regardless of what pitch and yaw input you give it; i.e., the local "right" direction of the POV always stays level in the global coordinate space.
Now, if you were controlling some object in game that you wish to intentionally roll, like an aircraft or spacecraft, the rotation behavior would have to be handled differently. But the free-floating camera, especially when used for editing work, should just be your "surrogate head" in the game, rather than a vehicle that you drive around.
I can just revert that portion of the setPosition code and get a well-behaved camera again, without roll control of course. The lack of roll control makes for problems though when dealing with cameras that have been detached from rolled objects... plus, it's fun to be able to barrel-roll your camera. :-) I do have a solution in mind for this, based on what I've done for player control in zero-G situations, but it requires a basic reworking of the code. Undoubtedly I can pretty much lift this from our player code, but I'm going to triage that for later and just do the simple code reversion for now.
---
Today's accompaniment for keyclicks:
"Damascus", Yazbek
"By Request... The Best of John Williams and the Boston Pops Orchestra"
"Sabsylma", Zap Mama
"Vox P", Vox P
"Bach: Art of the Fugue", Canadian Brass
"Kinky", Hoodoo Gurus
"Stop Making Sense", Talking Heads
"The Edgar Winter Collection", Edgar Winter
Recent Blog Posts
| List: | 06/16/04 - Plan for Joel Baxter 11/26/02 - Plan for Joel Baxter 11/23/02 - Plan for Joel Baxter 11/21/02 - Plan for Joel Baxter 11/20/02 - Plan for Joel Baxter 11/19/02 - Plan for Joel Baxter 11/15/02 - Plan for Joel Baxter 11/14/02 - Plan for Joel Baxter |
|---|
Submit your own resources!| Joel Baxter (Nov 19, 2002 at 08:04 GMT) |
It seems to be pretty straightforward to show that the rotation matrix derived from a set of Euler angles -- which is just compositing a series of rotations about the global axes -- is not doing the same thing as if you applied each Euler rotation in turn on the local axes.
An example:
- Start with the POV's local coordinate space aligned with the global coordinate space. Consider a point A with coordinates (1, 0, 0) that we're going to rotate along with the POV.
- If we rotate the POV around the Z axis, and then rotate the POV around its new local X axis, point A will have new X and Y coordinates, but its Z coordinate will still be zero.
- However, if we generate a rotation matrix from the Euler angles in the usual way, and apply that to the original point A, we end up with a point that has a Z coordinate which is not necessarily 0 ... I think the Z coordinate in that case will be sin(a)sin(b), where a is the pitch angle and b is the yaw angle.
So doing a series of rotations around the global axes is not the same as doing a series of rotations around whatever the local axis happens to be at that time. Seems like common sense.
However, there's an apparently well-grounded web site that claims (see the footnotes) that "rotation about sequentially newly generated axes produces the same result as rotations by the same angles about the fixed original axes". To me that sounds like they are contradicting what I just said in the paragraph above (especially given the content of the page). Not going to chase it right now, but if anyone can explain that in a comment, feel free. I know it's a long shot but since we have 3D graphics minds out there I thought I'd mention it. :-)
I'm probably just overlooking something obvious anyway.
Edited on Nov 19, 2002 08:05 GMT
| Phil Carlisle (Nov 19, 2002 at 08:36 GMT) |
Lets explain it like this, if you rotate around the X axis by 90 degrees, you have altered the Z axis to actually be the same as the Y axis, so losing the ability to rotate around the Z axis (no roll).
Take a google for gimble lock, that MIGHT be the problem here.
Phil.
| Joel Baxter (Nov 19, 2002 at 09:19 GMT) |
| James Margaris (Nov 19, 2002 at 09:46 GMT) |
That must be some typo or poorly worded.
Rotations around different axes produce different results. There are trivial counter-examples to what they are claiming. For example start with (1,0,0) rotate around global x and then global z and you are still in the xy plane. However if you rotate around global x then local z you could have a z component as you point about above.
Maybe what they are trying to say is that you can calculate new axes such that rotating around them ends up being the same. In other word, rather than rotate around localx and localy, rotate around local? and local?2.
So, maybe what they are trying to say is:
"Given angles a,b,c applied in global space to axes x,y,and z, there exists axes y'!=y and z'!=z such that that ax,by',cz' = ax, by, cz."
Something like that maybe?
| Joel Baxter (Nov 20, 2002 at 00:47 GMT) |
Although, if you look at that page (he's describing ZYZ rotation, but the same principles should apply to ZXY or whatever) it sure looks like they're making the stronger claim. In the absence of any sensible explanation though, I'm just gonna assume that Dr. Klaus Eichele has made a little boo-boo in his web pages.
You must be a member and be logged in to either append comments or rate this resource.
