for fuselage Surface objects. If the fuselage wasn't aligned perpendicular
to the Y axis, the matrix wouldn't be orthonormal. Since all of, perhaps,
three aircraft have ever been built this way, it's doubtful I would have
found this as a bug report. :)
Description:
This update includes the new viewer interface as proposed by David M. and
a first pass at cleaning up the viewer/view manager code by Jim W.
Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and
modified the Makefile.am accordingly.
Detail of work:
Overall:
The code reads a little easier. There are still some unnecessary bits in
there and I'd like to supplement the comments in the viewer.hxx with a tiny
bit on each interface group and what the groupings mean (similar but briefer
than what you emailed me the other day). I tried not to mess up the style,
but there is an occasional inconsistency. In general I wouldn't call it done
(especially since there's no tower yet! :)), but I'd like to get this out
there so others can comment, and test.
In Viewer:
The interface as you suggested has been implemented. Basically everything
seems to work as it did visually. There is no difference that I can see in
performance, although some things might be a tiny bit faster.
I've merged the lookat and rph (pilot view) code into the recalc for the
viewer. There is still some redundancy between the two, but a lot has been
removed. In some cases I've taken some code that we'd likely want to inline
anyway and left it in there in duplicate. You'll see that the code for both
looks a little cleaner. I need to take a closer look at the rotations in
particular. I've cleaned up a little there, but I suspect more can be done
to streamline this.
The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO
the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about
to rip it out. It would seem that there more conventional ways to get
spherical data that are just as fast. In any case all the viewer was pulling
from the quat matrix was the pitch value so I modified mouse.cxx to output to
our pitchOffset input and that works fine.
I've changed the native values to degrees from radians where appropriate.
This required a conversion from degrees to radians in a couple modules that
access the interface. Perhaps we should add interface calls that do the
conversion, e.g. a getHeadingOffset_rad() to go along with the
getHeadingOffset_deg().
On the view_offset (now headingOffset) thing there are two entry points
because of the ability to instantly switch views or to scroll to a new view
angle (by hitting the numeric keys for example). This leaves an anomaly in
the interface which should be resolved by adding "goal" settings to the
interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc.
Other than these two issues, the next step here will be to look at some
further optimizations, and to write support code for a tower view. That
should be fairly simple at this point. I was considering creating a
"simulated tower view" or "pedestrian view" that defaulted to a position off
to the right of whereever the plane is at the moment you switch to the tower
view. This could be a fall back when we don't have an actual tower location
at hand (as would be the case with rural airports).
ViewManager:
Basically all I did here was neaten things up by ripping out excess crap and
made it compatible as is with the new interface.
The result is that viewmanager is now ready to be developed. The two
preexisting views are still hardcoded into the view manager. The next step
would be to design configuration xml (eg /sim/view[x]/config/blahblah) that
could be used to set up as many views as we want. If we want to take the easy
way out, we might want to insist that view[0] be a pilot-view and have
viewmanager check for that.
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
inclueded in some of the files. Irix doesn't have cout in the std class,
so I changed it to "cout" and included SG_USING_NAMESPACE(std) at the
beginning of the files.
And some minor warning cleanups.
and fixes a 'potential bug' if the FGFS View code were to change
I also consolidated the specialized IntersectLeaf()
as they really didn't gain us much outside of their having
'more direct access into the SSG controlled data'
I would like to see the fgCurrentElevation functions moved
out of hitlist.cxx.
The one obstacle is their being dependent on my PLib
auxillary functions
ssgGetEntityTransform()
ssgGetCurrentBSphere()
code has been run through astyle with the default options
fixed this when I made the mistake the first time.
The view code wasn't properly handling the transition across tile
boundaries so we'd get a 'flash' of the scene wrongly transformed for
one frame at every tile boundary crossing. This is what
scenery.get_next_center() is for.
the property system, among other things. A separate integration into
the FDMs will follow shortly.
This code will be used only if the --with-new-environment option is
*not* passed to configure.
separate header file. This change will help integrate properties into
JSBSim.
Also, I (David Megginson) removed most of the SimGear include
statements from globals.hxx, reducing the amount of recompilation
every time SimGear changes. This required making minor changes to a
lot of files that were depending on the side-effects of the inclusions
in globals.hxx.
- implement the standard FGSubsystem interface, for consistency
- eliminate current_autopilot and add get/set_autopilot to FGGlobals,
for consistency
- use private methods rather than static functions for tying
properties
There should be no change in functionality.
is a work in progress and needs severe enhancement before it will be
useful. It provides a UDP data channel that goes both ways between
flightgear and the fdm. It also provides a TCP 'command' channel so
flightgear can 'reliably' send commands to the remote fdm (such as set
starting position, reset on ground, etc.)
includes the ability to specify per vertex normals rather than depending
the normals list being the same as the vertices list. (Support for
previous binary file format scenery is maintained.)
This seems to pretty much correct the problem. Part of the problem is that
rotations are occuring at the firewall (model origin) which seems a little
un-natural inside the cockpit. The rest of the problem is I am just learning
how this stuff works (I know I've been saying this for a couple months
now...but hey I'm slow :-)).
