Menu
▾
▴
Re: [Eighthfleet-development] ODE problems
|
From: TIMOTHY K H. <tkh...@ve...> - 2006-11-28 04:06:33
|
I mean that -z is always forwards in every context., +z is backwards. I'm looking at the vectors being translated back and forth from body to world to back now, and all the signs are matching up.
Maybe it's only with the latest commits I've made. Let me know if you're looking at something different, it is quite possibly right in front of my eyes and I'm missing it.
Nathan Clow <n_...@ho...> wrote: You mean -z is backwards from a body-relative standpoint? This really only makes some sense to me if there's actually a bug in the drawing code.
I can use a linear thrust to REVERSE and watch the global Z pos decrement, as well as watch the ship seem to go backward. The coordinates are pulled straight from ODE, so it LOOKS right. Is there some bug with engine placement or thrusting as well? Also, why does a [0,0,100] world vector translate to the body as a [0,0,100] relative vector? This tells me at least that the ode global coordinate and body-relative coordinate systems start aligned. If they are aligned, then the given rotation should produce what I expect, not what ODE is giving me. I tried to draw all my conclusions just from evidence culled from ODE, but can't really draw complete conclusions without understanding the values in the rotation matrix.
There are other scenarios too. For instance, from a 0,0,0 starting point, a PITCHUP to relative 0,100,0 scales the vectors exactly as I expect, and this does involve z.
I don't think I get it. I'll try to build an ODE testbed to test my understanding in isolation from all our game code but our deadline looms close.
----- Original Message -----
From: TIMOTHY K HAMILTON
To: eig...@li...
Sent: Monday, November 27, 2006 1:21 PM
Subject: Re: [Eighthfleet-development] ODE problems
So... ready for the next revelation in the "Tim is stupid" saga?
The z-coordinates are reversed.
-z is forward, +z is backwards
Yeah, it's really counter-intuitive, but it's the way things work for whatever strange reason the original minds came up with. I know I've come across this before when working with openGL, but I'd managed to forget as I was getting into the project.
>From the sound of things so far, this may just solve the problem you've been having with ODE rotation, as well. If both systems use the convention of -z as forward, with all the other coordinate systems following the usual intuition, then things seems to make more sense.
Let me know if I need to do some more digging.
I'm going to keep working on the high-level nav AI for the rest of the day.
-Tim
TIMOTHY K HAMILTON <tkh...@ve...> wrote: Wow, that's... bad. Really bad.
I had been suspecting that I might have been mis-translating ccordinates between ODE and openGL, but what you're describing looks like a problem completely internal to ODE itself.
I'll see what I can do with it today, and get you some feedback by this afternoon.
-Tim
Nathan Clow <n_...@ho...> wrote:
Some bad news:
There appears to be a bug in ODE with dBodyVectorFromWorld. I think the
function is bugged and returns sign errors on its values.
Here's my logic:
The body starts at position 0,0,0 with normal (unrotated) rotation values.
The axes of the body are initially aligned with those of the world.
Here are sample dBodyVectorFromWorld translations while the body is
unrotated, with the world vector on the left and the relative vector on the
right.
[100,0,0] -> [100,0,0]
[0,100,0] -> [0,100,0]
[0,0,100] -> [0,0,100]
So, based on this, I created the notion that for relative vectors, +x is to
the right, +y is upwards, and +z is in front. Both the global and relative
coordinate systems seem to be aligned at the start while not rotated.
So, one would expect that, if given a point 100 units to the right, a simple
YAWCW would rotate you 90 degrees to the right until you're facing it. You'd
expect your relative vectors during this time to start with [100,0,0], to
range intermediately between [n, 0, m] with n and m from 0 to 100, and to
end at [0,0,100].
That's not what happens. Here's some sample output from the situation
described above.
Pos: [0.000000 0.000000 0.000000] DestPos: [100.000000 0.000000 0.000000]
Derived world vector [100.000000,0.000000,0.000000] from navQueue
Derived relative vector [98.828865,0.000000,-15.259607] from navQueue
Translated back to world vector [100.000000,0.000000,-0.000000]
See how z is negative? I don't know how this can be. The point is
approaching the "front" of the ship as it rotates. Z should range up to 100,
not down to -100.
This is just an example. The long and short of it is that 0 to 3 of the
values may have the wrong sign depending on the situation, and that I have
no way to tell when this will happen and thus correct the sign errors. I
think the bug occurs because of the way the rotation matrix works in ODE,
but I don't really understand what the values in that matrix are supposed to
be (despite spending a lot of time looking at it).
I've been over this and over this and can't find any error in my
understanding of what is supposed to be happening. I suppose there could be
a problem in the engine code or the graphics code or something else, causing
what we see to be different than what ODE knows, but I think that's pretty
unlikely.
So this was like hitting a brick wall. I have no idea if I could write a
working vector translation function before Thursday. Give me your feedback
if you have any. I'll approach the problem again tomorrow with a fresh mind.
_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
---------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
---------------------------------
_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
|
