>[A bunch of notes on Norm's notes.  Basically, everything he wrote
>  (even the editorializing) makes sense to me, with a few exceptions as
>  detailed below]

>Norman Vine wrote:
> > Easy beans - no gimble lock - infinitely stackable orientations -
> > everything has it's own logical spot - quick - elegant - natural
> > orientation changes < ie slerp's > - the code is basically all in PLib
> > for the using already - ect ....

>Heh, you're a quat nut, huh?

NO I HATE WORKING IN QUATS THEY MAKE MY HEAD SPIN :-)
but they have their occasional place and this is one of them !!!!!

> They're nice, but hardly necessary*.
>The biggest difficulty is in picking the front-end interface, for
> which quats basically suck.  I want to have a hat switch mapping where
>"left" becomes "subtract a little from view_offset".  You can't expose
> the quats to the user -- you need eulers for that, warts and all.

There are euler to quat interface routines in PLib
Use what ever interface you want but INTERNALLY
I say you want quats when you are modeling a 'free' rotation
otherwise you ALWAYS run into  a 'singularity' that you CAN'T
work around

And of course there is the elegant way to control spherical
accellerations that we haven't even talked about :-)

ie I want my head a(de)ccelerating smoothly not with an
unatural jerk

 > Now since every one seems confused a general overview of how FGFS
 > determines the 'VIEW'
 >
 > 1) the PLib coordinate system has the same 'sense' as OpenGL but is Z'
 >    up. [...] this is a simple rotation of a right handed coordinate
 >    system and is due to the fact that the PLib author primarily
 >    writes FlightSimulators where this is a 'natural coordinate basis
 >    If you don't like this fact either get over it or quit using PLib

> Chill, Norm, we can deal. :)

Hey all you had todo was ask and PLib has been that way from the beginning
and we all thought every one just knew it :-)
ie When in Rome do as the Romans ect....

> But having it spelled out somewhere more obvious would be nice.

FWIW - I was not a big fan of adopting PLib  for this and more importantly
its NON-C++'ness but I accepted it and more importantly became a PLib
developer jsut so I could watch out for FGFS Interests !
FYI - Several other FGFS'ers did the same feeling that developing PLib
was developing FGFS.  I feel sorry for all of those that think of PLib as
an 'external' constraint it certainly didn't start off that way and it
certainly
needen't remain that way

>I discovered it accidentally while browsing
>through the source code.  Just a hint for the next time you guys are
>auditing the documentation.

You mean you just ASSUMED we were using an OpenGL coordinate system ?

> > 2) the LaRC coordinate system is different also but this should be
> > handled transparently for you in existing code < see comment in
> > viewer_rph.cxx >

>There's a (reasonably) standard interface for the FDMs to export their
>location and orientation.  This bit isn't a problem.

Hey LaRC Sim is what made FGFS possible and by default determined how
a lot of things were done.  FWIW this is a  good piece of Quat  code and is
well
documented in reference 1 at
http://jsbsim.sourceforge.net/fsreference.html

As Newton said 'I stand on the shoulders of giants'

>This isn't quite fair.  I wasn't party to the discussion, but the tilt
>angle got added to solve a specific problem.  The panel/UI world
>*needs* an euler angle interface to the view direction to do its job.

Bah
It needs an interface .
If you want to talk to that interface with eulers fine
but it doesn't have to be an euler representation as you yourself just said
it just needs an euler interface.

>Under the existing implementation, the mouse code was the sole
>aribiter of those numbers, didn't export them as anything but a full
>quaternion, and didn't accept input from anywhere.  So a new feature
>was needed.

Wrong the GUI  exported an euler matrix !  From which you could have easily
picked  up the 'Mouse contribution' to the vies rotation with gram scmidt or
whatever.

OUT


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to