Split up main.cxx into a program manegement part (which remains in
main.cxx) and a render part (the new renderer.?xx files). Also turn
the renderer into a small class of it's own. At this time not really
exctining because most of the stuff is still global, but it allows us
to slowly migrate some of the global definitions into the new class.
The FGRenderer class is now managed by globals, so to get the renderer
just call gloabals->get_renderer()
At some pijt it might be a good idea to also turn the remaining code in
main into a class of it's own. With a bit of luck we end up with a more
robust, and better maintainable code.
This patch is there to correct a problem that prevent to load static objects when specifying a relative fg-root or a different, relative, fg-scenery. It appears that there is a mix between fg-root, fg-scenery and PLIB's model-dir.
It has been reported on the list that users are not able to see the buildings, especially those running the win32 builds because they run 'runfgfs.bat' that set FG_ROOT=./DATA.
I decided not to use model-dir because it just add confusion and to build a valid path earlier.
I split the FGModelPlacement code out into it's own set of source files.
I created two versions of the fgLoad3DModel() routine. One that is
unecumbered by a panelnode dependency and one that is. acmodel.cxx is
the only place that needs to load an aircraft with instrument panels.
model.[ch]xx are now pretty much free to move over into simgear.
loader.[ch]xx should be able to follow closely behind.
This will be a big step towards being able to move the material management
code over into simgear.
the ascii scenery file format has actually worked in quite some time, and the
ADA runway light code has been supersceded by a slightly different mechanism.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
To compile the development CVS version of FlightGear(0.9.0) i had to
apply some small changes to SimGear and FlightGear.
The changes need probably some additional ifdefs for other platforms but
since my linux-hd crashed i can't verify that.
Here's a patch to fix the offsets bug. The problem was the transform was just
getting added to a local instance rather than being returned by the function.
duration-sec. This animation may have any number of child objects,
and each one will be displayed for the requested duration before
moving on to the next one.
Added Animation::init for initialization after children have been
added to an animation.
Added a default implementation of Animation::update, and removed all
of the empty ones in derived classes.
Removed tabs from model.cxx.
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all "3D" cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another "update" hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
"mouse press delay", and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
I noticed that textures for scenery static objects are not loaded
anymore for a few weeks. Static objects have absolute path while
random objects and aircraft have relative path but fgLoad3DModel
unconditionally prepend fg_root to the model path. This patch test the
beginning of the model path to choose if fg_root has to be prepended
to the model path.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Animations are now contained within the scene graph itself and are
updated whenever the graph is traversed -- that saves time by not
updating animations not currently in sight, and it allows animations
to be used for static objects and random objects as well.
Added new FGModelLoader and FGTextureLoader classes. These are intern
tables for models, to guarantee (mostly) that no model is loaded more
than once. FGTextureLoader is not yet used anywhere, but
FGModelLoader is now in place everywhere that ssgLoad* used to be
used (thus adding the ability to use animations).
In the future, FGModelLoader will add some interesting functionality,
including the ability to reload 3D models on the fly.
GL/gl.h can't be included at the first position in windows. It requires
the inclusion of windows.h that must be included in other fgfs header
file. I only move down #include <GL/gl.h>
+ The panel(s) are now an first-class SSG node inside the aircraft
scene graph. There's a little code added to model.cxx to handle the
parsing, but most of the changes are inside the new FGPanelNode
class (Model/panelnode.[ch]xx).
+ The old FGPanel source changed a lot, but mostly cosmetically. The
virtual-cockpit code moved out into FGPanelNode, and the core
rendering has been abstracted into a draw() method that doesn't try
to set any OpenGL state. I also replaced the old inter-layer offset
code with glPolygonOffset, as calculating the right Z values is hard
across the funky modelview matrix I need to use. The older virtual
panel code got away with it by disabling depth test, thus the "panel
draws on top of yoke" bug. PolygonOffset is really the appropriate
solution for this sort of task anyway.
+ The /sim/virtual-cockpit property is no more. The 2D panels are
still specified in the -set.xml file, but 3D panels are part of the
model file.
+ You can have as many 3D panels as you like.
Problems:
+ The mouse support isn't ready yet, so the 3D panels still aren't
interactive. Soon to come.
+ Being part of the same scene graph as the model, the 3D panels now
"jitter" in exactly the same way. While this makes the jitter of
the attitude gyro less noticeable, it's still *very* noticeable and
annoying. I looked hard for this, and am at this point convinced
that the problem is with the two orientation computations. We have
one in FGLocation that is used by the model code, and one in
FGViewer that is used at the top of the scene graph. My suspicion
is that they don't agree exactly, so the final orientation matrix is
the right answer plus the difference. I did rule out the FDMs
though. None of them show more than about 0.0001 degree of
orientation change between frames for a stopped aircraft. That's
within an order of magnitude of what you'd expect for the
orientation change due to the rotation of the earth (which we don't
model -- I cite it only as evidence of how small this is); far, far
less than one pixel on the screen.
[and later]
OK, this is fixed by the attached panel.cxx file. What's happened is
that the winding order for the text layer's polygons is wrong, so I
reverse it before drawing. That's largely a hatchet job to make
things work for now, though. We should figure out why the winding
order is wrong for only text layers and fix it. I checked the plib
sources -- they're definitely doing things CCW, as is all the rest of
the panel code.
Odd. I'm also not sure why the 2D panel doesn't care (it works in
both winding orders). But this will allow you to check in working
code, anyway. There's a big comment to this effect in there.
class, FGModelPlacement, while FG3DModel retains control of animation.
This way, we can have a single, top-level placement, but multiple
layers of nested models underneath. To include a nested model, use
something like this in the XML wrapper:
<model>
<path>Models/Stuff/my-component.xml</path>
<offsets>
<roll-offset-deg>45</roll-offset-deg>
</offsets>
</model>
