layers. The properties controlling each layer are inside
/environment/clouds/layer[n], and the available properties are type
("clear", "overcast", "mostly-cloudy", "mostly-sunny", or "cirrus"),
span-m (should be about 40000), elevation-ft, thickness-ft, and
transition-ft.
This is a new improved patch for the previous tile manager fixes.
Rather than building dependencies between FGlocation or the viewer or fdm with
tilemgr what I ended up doing was linking the pieces together in the Mainloop
in main.cxx. You'll see what I mean...it's been commented fairly well. More
than likely we should move that chunk somewhere...just not sure where yet.
The changes seem clean now. As I get more ideas there could be some further
improvement in organizing the update in tilemgr. You'll note that I left an
override in there for the tilemgr::update() function to preserve earlier
functionality if someone needs it (e.g. usage independent of an fdm or
viewer), not to mention there are a few places in flightgear that call it
directly that have not been changed to the new interface (and may not need to be).
The code has been optimized to avoid duplicate traversals and seems to run
generally quite well. Note that there can be a short delay reloading tiles
that have been dropped from static views. We could call the tile scheduler on
a view switch, but it's not a big deal and at the moment I'd like to get this
in so people can try it and comment on it as it is.
Everything has been resycned with CVS tonight and I've included the
description submitted earlier (below).
Best,
Jim
Changes synced with CVS approx 20:30EDT 2002-05-09 (after this evenings updates).
Files:
http://www.spiderbark.com/fgfs/viewer-update-20020516.tar.gz
or
http://www.spiderbark.com/fgfs/viewer-update-20020516.diffs.gz
Description:
In a nutshell, these patches begin to take what was one value for ground
elevation and calculate ground elevation values seperately for the FDM and the
viewer (eye position). Several outstanding view related bugs have been fixed.
With the introduction of the new viewer code a lot of that Flight Gear code
broke related to use of a global variable called "scenery.cur_elev".
Therefore the ground_elevation and other associated items (like the current
tile bucket) is maintained per FDM instance and per View. Each of these has a
"point" or location that can be identified. See changes to FGLocation class
and main.cxx.
Most of the problems related to the new viewer in terms of sky, ground and
runway lights, and tower views are fixed.
There are four minor problems remaining. 1) The sun/moon spins when you pan
the "lookat" tower view only (view #3). 2) Under stress (esp. magic carpet
full speed with max visibility), there is a memory leak in the tile caching
that was not introduced with these changes. 3) I have not tested these
changes or made corrections to the ADA or External FDM interfaces. 4) The
change view function doesn't call the time/light update (not a problem unless
a tower is very far away).
Details:
FDM/flight.cxx, flight.hxx - FGInterface ties to FGAircraftModel so that it's
location data can be accessed for runway (ground elevation under aircraft)
elevation.
FDM/larsim.cxx, larcsim.hxx - gets runway elevation from FGInterface now.
Commented out function that is causing a namespace conflict, hasn't been
called with recent code anyway.
FDM/JSBSim/JSBSim.cxx, YASim/YASim.cxx - gets runway elevation from
FGInterface now.
Scenery/newcache.cxx, newcache.hxx - changed caching scheme to time based
(oldest tiles discard).
Scenery/tileentry.cxx, tileentry.hxx - added place to record time, changed
rendering to reference viewer altitude in order to fix a problem with ground
and runway lights.
Scenery/tilemgr.cxx, tilemgr.hxx - Modified update() to accept values for
multiple locations. Refresh function added in order to periodically make
the tiles current for a non-moving view (like a tower).
Main/fg_init.cxx - register event for making tiles current in a non-moving
view (like a tower).
Main/location.hxx - added support for current ground elevation data.
Main/main.cxx - added second tilemgr call for fdm, fixed places where viewer
position data was required for correct sky rendering.
Main/options.cxx - fixed segfault reported by Curtis when using --view-offset
command line parameter.
Main/viewer.cxx, viewer.hxx - removed fudging of view position. Fixed numerous
bugs that were causing eye and target values to get mixed up.
the wrong place. The Atmosphere::getStd*() calls are used by the
solver, and thus really need to return values for a "standard"
atmosphere. Otherwise, an aircraft started up in Moscow will behave
differently than one initialized in Cairo. :)
The place where environmental pressure and temperature get inspected
at runtime is in YASim.cxx. The changes there, happily, end up being
even smaller than the ones to Atmosphere. This ends up replacing code
only, and removing some comments.
Here is the new super improved telnet property interface. CVS changelog
is at the end of this message. Once this new telnet code is in and
compiles every where we can remove Network/props.[ch]xx. I've added a
--telnet=<port> command line option to invoke the new server. Later on
we could remove the --props option, or least change it to invoke the new
server. I'll let you decide.
I've added some new commands to the telnet interface:
view next Select the next view.
view prev Select the previous view.
view set <n> Select view 'n'
view get Return index of current view
I'm not sure if these same effects could be achieved through property
operations. The commands provide a convenient shortcut in any case.
I'm also planning on adding a panel command to manipulate panels and
objects contained therein (eg simulated mouse clicks). There is going
to be some commonality with the command objects so we may need to
rationalize this in the near future.
Finally, I've also included my python stuff. This is still very much a
work in progress, basically I've been using it to test the new telnet
server. I have tested it with python 2.2. Feel free to add it to the
repository if you want. I would suggest a scripts/python directory
CVS Changelog
Network/telnet.cxx: New property telnet protocol interface. It supports
the same user interface provided by the --props server. Additionally it
handles multiple simultaneous connections. Added "view" command to
manipulate viewmgr.
Network/protocol.hxx: Added protocol configuration exception.
Main/fg_io.cxx: Added new "telnet" protocol. Added protocol
configuration parse exceptions. Simplified protocol configuration
parsing.
Main/options.cxx: Added --telnet=<port> command line option and help
message.
set_Density; since JSBSim doesn't override the get_* methods from
FGInterface as well, the wrong values are always set anyway.
Take the static temperature, static pressure, and density values from
an external source if requested by the
/environment/params/control-fdm-atmosphere property. This isn't
working properly yet for JSBSim because of interactions with the
trimming routine.
Stratosphere). The atmospheric properties are as follow:
/environment/temperature-sea-level-degc
/environment/temperature-degc
/environment/pressure-sea-level-inhg
/environment/pressure-inhg
/environment/density-sea-level-slugft3
/environment/density-slugft3
Setting either the sea-level or altitude value automatically sets the
other value appropriate, except for temperature at altitude above the
Troposphere (where there's no reliable way to back-calculate it). The
atmosphere model appears in the atmosphere_data array in
environment.cxx, and can easily be extended into the upper
stratosphere and beyond.
These are not yet tied into the FDMs or steam module.
Removed configuration option --with-new-environment and
FG_NEW_ENVIRONMENT macro.
Added configuration option --with-weathercm and FG_WEATHERCM macro.
FGEnvironment is now the default; use --with-weathercm to get the old
weather.
object rather than a pointer.
FGEnvironment now has the beginning of an atmospheric model, and will
recalculate temperature (not pressure or density, yet) based on
elevation.
FGEnvironment has a copy constructor.
- changed FGSubsystem::update(int) to
FGSubsystem::update(delta_time_sec); the argument is now delta time
in seconds rather than milliseconds
- added FGSubsystem::suspend(), FGSubsystem::suspend(bool),
FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with
default implementations; is_suspended takes account of the master
freeze as well as the subsystem's individual suspended state
- the FDMs now use the delta time argument the same as the rest of
FlightGear; formerly, main.cxx made a special case and passed a
multiloop argument
- FDMs now calculate multiloop internally instead of relying on
main.cxx
There are probably some problems -- I've done basic testing with the
major FDMs and subsystems, but we'll probably need a few weeks to
sniff out bugs.
The FlightGear patch is to take account the change in the getChildren
function that now returns a vector<SGPropertyNode_ptr>. If the
removeChild functionnality is to be added in FlightGear, all those
SGPropertyNode * floating around should be changed to
SGPropertyNode_ptr.
- don't send "set" confirmation when in data mode. If an external
program really cares if the settings were accepted, which is
rather unlikely, it simply has to "get" the property again.
The returned line would have been a pain to parse, anyway
(something like "from-model = 'true' (bool)").
- do not only "set" the first token, but concatenate all given
tokens with a space in between. This won't be used much, but
makes sense for setting strings, while it does no harm when setting
numbers. Silently ignoring all but the first token is impolite. ;-)
- remove old, commented out debug message that doesn't make much
sense any more.
Due to jumpy joystick read-outs the UFO jitters a lot in turns.
This patch implements simple damping for aileron/elevator/throttle.
Furthermore it lets the UFO fly backwards if brake[0] is active
(by default associated with the joystick's fire button). After all,
everyone knows that UFO's can fly backwards!
It's cumbersome to use the MagicCarpet as 3D cursor, because everytime
you shoot over the target you have first to turn by 180 degrees and to
fly back.
This patch lets the magic carpet fly backwards if brake[0] is active,
which is by default associated with the joystick's fire button.
Turns out it was a problem with a long string, not the font. Plib is limited
to 80 characters in things like this listbox. BTW I checked and all the fonts
are missing those characters. So, no point in changing.
Description:
Fixed segfault caused by long string.
> I have attached some new additions to the UIUC code. Most of the
> changes allow for the addition of apparent mass. This is very
> useful with light aircraft and gliders.
I changed the sound code to let it use FGCondition. This changes the
code and configuration files rather drastically. Furthermore I've added
an in-transit mode which plays the sound only when the tied property is
changing.
Changes:
Code:
* Added condition support to trigger an event
* Removed the <type> section from the main event definition
(this could be done using conditions)
* Removed the abillity to use several events with the same name,
instead it is required to use conditions.
* Updated the README.xmlsound
Base package:
* Changed the configuration files accordingly.
* Changed flaps and gear to use the new in-stransit mode.
* Changed the flps.wav file so it can be looped.
* Created a new gear.wav file (whcih can be looped)
and a gear-lck.wav file for gear locking sound.
IMPORTANT:
To change existing configuration files to the new ones, it is important
to pack events with the same name together into one singel event, using
the condition specification. Also, when using special types (inverted,
flip-flop, raise or fall) these should be changed to a conditions also.
For more information, please look at
FLightGear/docs-mini/README.xmlsound and the supplied aircraft
configuration files located under FlightGear/Aircraft (espesially
c172/c172-sound.xml and c310/c310-sound.xml).
default implementation that uses user-supplied params. Currently, the
only parameters are
/environment/params/base-wind-speed-kt
/environment/params/gust-wind-speed-kt
but others will show up soon (i.e. sheer, variable direction, variable
visibility, etc.). To activate these properties, you have to
configure --with-new-environment.
The gusting function is simplistic and needs to be replaced with
something better, though it doesn't feel too far off.
subproperty, 'spherical', which is true if the object has spherical
symmetry and should rotate around both the x-axis and z-axis to face
the camera (i.e. a simple cloud), and false if the object has only
cylindrical symmetry and should rotate only around the z-axis (i.e. a
tree).
1. If /position/longitude-deg and /position/latitude-deg are in range,
use them.
2. Otherwise, if /sim/startup/airport-id is not empty, use it.
3. Otherwise, set the lon/lat to the middle of the KSFO field.
The default used to be Globe, AZ, but that doesn't make sense since we
don't distribute that scenery by default any more.
With this change, starting from a save file seems to work properly:
fgfs myflight.sav
- Added initial_value argument, in milliseconds, that specifies when
event is first run. The default value of -1 triggers the event
immediately as per the existing behaviour. A repeat_value greater than
zero runs the event no less than every 'repeat_value' milliseconds
afterwards. A repeat_value of zero deletes the event.
- Modified run queue behaviour such that only one event per frame is
run.
ATCmgr.cxx:148 says:
// Returns true if the airport is found in the map
Yes, it returns true if the airport has been found. But it fails
to return the airport data. Just plays around with a local pointer. ;-)
I have finished working the bugs out of my "Enhanced" version of the Magic
Carpet FDM. The UFO FDM works the same as the Magic Carpet with the
following exceptions:
The aircraft's pitch is determined by the Elevator setting (with a pitch
rate of 45 degrees per second).
Climb is forward velocity * sin(pitch)
Speed is forward velocity * soc(pitch)
Roll is tied to the aileron (again, with a roll rate of 45 degrees per
second)
Turn rate is sin(roll) * 45 degrees.
Yes, this does mean that turning is quite a bit more sluggish than
climbing.
If you are wondering why a UFO FDM, it is because it's best that I not
replace the existing magic carpet and this FDM does behave like a UFO (it
hovers, can spin and pitch while hovering, and does not obey the laws of
physics ;)
SGTimeStamp "-" operator returns it's result in usec's, there is an upper bound of 37.8 minutes on the maximum difference this operator can reliably report
before the math overflows. I change the global "int elapsed_time_ms" variable
to a "double sim_time_ms" and restructured how the value is calculated.
----
The practical result of the overflow bug is that a large negative dt was
passed to the event manager and the end effect was that no events would
be run until their counters caught up ... in another 37.8 minutes or so.
This led to an investigation into why the ident playing didn't work anymore.
Recent changes in the sound manager broke some assumptions the radiostack
code was making. These patches should hopefully fix all that back up.
Erik, please review these changes to double check I didn't do more damage
than good. :-)
These are the updates for the View manager properties. Removed the last of
items (within the viewer/viewmgr) hard coded to view number. Added support
for per view configuration of ground level nearplane value. Tower views look
very nice with little or no z-buffer problem in the models. Pilot offset
dialog can be used to move eye in all views.
>90deg, even though src/Cockpit/radiostack.cxx has code to deal with
those; as a result, no backcourses were getting through.
This fix allows the common case of backcourses to work again, but
breaks the uncommon case of a runway using the same frequency for two
separate localizers. That special case will have to be detected
somehow. Still, this fixes more approaches than it breaks.
graph as the terrain, except for internal cockpit view. The SSG
scene-graph variables (except for the lighting root -- I'll get that
later) are now held in globals.hxx.
FGModelMgr::draw() is obsolete; I'll remove it in a future revision.
Minor fixes. Made some changes to get lighting correct for time of day
for now. MSVC compatibility fix and returned to clearing z-buffer only in
LOOKFROM (formerly pilot view).
[dpm: removed the last one, since I had already made a similar patch]
else and *doesn't* clear the z-buffer when in external view; tighten
the far plane for internal view back to 100m to give us maximum
precision (this will be important for some instruments; I might even
move it to 50m).
Here are the Boost-less FGEventMgr updates I promised.
Removed Boost dependencies from FGEventMgr.
Removed Boost configure check.
fgMethodCallback now handles const member functions.
I've successfully tested these changes with gcc and msvc.
Synced to CVS 19:36 EDT 2002-04-10 (after this evenings JSMsim and Base
package updates).
Description:
Added FGLocation class which is new home for calculating matrix rotations.
Viewer can now be configured to access rotations created by the model rather
than repeating the same calculations again.
Changed model initialization for the time being so that its location data is
available for the viewer (currently required by other subsystems). At some
point we can move this back to fg_init along with the viewer initialization.
Seperated the update from the draw function in the model code. The viewer
code needs the same matrix data, and moving the update portion at this time
does not increase the number of matrix math iterations.
Moved the model draw so that it always appears "in front" of lights and clouds.
Reogranized viewer update routine for using the FGLocation class and
simplified some more tasks. The routine is fairly easy to follow now, with
the steps ordered and spelled out in comments.
Viewmgr only updates the current (visible) view now, with the exception of an
old reference to "chase view" that will be corrected in forthcoming changes.
Also will be doing some work on the viewmgr outputs.
Model is now clears the z-buffer in all modes. This will be changed with the
next viewmgr update. The only side effect is that models always disappear
when over 5km distant from the eye point (can't really see them anyway:-)).
Other than a flag to indicate "internal" view I don't anticipate the
configuration interface for viewmgr/views will be changed a lot for now. It
is close to done. The next viewmgr update will however rework the outputs so
may change location.
This code will run with the previous version of preferences.xml, but will run
faster with the newer version. I am attaching a preferences.xml that should
not be commited before the code. All the changes are in the /sim/view section
and should show a simpler view configuration that references model locations.
Note that I've added a 2nd tower view in "lookfrom" mode for illustration
purposes. You can look around using the mouse. You may want to remove that or
comment it out.
Synced to CVS 19:36 EDT 2002-04-10 (after this evenings JSMsim and Base
package updates).
Description:
Added FGLocation class which is new home for calculating matrix rotations.
Viewer can now be configured to access rotations created by the model rather
than repeating the same calculations again.
Changed model initialization for the time being so that its location data is
available for the viewer (currently required by other subsystems). At some
point we can move this back to fg_init along with the viewer initialization.
Seperated the update from the draw function in the model code. The viewer
code needs the same matrix data, and moving the update portion at this time
does not increase the number of matrix math iterations.
Moved the model draw so that it always appears "in front" of lights and clouds.
Reogranized viewer update routine for using the FGLocation class and
simplified some more tasks. The routine is fairly easy to follow now, with
the steps ordered and spelled out in comments.
Viewmgr only updates the current (visible) view now, with the exception of an
old reference to "chase view" that will be corrected in forthcoming changes.
Also will be doing some work on the viewmgr outputs.
Model is now clears the z-buffer in all modes. This will be changed with the
next viewmgr update. The only side effect is that models always disappear
when over 5km distant from the eye point (can't really see them anyway:-)).
Other than a flag to indicate "internal" view I don't anticipate the
configuration interface for viewmgr/views will be changed a lot for now. It
is close to done. The next viewmgr update will however rework the outputs so
you can expect that the data that viewmgr is writing to the property tree
may change location.
This code will run with the previous version of preferences.xml, but will run
faster with the newer version. I am attaching a preferences.xml that should
not be commited before the code. All the changes are in the /sim/view section
and should show a simpler view configuration that references model locations.
Note that I've added a 2nd tower view in "lookfrom" mode for illustration
purposes. You can look around using the mouse. You may want to remove that or
comment it out.
- Throttle control position
- Mixture control position
- Magneto/starter control position
Added support for receiving:
- Engine state (off, cranking, running)
- RPM
- Fuel Flow
- EGT
- Oil Temp
- Oil Pressure
- Fuel tank quantity
- Weight on wheels
I made these modifications to correct the problem of getter functions
returning pointers to local variables. Those variables are no longer
locals and become static. One should be aware that it kills reentrancy
!
This patch moves built-in Class (for now only mag-ribbon) into special
directory as you have written it in TODO: in comments of this class in
panel_io.cxx. IMHO it is good idea. I want to play with built-in
classes and OpenGC and this will be useful.
Made a couple more adjustments, now the function builds the
transformation matrix (sans the translation) directly from the five
inputs. After realizing that it may be necessary for the new location
class to publish a world up vector, comments were added indicating
which values constitute world up.
Minor patches to initial tower view code. Added calculation for "tower" at
any airport, placed a couple fractions of a degree off the center. Moved the
farplane from 100m to 5km so that "lookfrom" mode can see the model. 5km is
still in a reasonable range for a depth buffer. Note that looking at a model
anything but a small distance will cause some problems on older cards.
Temporarily changed viewer to always report elevation/lon/lat of the aircraft
in order to avoid a problem with the ground trim getting recalculated when
tower and aircraft are on different tiles.
radiostack.cxx, fg_init.cxx and main.cxx. If these changes are accepted
then you can remove Time/event.[ch]xx and Include/fg_callback.hxx from
the repository.
Tower View and viewer config is in place. Note that the interface is
still in a state of flux. A couple of the config items (namely the
offsets) are still using the old settings. The tower is hard coded
into the base package for a position off the starting runway at KSFO
and is probably not in the right place for there even. Looks pretty
cool though! Tower View is the third view. If you aren't at KSFO
you'll just see blank space in view 3. It's looking through the earth or
something like that :-). Important note: zoom in with a few
hits of the "x" key to see the plane better in tower view.
This should fix it. The problem wasn't the rotations but a difference in
the translations. Note that this fix also puts the wheels back on top of the
pavement when in external view.
Changed the steering gain from +/-0.1 to +/-1.0, so that the steering
angle for the nosewheel (when present) is the same as the rudder
deflection angle. That's probably not exactly right, but it's much
better than we had before -- you can now steer the plane on the ground
reasonably during taxiing.
case logging is disabled). This way, when people specify a
non-existant aircraft or have an error in a custom XML file, they'll
get an error report, at least.
system. A chap from Germany called Alexander Kappes (cc'd) got
in touch with me a few weeks ago and has written the start of
Approach control. At the moment tuning in to a valid approach
frequency (Dortmund or East Midlands) should result in vectors to
a spot about 3 miles from the active runway, and a telling off if you
stray too far from the correct course, in the console window. He
seems to know what he's doing so expect this to improve rapidly!!
I've added a rudimentry AI manager and a hardwired Cessna at
KEMT on the runway - I'll remove it before the next release if I don't
have it flying by then. There seems to be an issue with framerate
which drops alarmingly when looking at it - I've a feeling that I've
possibly created several Cessnas on top of each other, but am not
sure.
ability to run a nonlinear model with flaps. The files ls_model.c and
uiuc_aero.c were changed since we had some functions with the same
name. The name changes doesn't affect the code, it just makes it a
little easier to read. There are changes in LaRCsim.cxx so UIUC
models have engine sound. Could you send me an email when you receive
this and/or when the changes make it to the CVS? Thanks.
Also I noticed you have some outdated files that are no longer used in
the UIUCModel directory. They are uiuc_initializemaps1.cpp,
uiuc_initializemaps2.cpp, uiuc_initializemaps3.cpp, and
uiuc_initializemaps4.cpp
Rob
and specific animation types are derived from it. This change makes
the code much easier to read, maintain, and extend.
Added a 'translate' animation type for a scaled, 3D linear translation
(such as a sliding throttle knob).
Renamed the 'offset' property to 'offset-m' or 'offset-deg' as
appropriate; ditto for 'min' and 'max' properties.
MSVC fix from Bernie Bright:
You can keep the enum private if you add the following declarations
immediately afterwards:
struct mouse;
friend struct mouse;
It seems that MSVC doesn't grant the nested mouse decl. any special
access privileges to its surrounding class.
Clear frame buffer and render model after rest of 3D scene. This has a
small frame rate cost (YMV). But who thought 3D cockpit would be cheap?
If anyone has a better idea, have at it!
Just did some more careful testing and I see little or no frame rate loss
with the depth buffer clear. Also you can change the near plane to 0.1
and get rid of the "sunroof" (so I don't have to make up another set of
patches.
My last patch fixed the initialization problem only for the main branch, but
ignored the _MWERKS_ branch.
- merged the branches, only the loop head needs different treatment;
- don't access n.type before it is initialized (valgrind complaint)
- created a constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.nav.gz entry, so we would have
got a mixture of the broken one and the previous one; in case of
the first entry, that would have made nice random values ... ;-)
- move the automatic FGNav variable into the loop, so that the gets
cleanly constructed for every database entry.
- commented out the frequency min/max exploration, which isn't used at all
- updated the commented out debug output statements, which were simply
copied over from the nav* files, but never adapted (I needed them :-)
* src/ATC/atislist.cxx
Patch from Melchior Franz:
- merged the _MWERKS_ & generic #ifdef branch, only the loop head needs
different treatment
- commented out a "n >> skipeol" that is used in navlist.cxx to gobble
the starting C++-style comment from default.nav.gz; atis inherited
that, but there is no such comment in default.atis.gz, so the first
data entry got thrown away
- commented out min/max frequency exploration (-> only for debugging)
- enhanced the constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.atis.gz entry, so we would have
got a mixture of the broken one and the previous one;
- move the automatic FGATIS variable into the loop, so that it gets
cleanly constructed for every database entry.
- don't access a.type before it is initialized
- updated the commented out debug output statements; they were still
designed for the FGNav class ...
- merged the _MWERKS_ and the generic branch, only the loop head needs
different treatment
- created a constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.fix.gz entry, so we would have
got a mixture of the broken one and the previous one; (valgrind
complained ...)
- move the automatic FGFix variable into the loop, so that the gets
cleanly constructed for every database entry.
- don't access fix.type before it is initialized
- updated the commented out debug output statements (they were copied
over from navlist.cxx but never adapted)
radiostack.cxx:703 says
bool light_on = ( outer_blink || middle_blink || inner_blink );
but none of the flags has ever been initialized when this line is first
executed.
This patch creates a seperate scene graph for the cockpit. The near plane is
only moved up when in the interior (pilot) view. This is because with
rounding (I presume) it the visible ground is a bit up higher than it is with
the older nearplane setting. Not much, but it is enough to bury the wheels.
I suspected this might be true but spliting to two sg's confirms it. If
necessary we can adjust the model up a bit when in interior view. This might
be good so we can set the near plane even closer when in the cockpit (its
still at 0.2m).
In general this looks a lot better on my Voodoo with this patch. No
perceptibel change in frame rate on my system. In terms of future plans I'd
see the sense in making the model plug into either scene. This will be
necessary when we have multiple model instances in the frame.
The matrix doesn't define some cells, which are actually used
in the multiplication. That makes the result unpredictable.
I have no idea if 0.0 is the correct value for these, but
garbage is hardly the correct value either. Should some of them
be set to 1.0?
Think my brain is getting clogged with matrices :-). Well I've got the funky
orientation offset bug out of the model code. In the process the model.cxx
got optimized a bit. At some point we'll need to liberate model.cxx from the
viewer class, but it is no longer hard coded to access the "pilot view" to
get it's data. Instead it uses whatever the "current" view happens to be. I
may try and do that final bit of having models rotate independant of the view
tomorrow night, or start right in on the viewmgr and get a tower view up and
running. You guys have any preference? My brother's family is coming to
visit for a few days so what I don't get done tomorrow night probably won't
get done until after the weekend.
The compiler complains about too long names for instanciated templates
that result in name truncation. There are warnings but finally it ends
with a fatal errors. I found that ignoring the warning cure the
problem.
as a follow-up of my previous message, I found that in panel.cxx, function
const char *FGTextLayer::Chunk::getValue () const, there is the use of a
member variable _buf that seems to be uninitialized.
When the loop starts, n.type is still undefined, so the while statement
depends on unitialized garbage. The input operator cares for the [End]
bracket anyway (returns if the first character is a '['). So it is safe
to check for it after reading the line and break if necessary.
The first hunk might not be necessary, but the light_coverage property
was the only one that wasn't explicitly defaulted, which is unfair. ;-)
The second hunk adds the missing initialization to the init routine.
This is necessary, because (unlike the material entries from material.xml)
the generated light entries don't get the light coverage set. Yet
obj.cxx:795 reads this information out fot every leaf, although not needed
in the case of lights. Avoiding this isn't worth the trouble.
The last hunk sets the missing normal_index. The POINTS branch in
gen_leaf was always called with this int_list empty, which made the normals
handling use data garbage.
It seems that the airport database was changed some day and the End?Flags
changed from floats to strings. The database definition, though, was not
adapted and still created number entries. Reading out these flags led to
access to memory, that was never initialized. While it didn't cause crashes
during normal use, it actually caused one when I ran fgfs in ddd. Seems,
that the concerned memory region wasn't zeroed out then and hence uncovered
the bug.
Of course, the runways.mk4 database has to be re-created with the new
definitions.
Fix FGViewer::update so that pitch offset and goal pitch offset work
together nicely (the offset was snapping to 90/-90 when only one of
the two was changed).
Viewer improvements from Jim Wilson:
These files get the 3d cockpit working and fix a few issues in the viewer
code.
XYZ offsets are now defined as follows: X -left/right+ (along wing axis), Y
-up/down+ perpendicular to the aircraft, Z is -in/out+ the aircraft's body axis.
I've also done some cleaning up of unused and mostly unusable interfaces,
added commentary to the *.hxx, combined together some duplicate code and
eliminated a couple unecessary operations. I also moved what was left of the
"protected" zone to "private" since we aren't subclassing this anymore.
(mainly in src/Input/input.cxx) will make src/GUI/mouse.cxx obsolete
and bring the mouse into the same input system as the joystick and
keyboard. This is just preliminary work allowing, covering mouse
clicks (no motion yet), and it actually crashes on a middle or right
click.
The new mouse support is disabled by default until it become stable;
to try it out, you need to configure --with-new-mouse.
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 :-)).
* Add new trigger types: raise, fall
* Add new trigger offset parameter
* Add new volume/pitch types: inv, abs, sqrt
* Add initial support for multiple events to intervere in a single sound
(by using the same name, see the crank section of 172-sound.xml)
* Cached the volume/pitch type fucntions
(No more if's inside the loops in update())
created a new class, FGViewPoint (declared in viewer.hxx) that holds a
single position in FlightGear coordinates, and have used it to factor
a lot of the common code out of viewer_lookat.cxx and viewer_rph.cxx.
I don't know whether this new class will stay or not; it might just be
a temporary step, or it might end up taking over much of the current
viewer functionality. It would be a bad idea to code against it right
now.
plane to 0.2; otherwise, use the old defaults.
This is a temporary step that will allow me to work on a 3D cockpit
without breaking current behaviour; the final approach will be to put
the 3D model in its own scene graph, with different clipping plane.
OK, attached is a replacement for mouse.cxx that works the view using
the view-offset/tilt interface, rather than the (kinda odd) GuiQuat
stuff. It's kind of a hack job, as I left the hooks to GuiQuat in in
other places for fear of breaking something. Still, it removed more
code from mouse.cxx than it added, which has to count for some
elegance points.
Oh yeah, I forgot to send that one along. This one is my bug, I
goofed the precedence in the fgPanelVisible() function in panel.cxx
such that the panel was *always* visible if virtual cockpit was
enabled. Here's a replacement. I've modified the style from a single
boolean expression to an if-list, since that's more readable to my
eyes for expressions this big:
and soon to be renamed) is true, FlightGear will draw the 3-D model
even in internal view. This makes sense right now only with the C310
model, since the others don't have any kind of interiors modeled and
all surfaces in all models are one-sided.
This isn't quite working yet -- the view code is very hard to
disentangle, and currently, if the view is not forward, roll and pitch
are applied incorrectly. It looks interesting (modulo a messy model)
on the ground, in level flight, or looking straight ahead under any
other flight conditions.
to 10m after takeoff, but that doesn't really make sense any more,
especially if models are going to have interior views. Is there any
real saving in pushing the near plane out anyway?
was some confusion between degrees and radians which would lead to a huge
goal_view_offset value. The display would sit and spin for a *long* time
trying to wind it's way up to this large value.
