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
1) The AIStorm sets the properties:
/environment/turbulence/magnitude-norm
/environment/turbulence/rate-hz
The actual turbulence effects are handled by the FDM.
If the effects are deemed unrealistic, then that will
have to be fixed in the FDM(s).
2) The zone of turbulence is cylindrical, and is centered
at the AIStorm's lat/lon. The diameter is set with
<diameter-ft>, the top with <height-msl>, the bottom is
assumed to be at <altitude> minus 1000 feet.
3) Note that the zone of turbulence may not match well with
the visual model of the storm. In this case I had to
x-offset the storm model by 4700 meters to match the zone
of turbulence. (i.e. the storm model is 4700m off center).
4) While I was in there I also increased the speed of the
lightning flashes to look more realistic.
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
in terms of predictable packing and byte ordering. So rather than trying to
get fancy and shave a few bits off the structure sizes, just go with 32 bit
ints for everthing which saves a lot of potential headaches in the cross
platform and cross architecture arenas.
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.
was probably my idea of a feature, but if the input buffer actually
does has a length of zero (as Melchior discovered for the case of a
zero-length .nas file) then there will be no null.
Changes
=======
- corrected some strange behavior when playing with the render dialog options
- the density slider is now working : if you are fps limited and still want to see clouds in
the distance you should play with that
- added the choice for texture resolution, its more comprehensible now (before it was
wrongly allways choosing 64x64 textures)
- changed the initial texture size : you now have 64 texture of 64x64, this uses 1Mo of
texture memory (before it was 20 texture of 256x256, that took more memory and there was
not enought impostors)
- sun vector is now right so the lighting is a bit better
- removed useless sort and light computations for impostors, this should save a lot of cpu
- blending of distant cloud is more accurate now
- clouds are now positioned correctly, they don't try to escape you anymore
- no more red/white boxes around cloud
- textures are now filtered (no more big pixels)
known bugs
==========
- distant objects are seen in front of clouds
- new and updated sources for the new volumetric clouds
- 2 new textures for the clouds
- an update to the render dialog to enable/disable and change a few parameters
for the new clouds
I have some small updates to the ground cache.
- Remove the usage of dynamic_cast where it is known that the result will be
non null.
- Renormalize the surface normal in double precision.
- Place the groundcaches center at the point it was requested not at the
scenery center. This fixes the problems with JSBSim's trimming together with
the ground cache. Now I am ready to commit JSBSim's ground cache usage.
I'm looking through the AI code, trying to find the bug that's killing the
thermals. The following things don't look right:
1) AIManager::101 , the Traffic Manager pointer is searched for by name at
every dt. I'll leave this for you to look at.
2) AIManager::295 , the thermal height is not being set. We need to
restore the line: ai_thermal->setHeight(entity->height_msl);
This fixes the thermal problem.
3) AIManager::328 , I changed the fetching of the user state to occur every
sim cycle, and changed the fetching function from by-name lookup to a lookup
by node pointer. It should be faster now, and more accurate too. This helps
the air-refueling.
There weren't changes to this script in a while -- it almost looks
like dead code, but isn't. I'm using this regularly. valgrind works
better than ever (version 3.0 coming out soon, and the alpha already
very usable). New address: http://www.valgrind.org/
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.
