Re: [Eighthfleet-development] ODE problems

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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.=20

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 -----=20
  From: TIMOTHY K HAMILTON=20
  To: eig...@li...=20
  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=20
      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=20
      unrotated, with the world vector on the left and the relative =
vector on the=20
      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=20
      the right, +y is upwards, and +z is in front. Both the global and =
relative=20
      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=20
      YAWCW would rotate you 90 degrees to the right until you're facing =
it. You'd=20
      expect your relative vectors during this time to start with =
[100,0,0], to=20
      range intermediately between [n, 0, m] with n and m from 0 to 100, =
and to=20
      end at [0,0,100].

      That's not what happens. Here's some sample output from the =
situation=20
      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=20
      approaching the "front" of the ship as it rotates. Z should range =
up to 100,=20
      not down to -100.

      This is just an example. The long and short of it is that 0 to 3 =
of the=20
      values may have the wrong sign depending on the situation, and =
that I have=20
      no way to tell when this will happen and thus correct the sign =
errors. I=20
      think the bug occurs because of the way the rotation matrix works =
in ODE,=20
      but I don't really understand what the values in that matrix are =
supposed to=20
      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=20
      understanding of what is supposed to be happening. I suppose there =
could be=20
      a problem in the engine code or the graphics code or something =
else, causing=20
      what we see to be different than what ODE knows, but I think =
that's pretty=20
      unlikely.

      So this was like hitting a brick wall. I have no idea if I could =
write a=20
      working vector translation function before Thursday. Give me your =
feedback=20
      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=20
      by Pandora http://radio.msn.com/?icid=3DT002MSN03A07001

      =
-------------------------------------------------------------------------=

      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=3Djoin.php&p=3Dsourceforge&CID=3D=
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=3Djoin.php&p=3Dsourceforge&CID=3D=
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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV

-------------------------------------------------------------------------=
-----

  _______________________________________________
  Eighthfleet-development mailing list
  Eig...@li...
  https://lists.sourceforge.net/lists/listinfo/eighthfleet-development