FG_ENABLE_MULTIPASS_CLOUDS must be defined to enable
the algorithm. I made this because the stencil buffer
must be initialized at the beginning of the program and
OpenGL can fallback to software rendering if it can't
find a visual with stencil buffer. I didn't touch the
configure script, so CXXFLAGS=-DFG_ENABLE_MULTIPASS_CLOUDS
must be set before running ./configure.
If FG_ENABLE_MULTIPASS_CLOUDS is defined, the main render
loop begins by reading the /sim/rendering/multi-pass-clouds
property. It is a boolean property so there are only two
quality levels. false means no multi pass and no use of
the stencil buffer, true means an additionnal pass for
both upper and lower cloud layers.
The algorithms are as follow :
/sim/rendering/multi-pass-clouds=false
1. draw sky dome
2. draw terrain only
3. draw clouds above the viewer
4. draw models except the aircraft
5. draw clouds below the viewer
6. draw the aircraft.
The cloud rendering doesn't update the depth buffer.
This means that models overwrite clouds above the viewer.
This is only noticeable for tall buildings and when
flying very low. Also, drawing low clouds after models
means that they are not blended with models' translucent
surfaces. Large transparent area require alpha test
enabled and AI aircraft canopy are making holes. The
pilot's aircraft being rendered at the end, there is no
problem with canopy or prop disc.
/sim/rendering/multi-pass-clouds=true
1. draw the sky dome
2. draw the terrain only
3. draw all clouds
4. draw models except the aircraft
5. redraw the clouds where the models where drawn ( stencil
test on )
6. draw the aircraft
The assumptions made by this algoritm are that the terrain
is not transparent ( should be true in all cases and
that there are no clouds between the aircraft and the viewer.
Assuming these facts, there should be no blending bugs.
The screenshot rendering is not updated yet.
trying the --show-aircraft option, I noticed that I had
no output. This is because there are still output to
cout or cerr, that are not triggering my console patch
for windows. The patch attached use SG_LOG instead.
A request to hit a key is also added because otherwise,
the console window will disappear as soon as the program
stop.
This problem is minor though given the fact that fgfs.exe
is shipped with fgrun that do show the available aircraft
in a much nicer manner.
places now use sgCartToGeod() instead of rolling their own
approximation. And YASim is now using exactly the same 3D coordinate
system as the rest of FlightGear is.
makes more sense to keep I/O running. That way remote telnet connections
will still respond, and the sim can still accept and send data. This also
allows a remote script or gui to pause and (more importantly) be able to
the unpause the sim.
This patch is there to correct a problem that prevent to load static objects when specifying a relative fg-root or a different, relative, fg-scenery. It appears that there is a mix between fg-root, fg-scenery and PLIB's model-dir.
It has been reported on the list that users are not able to see the buildings, especially those running the win32 builds because they run 'runfgfs.bat' that set FG_ROOT=./DATA.
I decided not to use model-dir because it just add confusion and to build a valid path earlier.
I have added a fledgling replay system that records flight data and control
positions during the flight.
I have added an internal command called "replay" which will trigger a replay
of the entire saved flight data set. This could be bound to a keyboard or
menu command, in fact this entire module is screaming for someone to build
a gui to control playback speed, amount of playback, etc.
This is the initial version so there are kinks that still need to be worked
out, please be patient.
