< decloaking >
Hopefully the list administrators will allow this post from
a non-subscriber thru to the list :-)
Here are some of my thoughts on how the 'View'
< please change this to 'Camera' > should work.
>> 2. The instruments rotate with the 3D cockpit but they don't tilt with
> > it (also waiting for a fix from Andy) -- that means that you can move
> > the mouse sideways, but try not to move it up or down unless you want
> > to see the magic floating gauges.
>Sadly, this requires more than just a fix. The virtual cockpit code
>needs to be able to read the current view direction as an offset from
>"aircraft coordinates" from the view_offset/view_tilt properties. But
>those are lies -- the "real" view direction is maintained by the mouse
>code, and is defined in global coordinates.
>These need to be unified. I keep thinking I've got it, and then
>getting crushed by a new discovery. This morning's surprise was that
>the mouse direction is handled by FGViewer, but the view_offset stuff
>actually happens outside the viewer object, in the main loop.
>It may well be better to wait for the ground-up rewrite of the view
>code before dealing with this. Alternatively, dealing with this may
>well *become* the ground up rewrite. :) I'll keep you posted.
FWIW - IMHO
FIRST yank out all the offset/tilt stuff and use a 'camera' quaternion to
represent these instead, THEN put the Mouse quaternion back adding in
the previously commented out horizontal component as you will need it.
Now you can just add the Mouse quat to the Camera quat and any other
applicable 'orientations' into a VIEW ORIENTATION quat in the main loop
>From this you can easily get the Euler Angles and/or the Rotation Matrix
of the 'cumulative view rotation' for what ever purposes you need.
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 ....
Now since every one seems confused a general overview of how FGFS
determines the 'VIEW'
There are several things that you want to keep in mine along the way
1) the PLib coordinate system has the same 'sense' as OpenGL but is
'Z' up. ie when looking the origin in a cannonical way
X is across the screen left to right ie right is positive
Z is across the screen bottom to top ie up is positive
Y is going into the screen positive is away from you
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
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 >
3) The next piece in the puzzle that complicates things 'a little bit'
is that there is not enough precision in a float32 to handle things
precisely on the surface of the Earth if the coordinate system originates
at the ECP [0,0,0] therefore 'most coordinates' are manipulated in a local
cordinate system that gets regenerated every frame relative to the
'scenery center', which conveniently is set each frame to the overflown
tiles center point which is 'close to the intersection of Earth Radial
Vector
expressed in direction cosine form with the 'best fit plane' of all the
points
in that tiles scenery. < in reality I think it is just the average of all
tiles points >
but it helps to visualize it as 'this tiles plane'
Finally given the above pieces an a current position expressed as Lat Lon
AGL
we first determine the XYZ offset of this Lat Lon AGL triplet by
1) converting from Ellisoidal Lat Lon SeaLevel to Spherical Lat Lon SeaLevel
// cartesian coordinates of current lon/lat if at sea level
// translated to scenery.center
sgVec3 zero_elev;
2) we add to this our AGL to get
// absolute view position in earth coordinates
sgdVec3 abs_view_pos;
3) we subtract the Scenry Center < the overflown tile's center > from this
// view position to go into our opengl world coordinates (this is the
// abs_view_pos translated to scenery.center)
sgVec3 view_pos;
4) we determine the Rotation Matrix that represents the Orientation of the
Aircraft with respect to the Current Tangent Plane < ie FDM's reference
plane >
// code to calculate LOCAL matrix calculated from Phi, Theta, and
// Psi (roll, pitch, yaw) in case we aren't running LaRCsim as our
// flight model
You can do this long hand or use my handcoded
MakeLOCAL( LOCAL, rph[1], rph[0], -rph[2] );
5) You then make a rotation matrix that brings the current surface
position ie you lat lon position to the 'zero spot'
This is your UP Matrix
6) multiplying this by the previously found LOCAL matrix < aircraft
orientation >
Gives you your Primary VIEW_ROT matrix which knows all about
the Aircraft's Orientation with respect to it's reference plane, the
position of this 'tangent plane' with respect to the Earth, and has the
Scenery Center < local tiles's center point > has its 'origin' which is
what
is needed to draw the scenery as all of the tiles centerpoints are
translated
with respect to the scenery center each frame.
Now all you have to do is add in your local 'eye' rotations to this matrix
and as should
be apparent I STRONGLY suggest using individual quaternions for this
FWIW
Using the above < existing method > FGFS is in fact a 'fast' 'reasonable
WGS84'
'mapping' engine. In fact it is 'almost' good enough to be a a 'charting
engine'
ie good enough to 'navigate' with, I have tried to make sure of that
< Disclaimer FGFS Code is NOT to be used for NAVIGATION
but should only be considered at 'best' a Navigational aid >
FYI I was about to rip out the view offset stuff after first having a
discussion about
the View Pipeline and how it all tied together but then somehow the tilt
matrix just
got added into the equation even after I had specifically requested a peer
review
prior to it inclusion, ie I knew the problem of not having ripped out the
view_offset
stuff earlier and it's making it too tempting to add in a tilt variety and
this is EXACTLY
what I did not want to see happen as it could only lead to the mess that you
have now
trying to implement a 'Virtual Cockpit'.
There are of course other ways that one can do this but I believe what I
have outlined
above is far and away the most flexible and 'natural' representation of the
problem
FWIW
This IS what finally led me to decide it was better for me to just leave
the
project rather then raise yet another public ruckus about arbritrary non-
discussed changes.
and I hope the above helps but ....
I will leave any further implementation/modification to the 'experts'
knowing that
what is there will work perfectly well as is if someone adds back and
finishes the
work on the 'eye' rotator as discussed above to have it handle the tile
horizontal
offset as well as the tilt.
FYI - I believe the code to do this was there just commented out
Regards
Norman
< re-cloaking >
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
