/sim/screneryloaded-override was "true". At least one subsystem (od_gauge)
waits for /sim/sceneryloaded to bypass CPU intensive code until the scenery
is up. This broke e.g. the RTT-radar when using /sim/screneryloaded-override
--prop:sim/sceneryloaded-override=true has the effect that fgfs
doesn't show the splash screen until the scenery is loaded, but shows
the OTW view (scenery/aircraft) at the earliest possible moment. This is
useful for developers who often need to run fgfs only to check some minor
detail, while not caring about stuttering caused by scenery loading.
simple SG_LOG instead. The user didn't call the fgcommand, so why should
s/he be bothered with that? And the actually caller of the command gets a
return value and can pop up a dialog if it thinks it's necessary.
Why /sim/fg-current at all? Because we have a file selector dialog
(still unfinished), and one might like to start it from the current
directory, to find saved flights/screenshots/whatever.
FGManipulator.*:
"This patch works around a bug in OSG's handling of modifier keys. The
symptom of the bug is that modifier keys don't appear to be released."
fg_os_osgviewer.cxx:
"This patch fixes the test for support of cursor changes in OSG 2.0."
because this allows to load from FG_HOME. To reduce security risks, always
append an ".xml" extension if there was none. Makes it hard to read /etc/secret
and to overwrite ~/.bashrc. :-)
src/GUI/gui.h src/GUI/gui_funcs.cxx src/Main/fg_commands.cxx
src/Main/renderer.cxx src/Main/renderer.hxx: Tim Moore:
These patches implement a command to dump the entire OSG scene graph as
a .osg text file. While large, this allows debuggers to really see
what's happening in the scene graph.
configure.ac src/Main/Makefile.am src/Main/fg_os.cxx
src/Main/fg_os.hxx src/Main/fg_os_sdl.cxx src/Main/main.cxx
src/Main/renderer.cxx src/Main/renderer.hxx
src/Network/jpg-httpd.cxx
Added Files:
src/Main/FGManipulator.cxx src/Main/FGManipulator.hxx
src/Main/fg_os_osgviewer.cxx:
Tim Moore: Make use of osgViewer.
throwing an instance of 'sg_io_exception'\nAbandon". And this is caused
by compiling fgfs/sg without exception support (unlikely) or linking
against a libSDL/libglut that was compiled/linked without execption
support. While we can't fix that, we can tell the users who's to blame. :-)
- handle const char * exceptions
- props is easy to mix up with the --prop option (for setting properties)
- the name is unspecific and inconsistent: other option names describe
the protocol -- the way to get the properties. How is, for example,
--httpd less about prop(ertie)s?
- two identical options easily confuse people, as can be seen in The
FlightGear Manual, where --telnet and --props were described differently
/sim/view[*] that it finds. It's not only unnecessary that view definitions
have subsequent indices, but aircraft are now *requested* to use indices
100++. /sim/view[0] .. /sim/view[99] are reserved for the system. (Not
that we'd ever need that many, This is just a convention, it's nowhere
hard-coded.)
- replace the string operations for property paths by method calls & other
improvements
because nasal's f_interpolate() may be called in Nasal at times when the
GENERAL subsystem group is being deconstructed; access it by addressing
the group directly, as using globals->get_subsystem() does then not
work any more then; yeah, it's all for a rare border case ... :-)
NasalSys.cxx more robust instead. The reason for the crash was that during
fgfs shutdown destroyed subsystems (GENERAL group) still need Nasal access
(for AI Model destruction listeners), but at that point globals->get_subsystem()
can't even deliver the "nasal" subsystem (INIT group). One way to solve that
problem would have been to replace globals->get_subsystem("nasal") by
globals->get_subsystem_mgr()->get_group(SGSubsystemMgr::INIT)->get_subsystem("nasal"),
but Andy decided to store a pointer to the active "nasal" subsysten in
NasalSys.cxx instead, as the "nasal" subsystem needs to be accessed in
every single Nasal extension function, and multiple "nasal" subsystems are
out of the question, anyway.
we need to explicitly destroy that here, too, so that it has guaranteed
access to the Nasal subsystem. Otherwise we get a segfault on exit. When
the next subsystem needs this special treatement (radar?), we should
introduce a new subsystem group (in addition to INIT and GENERAL)
"FATAL: PUI: No Live Interface! Forgot to call puInit ?"
We shouldn't use the splash progress message before guiInit().
Leave the "idle_state" step for now, to keep the similarity
with fg/plib as big as possible. This can be dropped later.
Patch to enable atc chatter (and any other arbitrary "message" audio file)
to be played at any specified volume. (Previously these messages were always
played at a hardcoded volume of 1.0)
- loop up file name in the cache at startup. If it's found, check if the
file exists and use it, otherwise scan $FG_ROOT/Aircraft/ as usual,
and create a new cache while doing that. Rebuild cache on FG_ROOT change.
(including all subdirs and with max depth!), but only the outmost level.
There are no *-set.xml files in deeper nested dirs, and with an ever growing
number of aircraft the search just lasts too long.
src/Input/input.cxx src/Main/renderer.cxx
src/Main/renderer.hxx src/Scenery/scenery.cxx
src/Scenery/scenery.hxx: Move scenery picking into the renderer.
There is most of the required data defined. Also we can better use
the pick visitor that will be needed with th upcommung panel code.
options.cxx: Olaf Flebbe: Fix some problems with --help --verbose
caused by the usage of snprintf. Elimate snprintf usage in favour
plain std::string manipulations.
Time/tmp.cxx Main/viewer.hxx Main/viewer.cxx Main/renderer.cxx
Get rid of an other OSGFIXME. The view matrix had some plib specials
included. The viewer is now updated for that.
format. I have a Garmin 295 to test with, but so far I haven't been able
to make this work (code should compile cleanly though.) I don't know if
I've made a mistake in the protocol or if my 295 just doesn't support this.
More work on this to come.
in the case of fg_init.cxx we'll only see that if the log-level is set
in preferences.xml, because command line options weren't even processed
at that time. :-/
(this was the reason why the first two text lines on the splash screen
looked more blurry than the others). BTW: I played with other values
than -0.5, but this turned out to be the best already. It makes textures
sharper than 0, but not too sharp (and thus flickering).
track and is a PITA for support staff. It's this message:
Error reading properties:
Failed to open file
at /home/newbie/.fgfs/autosave.xml
(reported by SimGear XML Parser)
Generally you want point sprites for performance reasons when enhanced runway
lighting (and smooth points) are activated. Most hardware doesn't
accelerate the rendering of standard smooth points, so without point sprites
you will kill your night time performance if you turn on enhanced runway
lighting.
Note that enhanced runway lighting "breaks" our clever scheme to make the
runway lighting brightness vary with the relative view angle. This means
with enhanced lighting on, all lights are equally bright no matter what
direction you view them from. So perpendicular runways are just as bright
as runways you are directly lined up with (when enhanced runway lighthing
is activated.)
You can revert to the original lighting scheme by turning off enhance runway
lights, turning off distance-attenuation, and turning off point-sprites in
the rendering options menu.
and "latitude-offset" should not use a precalculated value of warp.
2) Since the values of cur_time and crrGMT are identical in the current
version of the SGTime class, the calculations of the "system", "gmt", and
"latitude" are re-evaluated and updated where necessary.
I attach 2 new files and a diff file for the associated changes to add a
“fluxgate compass” to the instrument inventory. Whist this outputs
essentially the same data as /orientation/heading-magnetic-deg, it has to
be powered, and can be made to fail. I also followed Roy’s suggestion to
generate the error properties for this instrument here rather than in
xmlauto.xml.
When this instrument is included in cvs, I intend to use it in the Hunter,
A4F Seahawk and KC135. After a bit more research, it might be appropriate
for the Spitfire and Hurricane as well. AJ would also like to use it for his
Lightning model.
Thanks to tied functions, this is only executed when the node is read. This
will be done by the old & new HUD code, the latter of which won't have a
special lon/lat mode at all. Instead it will be regular labels that point
to these properties for displaying lon/lat.
I would have liked to avoid the duplication of code (lon and lat being
basically the same thing), and to avoid using static buffers and all, but
... if anyone wants to make it prettier, go ahead.
The format is controlled by /sim/lon-lat-format (will be changed if I
find a better place).
are taken down by the C++ runtime environment. This will later be done
with runlevels. Why would we want to run nasal code in subsystem
destructors? We don't really. But some data structures may use nasal,
which are normally created/destroyed during runtime. And these will
also be destroyed at fgfs exit. In the past things like these didn't
happen, because someone had disabled all subsystem destructors ...
src/AIModel/AIAircraft.cxx src/ATC/AILocalTraffic.cxx
src/FDM/flight.cxx src/FDM/flight.hxx src/FDM/groundcache.cxx
src/FDM/groundcache.hxx src/Main/fg_init.cxx src/Main/main.cxx
src/Scenery/hitlist.cxx src/Scenery/hitlist.hxx
src/Scenery/scenery.cxx src/Scenery/scenery.hxx
Make use of the attached SGMaterial reference userdata on scenegraph
leafs. Make the SGMaterial pointer available to the ground query
routines.
SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx,
for which JSB had given explicit permission a while ago. I postponed that
back then, but now is the time.
into the <color> group, but that's because on HUD color changes a whole
"color" set from /sim/hud/palette/color[*] is copied to /sim/hud/color/, and
antialiasing needs to be considered with that. (I'm not entirely happy
with the property names yet.)
two almost identical functions for these methods. It only forces to repeat
the redundancy for every small change to either.
- abstract out generation and destruction of plib string arrays
- abstract out generation of lists from <value> children
- only call globals->set_initial_waypoints() if the waypoints list address
has actually changed, that is: if it has just been initialized
- remove trailing spaces
- fix indentation
but got changed so that Nasal listeners wouldn't be triggered needlessly.
Doesn't make sense, though, as Nasal will never be available before the
video size is set, and it prevents the window interface from setting the
startup size.)
Here is one patch that to make FlightGear run without floating point
exceptions on FreeBSD. Apparently, if we do not ignore floating point
exceptions per this patch, there is some occasional condition where the
nvidia driver is involved in delivering spurious floating point exceptions
to the fgfs process, causing it to core-dump occasionally without the patch.
With only this patch, FlightGear will compile and run properly on
FreeBSD 6.X as long as the nvidia accelerated driver is installed,
modulo proper switches to the SimGear and FlightGear configure script
executions.
Again, kudos to your team for the great work on the big release
push; it is super to see things come together like this!
a race condition ending in warping twice and having huge increments for the
second warp.
I am not aware of such a flush function in glut. So we emulate that by
ignoring mouse move events between a warp mouse and the next frame.
That should make glut behavour aequivalent to sdl behavour.
I have implemented a Honeywell MK VIII EGPWS emulation for FlightGear.
The MK VIII is an Enhanced Ground Proximity Warning System aimed at
regional turboprop and small turbofan aircrafts such as the Citation,
Citation Bravo, B1900D, Beechcraft 99 and L410.
Frederic Bouvier:
make the MSVC compilation possible. Rearrange base package directories.
This patch makes use of the vectors now available in simgear with that past
patch. And using that it simplyfies the carrier code somehow.
- Small additional factory's to the quaternion code are done in the simgear
part. Also more explicit unit names in the factory functions.
- The flightgear part makes use of them and simplyfies some computations
especially in the carrier code.
- The data part fixes the coordinate frames I used for the park positions in
the carrier to match the usual ones. I believed that I had done so, but it
was definitly different. Also there are more parking positions avaliable now.
The new multiplayer patch with an extension to transmit some properties with
the base package. The properties are transmitted in a way that will not
immediately brake the packet format if we need new ones.
Even if the maxmimum number needs to be limited somehow, that format might
work well until we have an improoved packet format which is even more compact
and that does not require to retransmit redundant information with each
packet.
That part is relatively fresh and based on that what Oliver provides on his
multiplayer server web page.
The properties are transferred to the client and I have modified the seahawks
rudder animation property to use a relative property path to verify that it
works appart from the fact that you can see it changing in the property
browser.
The movement is still a bit jerky, but that can be fixed/tuned later without
again braking the packet format.
the mouse pointer to a new position. Otherwise it can happen that the new
position is first set, but then come a few still unprocessed events for the
old position. This makes ugly jumps in mouse view mode.
or write to the color properties in /sim/screen/. If this Nasal/GUI
implementation turns out to be too slow, we'll write a generic OpenGL/plib
version simliar to the ATCdisplay code. (OK'ed by Andy and Stuart)
or write to the color properties in /sim/screen/. If this Nasal/GUI
implementation turns out to be too slow, we'll write a generic OpenGL/plib
version simliar to the ATCdisplay code. (OK'ed by Andy and Stuart)
scripts that load/write user specific data that shouldn't go to PWD, and
can't go to $FG_ROOT (due to permissions and clean separation of 'official'
data and local modifications)
This patch removes some useless indirection when creating AIModels. It
obsolets AIScenario*.
AIEntities are just an intermediate copy of an other intermediate copy of an
xml file on the way from the ai scenario configuration file to the AIModels.
As such the AImodels can now be created directly from the property tree read
from the scenario file.
This reduces the amount of work needed to add an other AIModel and reduces the
amount of copy operations done during initialization.
It also moves internal knowledge of special AI models into these special AI
models class instead of spreading that into the whole AIModel subdirectory
which in turn enables to use carrier internal data structures for carrier
internal data ...
Also some unused variables are removed from the AIModel classes.
I believe that there are still more of them, but that is what I stumbled
accross ...
Tested, like the other splitouts these days in a seperate tree and using the
autopilot for some time, and in this case with a carrier start ...
problems because a lot of people already have their *real* preferences
set in ~/.fgfs/preferences.xml (and don't want fgfs to stomp over them),
because the name doesn't tell people that their data aren't save there
(comments!), and because this is inconsistent with the global preferences.xml
file, where user changes *are* respected.
This patch is a combined effort by Gregor Richards, Oliver Schroeder, and
Vivian Meazza (and code cleanups and improvements by Erik Hofman). It corrects
the bug in which a Multiplayer model responds to local inputs, and the view
number bug which caused certain aircraft to appear as cockpit only models. It
passes remote properties over the net, and all major control surfaces and gear
are now animated correctly, providing that the local ~model.xml file contains
no leading "/" in the <property></property> data entries. MP objects
are now extrapolated using 1st and 2nd derivatives to make their movement
appear more smooth. The sim is now halted while a new client joins the net.
Known problems with MP are non-display of the remote client under certain
circumstances of starting/resetting, and a freeze on starting. These bugs are
long standing, and are not addressed by this patch.
Special thanks must go to AJ Macleod for his patient testing of this patch over many evenings.
We have also moved part of multiplayer into AIModels as part of the ongoing
development of MP.
Fix the current buggy rain orientation behaviour for the views attached to the
aircraft (while still inheriting bugs with the views attached to anything else).
- Feet to meter conversion mistake (in AI getGround elev)
- Improved ground following code (not yet perfect, but for now no one will
notice it within the marginal altitiude differences at the taxitrack or
runway)
- Exclusion of the "AI" directory witihin data/Aircraft in
main/init/fgSearchAircraft, to prevent AI aircraft to be picked up by the
aircraft search function
This patch limits the maximum simtime we do simulation computations for.
That is highly sensible if you run flightgear in valgrind or some realy slow
debug build. In such a case it is possible that flightgear gets totally
unresponsible, because simulation time might increase slower than real time.
That patch introduces a maximum simulation time per rendered frame to limit
that effect.
If the property /sim/max-simtime-per-frame is set to something strictly
positive, the simulation time is limited to that value.
The default is unchanged - no limit.
Anyway, from the point of view of gui responsiveness and responsiveness to
realtime controls like joystick inputs it might be a good idea to limit that
by default to say 1 second. If you have less than 1fps, flightgear is
unplayable anyway and I believe we do not longer need to care for realtime
correctness for that case ...
though the window wasn't resized. I'm just not adventurous enough for
a cleaner solution in the light of the upcoming release. At least the
xsize/ysize properties aren't set each frame any more, so listeners
work now properly.
Erik Hofman:
This patch contains an update to net_ctrls.hxx that adds an extra 100 bytes
(or an equivalent of 25 (u)int32_t types) of reserved space. This could be
used to make the protocol forward and backward compatibel within a certain
scope. Be sure to read the instructions at the begining of the header file
when addinf new variables.
"play-audio-function" command. This function can be called from internal
code, from nasal scripts, or from external scripts to play a single one-off
wav file. File/audio data is loaded and unloaded on the fly automatically.
- Provide a Nasal interface to display simple text messages on the screen
like the ATC display. In fact, I copied the code from the ATCDisplay.cxx
and simply shifted it further down the screen.
Erik:
TODO: Integrate the two pieces of code.
Computes the pick direction and starting point. This is code that translates
a screen coordinate into a vector in the FlightGear world (between the eye and
the on-screen coordinate.) Armed with this vector in FG world coordinates,
you could call a scenery intersection routine and lookup the lon/lat/elev of
the point in the world that was clicked on.
* in some cases more specific sg exception types were used in place
of the more generic one, e.g., sg_io_exception instead of sg_exception
when the context of the error was an IO error
* in some cases, the error message was made more specific
* minor style fix for exception rethrowing --- using throw; whenever
a re-throw is made; sometimes optimizing away the exception symbol name
in the catch handler at all
* more specific catch handlers added in some places -- e.g.,
an sg_io_exception caught ahead of sg_exception
Insert empty string as marker between FG_SCENERY path elements.
FG_SCENERY=A:B expands to [A/Terrain, A/Objects, "", B/Terrain, B/Objects, ""]
(assuming that both A/ and B/ have Terrain/ and Objects/ subdirs).
tileentry.cxx -- FGTileEntry::load():
Check all tile dirs in FG_SCENERY from left to right: add all objects
to the scenery until a terrain tile was found: In this case read the
rest of that group (i.e. the Objects/ twin dir) and then stop scanning.
Better structuring of log messages & fix warnings.
to pop themselves down while the simulator is paused.
The problem was with the "real time" queue in the event manager,
causing the third argument of Nasal's settimer() (a flag for "sim
time") to be ignored. Inverts the default sense of the argument, as
there are lots of uses of settimer() in the current code, almost none
of which want to use real time.
Note this fix introduces a header file incompatibility in SimGear --
be sure to update.
redraw(): redraw gui without distroying dialogs (fgcommand "gui-redaw"/Shift-F10)
This change makes sure that Nasal-generated and dynamic dialogs can be
re-opened correctly when cycling through themes.
there was the situation where four directories contained jst two files,
of which three directories were aircraft related, and one directory contained
test code from Curt that might be better of in SimGear anyhow.
This is just a patch to move a bunch of files to new locations. In case of
local changes to any of them you can do the following:
move replay.[ch]xx from src/Replay to src/Aircraft
move control.[ch]xx from src/Control to src/Aircraft
move ssgEntityArray.[ch]xx from src/Objects to simgear/screen
In addition it has been decided only to use .[ch]xx files in all directories
unless it's contained within an FDM specific directory, in which case the
author is free to do whatever (s)he wants.
In this repspect the following files have been renamed in src/Multiplayer:
tiny_xdr.[ch]pp has become tiny_xdr.[ch]xx
multiplaymgr.[ch]pp has become multiplaymgr.[ch]xx
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
CygWin/gcc-3.4.4 updates.
I replaced my cygwin compiler with 3.4.4, did a make clean of plib, simgear,
and flightgear, then did a make install of all three. With the included changes,
everything builds fine, and runs fine.
I stumbled across two memory errors with two wrong const references to
std::string.
As I fixed that, I also moved aircraft_dir which is only used from UIUC into
UIUC. With that uiuc_aircraftdir.h is empty and can be removed.
I believe I have found the agl hud problems as well as the 'hole' in the
carrier's deck. I spent half the day to reproduce that problem, it did not
occure when you start on the carrier not does it occure with JSBSim and my
really often used testaircraft. So I really need to improove my helicopter
flying qualities.
I was under the impression that *all* FDM's call
FGInterface::updateGeo*Position(..)
so set the new position in the FDM interface. Therefore I had added at the
some code that updates the scenery elevation below the aircraft to *those*
functions.
Ok, not all FDM's do so :/
The attached patch factors out a function computing the scenery altitude at
the current FDM's position. This function is also used in those FDM's which
need to update this value themselves.
Also this patch restores the nearplane setting and uses the current views
altitude instead of the current aircrafts. I think that this should further
be changed to the eypoint's agl in the future.
The agl is again ok in YASim's hud.
Changes
=======
- acmodel.cxx :
we now have an optional new property (/sim/model/texture-path) that is used
as the first path in wich aircraft textures are searched. If textures are not
found there then the usual texture path or model path is used ;
This allows to replace only needed textures for liveries ;
- options.cxx :
added a new --livery=xxx option for the user pleasure ;
this will just set the /sim/model/texture-path property with /livery/xxxx
- od_gauge.cxx, og_gauge.hxx, cockpit.cxx, cockpit.hxx,
generic-instrumentation.xml :
added an helper class that contain a rendering context for glass instrument
or any other opengl drawn instrument ;
- wxradar.cxx, instrument_mgr.cxx, wxradar.hxx :
first experimentation of a weather radar ;
This adds a TACAN instrument to the inventory. Range and bearing are calculated
to the TACAN or VORTAC beacon selected by means of the Channel Selector in the E
quipment/Radio pull-down menu.
A TACAN beacon has also been added to the aircraft carrier Nimitz (channel #029Y
).
Attached is a patch to the airport data storage that I would like committed
after review if acceptable. Currently the storage of airports mapped by ID
is by locally created objects - about 12 Meg or so created on the stack if
I am not mistaken. I've changed this to creating the airports on the heap,
and storing pointers to them - see FGAirportList.add(...) in
src/Airports/simple.cxx. I believe that this is probably better practice,
and it's certainly cured some strange problems I was seeing when accessing
the airport data with some gps unit code. Changes resulting from this have
cascaded through a few files which access the data - 11 files are modified
in all. Melchior and Durk - you might want to test this and shout if there
are problems since the metar and traffic code are probably the biggest
users of the airport data. I've also added a fuzzy search function that
returns the next matching airport code in ASCII sequence in order to
support gps units that have autocompletion of partially entered codes.
More generally, the simple airport class seems to have grown a lot with the
fairly recent addition of the parking, runway preference and schedule time
code. It is no longer just an encapsulation of the global airport data
file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!).
My personal opinion is that we should look to just store the basic data in
apt.dat for all global airports in a simple airport class, plus globally
needed data (metar available?), and then have the traffic, AI and ATC
subsystems create more advanced airports for themselves as needed in the
area of interest. Once a significant number of airports worldwide have
ground networks and parking defined, it will be impractical and unnecessary
to store them all in memory. That's just a thought for the future though.
There was a patch from Manuel Masing a few months ago which cleaned up
SGLocation's way depending on input values. That means that with that patch
SGLocation does no longer have calls with unneeded input arguments.
I took his patch and integrated that into flightgear and made maximum use of
that changes.
Erik Hofman:
Remove some duplicate code that was moved to simgear/compiler.h
I have prepared a patch that:
- Introduces a FGTileMgr::scenery_available method which asks the tilemanager
if scenery for a given range around a lat/lon pair is already loaded and make
use of that method at some -9999 meter checks.
- Introduces a FGScenery::get_elevation_m method which queries the altitude at
a given position. In constrast to the groundcache functions this is the best
choice if you ask for one *single* altitude value. Make use of that thing in
AI/ATC classes and for the current views ground level. At the current views
part the groundcache is reused if possible.
- The computation of the 'current groundlevel' is no longer done on the
tilemanagers update since the required functions are now better seperated.
Alltogether it eliminates somehow redundant terrain level computations which
are now superseeded by that more finegrained functions and the existence of
the groundcache. Additionally it introduces an api to commonly required
functions which was very complex to do prevously.
I did some profiling of the code and found a few interessant things. Some corrections are obvious like the one in the multiplayer code, the fps is no more divided by 2 or 3 when another plane is on screen.
Other things like collision detection and computation of agl can not really be optimized. I changed a few things in hitlist.cxx but this only give a very low increase of fps. The groundcache eats a lot of cpu but I think that the real way to do it is to use a real collision system like OPCODE or something like that.
And I added an option to disable the recording of replay data. It takes more cpu than we can think.
Changes
=======
- panel.cxx :
moved the computation of the instruments diffuse color outside the texturelayer code
since this is constant during a frame, this is a big speedup for 2D panels ;
- hitlist.cxx :
changed the computation of the intersection between ray and triangle, optimized
the sphere culling by using a normalized direction vector. This can give a
35% speedup on the computation of elevation in some situations ;
- renderer.cxx, acmodel.cxx :
call ssgDrawAndCull with plane scene graph in external or internal view,
calling ssgDrawAndCull with the root scene graph was drawing other players plane
a second time in multiplayer mode ;
- mplayer.cxx :
removed the calls to ssgFlatten and ssgStripify because it was degenerating models,
causing a massive drop in frame rate ;
- replay.cxx :
added an option to disable the recording of the flight
- fgclouds.cxx :
changed the path of cloudlayer properties to match preferences.xml ;
set the altitude of clouds from scenarios to a more correct value if metar is not enabled ;
Changes
=======
- shadowvolume.cxx, renderer.cxx :
- reduced the polygon offset a bit to eliminate some artifact ;
- changed again the cleanup code for objects inside a tile because it could crash on rare occasion ;
- the culling of shadow casters has been rewritten to traverse the scene graph, it should be
a bit faster when there is a lot of objects ;
- the range selector was not correctly handled, sometimes the wrong LOD was casting shadows.
- added the option to display aircraft's transparent objects after the shadows, this will
reduce the problem of shadows being hidden by the transparent object (propeller disk,
rotor, etc). A side effect is that aircraft's transparent objects won't receive shadows
anymore. This is usually a good thing except when the aircraft use a 'transparent'
texture where it should not. A transparent texture in the plib context is a texture
with an alpha channel or a material with alpha <= 0.99.
- model.cxx, animation.cxx, shadowvolume.cxx :
- added an optional <condition> under the <noshadow> animation
- tower.cxx
- correct a rare bug where all occurences of the aircraft are not deleted from the
departure list causing a crash in FGTower::CheckDepartureList function.
I have traced that reset on carrier problem down to several problems. One of
them is the fact that on reset the carrier is updated while the aircraft is
not. That made the aircraft drop down an elevator sometimes. Depending on the
passed realtime while loading some parts of the scenery.
I have introduced the posibility to start directly on the carrier.
With that patch you will have a --carrrier=id argument where id can either be
the pennant number configured in the nimitz scenario or the carriers name
also configured in the carriers scenario.
Additionaly you can use --parkpos=id to select different positions on the
carrier. They are also configured in the scenario file.
That includes the switch of the whole FGInterface class to make use of the
groundcache.
That means that an aircraft no longer uses the current elevation value from
the scenery class. It rather has its own local cache of the aircrafts
environment which is setup in the common_init method of FGInterface and
updated either manually by calling
FGInterface::get_groundlevel_m(lat, lon, alt_m);
or implicitly by calling the above method in the
FGInterface::_updateGeo*Position(lat, lon, alt);
methods.
A call get_groundlevel_m rebuilds the groundcache if the request is outside
the range of the cache.
Note that for the real usage of the groundcache including the correct
information about the movement of objects and the velocity information, you
still need to set up the groundcache in the usual way like YASim and JSBSim
currently does.
If you use the native interface, you will get only static objects correctly.
But for FDM's only using one single ground level for a whole step this is IMO
sufficient.
The AIManager gets a way to return the location of a object which is placed
wrt an AI Object. At the moment it only honours AICarriers for that.
That method is a static one, which loads the scenario file for that reason and
throws it away afterwards. This looked like the aprioriate way, because the
AIManager is initialized much later in flightgears bootstrap, and I did not
find an easy way to reorder that for my needs. Since this additional load is
very small and does only happen if such a relative location is required, I
think that this is ok.
Note that moving on the carrier will only work correctly for JSBSim and YASim,
but you should now be able to start and move on every not itself moving
object with any FDM.
Changes
=======
New volumetric shadows for FlightGear.
There is now two new checkboxes in the rendering dialog to enable/disable shadows
for the user aircraft and for static scenery objects (ie those defined in the .stg files).
AI and random objects are not handled for the moment.
known bugs
==========
- ghost objects
Changes
=======
- correct the transparency probleme when old 3d clouds were enabled
(rendering context with an alpha channel)
- changed rain cone orientation, it can now be viewed from helicopter or chase
view (still not tower view)
- clouds are a bit more yellow/red at dawn/dusk
- weather data is now correctly propagated to the interpolator, this correct
visibility, wind, etc
- the 'metar' weather scenario now immedialty reuse the real metar data
- real metar no more overwrite custom weather scenario
This is another update for the cloud code, a lot of lines but this time I have started to add the doxygen doc.
Misc
====
- corrected a bug when RTT is not available, the current rendering context was
altered
- if RTT is not available then 3d clouds are not drawn at all
- impostors lighting is now recomputed when the sun changes position
- distant objects are no more seen in front of clouds
- blending of distant clouds is a bit better now
- litle optimization of code (uses a less cpu time)
- use layer wind speed and direction (no more hardcoded wind)
- fov is no more hardcoded
Changes
=======
- clouds (cu only) are dissipating/reforming (experimental)
- compute a turbulence factor that depends on surrounding clouds and type of
clouds (experimental)
- clouds shapes are defined in cloudlayers.xml
- type of clouds present in a layer is also defined in cloudlayers.xml
- cloud layers are generated from metar and other misc. data (in progress)
- added a rain effect around the viewer (enabled in the rendering dialog and
when the metar property says so)
- added a lightning effect (enabled in the rendering dialog) : cb clouds spawn
new lightnings
- added a dialog to select from different weather source : metar/property,
a 'fair weather' environment and a 'thunderstorm' environment.
/sim/startup/splash-progress)
- a string in /sim/startup/splash-title is displayed on top of the screen
and by default empty
- the splash image is scaled down if 512x512 is too big
- code cleanup
I have done a patch to eliminate the jitter of 3D-objects near the viewpoint
(for example 3D cockpit objects).
The problem is the roundoff accuracy of the float values used in the
scenegraph together with the transforms of the eyepoint relative to the
scenery center.
The solution will be to move the scenery center near the view point.
This way floats relative accuracy is enough to show a stable picture.
To get that right I have introduced a transform node for the scenegraph which
is responsible for that shift and uses double values as long as possible.
The scenery subsystem now has a list of all those transforms required to place
objects in the world and will tell all those transforms that the scenery
center has changed when the set_scenery_center() of the scenery subsystem is
called.
The problem was not solvable by SGModelPlacement and SGLocation, since not all
objects, especially the scenery, are placed using these classes.
The first approach was to have the scenery center exactly at the eyepoint.
This works well for the cockpit.
But then the ground jitters a bit below the aircraft. With our default views
you can't see that, but that F-18 has a camera view below the left engine
intake with the nose gear and the ground in its field of view, here I could
see that.
Having the scenery center constant will still have this roundoff problems, but
like it is now too, the roundoff error here is exactly the same in each
frame, so you will not notice any jitter.
The real solution is now to keep the scenery center constant as long as it is
in a ball of 30m radius around the view point. If the scenery center is
outside this ball, just put it at the view point.
As a sideeffect of now beeing able to switch the scenery center in the whole
scenegraph with one function call, I was able to remove a one half of a
problem when switching views, where the scenery center was far off for one or
two frames past switching from one view to the next. Also included is a fix
to the other half of this problem, where the view position was not yet copied
into a view when it is switched (at least under glut). This was responsible
for the 'Error: ...' messages of the cloud subsystem when views were
switched.
have a "property" mode as well as the original "binary" mode. The property mode
will allow the remote module to request any set of properties, and it will send
those properties each frame. The remote module can reply with a list of arbitrary
property name/value pairs to update on the FlightGear side.
This is a first stab, so it's not the cleanest, most well concieved code, but it
allows an external module (communicating via a pipe) to have a huge amount of
flexibility in the data in can access and update.
Make SDL window resizable; This exposes the same problem that many
GLUT users have: resizing up may cause a temporary switch to software
rendering if the card is low on memory. Resizing down again switches
back to HW rendering. (KSFO is texture intensive, but there are no
problems in LOWL, and elsewhere.) Less and less users will have the
problem as cards become better, and it's no reason not to allow
resizing altogether.
a safe undersleep() to conserve cpu. Essentially we undersleep our target by
just a bit (to avoid the chance of oversleeping.) Then we finish off the
remaining time slice with a busy-wait loop.
Norman Vine wrote :
> Frederic Bouvier writes:
>
>> Quoting Andy Ross:
>>> * Hopefully in a CPU-friendly way. I know that older versions of
>>> the NVidia drivers did this by spinning in a polling loop
>>> inside the driver. I'm not sure if this has been fixed or not.
>>>
>>> From my experience, the latest non-beta Windows NVidia driver seems to eat CPU
>>
>> even with sync to vblank enabled. The CPU usage is always 100%.
>
> Buried in the PPE sources is a 'hackish' but portable way to limit CPU usage if the desired framerate is met
>
> /*
> Frame Rate Limiter.
>
> This prevents any one 3D window from updating faster than
> about 60Hz. This saves a ton of CPU time on fast machines.
>
> ! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV !
> */
>
> static ulClock *ck = NULL ;
>
> if ( frame_rate_limiter )
> {
> if ( ck == NULL )
> {
> ck = new ulClock ;
> ck -> update () ;
> }
>
> int t_ms = (int) ( ck->getDeltaTime() * 1000.0 ) ; /* Convert to ms */
>
> if ( t_ms < 16 )
> ulMilliSecondSleep ( 16 - t_ms ) ;
> }
>
>
I implemented the method pointed out by Norman. It works great on windows and saves me a lot of CPU cycles. This way, I can get the same framerate in moderately populated areas and have CPU idle 50% of the time instead of wildly looping in the NVidia driver while waiting to sync on vblank.
It has been tested on Linux by Melchior. He saw the same gain in CPU cycles.
I have added a --aspect-ratio-multiplier=x.xx option to give some end user
control over the aspect ratio. (This may seem a little strange, but it's a
building block towards the capability of doing asymmetric view frustums in
FlightGear.)
ssgSetNearFar(). This by default creates a symmetric view frustum which is
typically what an application wants.
However, to get control of the view frustum in order to build support for
asymmetric view frustums, we need to wrap these calls with a bit of our own
logic.
This set of changes wraps all calls to ssgSetFOV() and ssgSetNearFar() with
FGRenderer methods.
I also standardized how the FGRenderer class is handled in globals.[ch]xx.
This led to some cascading changes in a variety of source files.
As I was working my way through the changes, I fixed a few warnings along
the way.
I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft.
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
The following patches to SimGear & FlightGear ...
- create an FGMetar abstraction layer, whose purpose is:
* provide defaults for unset values
* interpolate/randomize data (GREATER_THAN)
* derive additional values (time, age, snow cover)
* consider minimum identifier (CAVOK, mil. color codes)
- add rain/hail/snow/snowcover support on the METAR side
- add max age of METAR data handling (currently set to
- add support for an external METAR cache proxy server
- add CAVOK handling
- set missing year/month in regular METAR messages
- fix a small bug in metar.cxx (wrong return value)
explicit calls to shutdown_all() which was causing this to be called twice.
This could cause problems with some IO modules (such as attempting to close
an invalid file descriptor the second time.)
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
I've finished the emigration of the radiostack, and I've also removed it
completely. It turned out that the comm radio is completely implemented in
the ATC subsystem. I've changed the affected ATC files to point
to /instrumentation/com, but I guess that the maintainer of the ATC code
should decide wether to make it configureable, and how.
I also had to change some files in Network and Main. The changes in network
should be obvious, but the changes in Main were a bit suspect. The files
included radiostack.hxx, but they weren't directly depending on
radiostack-hxx. They were depending on other files that were included by
radiostack.hxx. I got it to compile, but I'm not sure if I included the
correct directly depending file.
For the data directory I changed every occurrence of /radios/
with /instrumentation/ with this simple one-liner that I found on the net:
find -name '*.xml' -type f | xargs perl -pi -e
's/\/radios\//\/instrumentation\//g'
Instead of me sending all the files that got changed by this I suggest that
you execute the one-liner yourself. Of course I can not guarantee that this
will work perfectly, but I considered hand editing to be not an option (I'm
lazy). I don't want to test every aircraft to see if everything still works,
I think it's better to wait and see if anyone complaints about broken nav
radios/instruments.
Use a suggested exit method as described in the SDL_Quit man page. (fgOSExit() is still uncalled in both fg_os.cxx (glut) and fg_os_sdl.cxx, which makes these functions kind-of useless.) The other changes are fixes for gcc 3.3.4 warnings.
The caption should already be set when the window is opened. This is
important for some window managers. (KDE's kwin, for example, can store
special settings for certain windows, such as "no border" and "always
on top". KDE uses the window title to determine if a special rule is
to be applied. KDE will be made more tolerant, too.)
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-status={level} --show-aircraft
whereas "level" can be anything between
"alpha","beta","early-production" and "production"
Of course running something like
fgfs --min-status=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required
<status></status>
tag - but you can easily give it a try by adding something like
<status>alpha</status>
The tag should be placed as a sub-tag within <sim> - so directly behind
the <description> tag would be just fine and straight-forward.
I've added two new debug log types for the instrumentation and systems. They
used to use the autopilot debug log, because I couldn't figure out how to
make new log types. Well, now I have figured it out. ;-)
Don't overwrite user settings from config files.
fgfs had in any case set bump-mapping to false, no matter if this
node did already exist (because it was defined in a config file).
This is a patch to make display list usage optional. They are on by default.
Use --prop:/sim/rendering/use-display-list=false to use immediate mode.
There is also a change in exception handling in main.cxx and bootstrap.cxx
erly known as trRenderFrame) is now declared as a NULL function pointer and ass
ignment of the proper function is now done in FlightGear (jpgRenderFrame=FGRend
erer::update).
a working state. I still see an anomoly when taking a screen shot from inside
a 3d cockpit, but external (chase/tower) views seem to work well. I also
added a property to control how many screen-res tiles are generated in the
output. Theoretically, you can now generate unlimited resolution screen shots,
or limited only by your disk space and patience.
Today I successfully generated a 20*1024 x 20*768 (20480x15360) resolution
screen shot. If you rendered that at 100 dpi it would cover a poster of
about 17 feet by 12.8 feet.
Good luck trying to display something that big or convert it to anything
useful on a typical PC. :-)
split). If SimGear is configured --with-jpeg-factory, then FlightGear
will fail to build unless this function is present.
FIXME: this is very messy architecturally -- find a better solution,
like passing this explicitly as a callback to the libJPEG class
(SimGear should not have a dependency on FlightGear).
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 was always only meant to be a test program for the metar lib, but now
that people are referring to it as a means to get metar reports, I think a
usage info is desirable. The list of test ids, on the other hand, isn't
necessary any more. This can still be handled by a Makefile or the commandline.
I'm all for keeping this tool in cvs, however. And also the not-used stuff
therein is a welcome source for how to use the SGMetar class.
