After much trial and tribulation, Harald came up with a fix for the bug
which has been plaguing Cygwin for a couple of weeks now.
It's only a couple of lines. I've tested it exhaustively, and it seems to
cure the problem of Cygwin failing to start.
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.
just a few split out patches from my zoo of local work ...
The patch to simgear-glxproc.diff changes dlopen to not open a specific library.
If it is used with a NULL argument, we just get a handle to the current running
binary including all loaded libraries. This has the advantage that we do not
rely on the name of libGL on the specific platform.
Also a user can link with his own different named libGL or with a static libGL.a
Then the render texture again ...
glxQueryVersion turns out to return the minimum of the client libraries glx
version and the servers glx version. *All* Xorg servers return 1.2 here.
So we never get the glxPBuffer functions which are the only ones working with
ati's drivers ...
Reverted back to checking the required functions and just use them if they are
there. Still prefering the glx standard variants since they work on ati's
drivers ...
- model.cxx :
load the 2.5D panels before the animations so that the panels can be used in
animations his solve the problem of 2.5D panels visible outside of the
aircraft (one can add a null animation to put the panel at the top of the
aircraft graph so it is drawn first) and this adds the possibility to have
billboarded/popup panels.
- newcloud.cxx :
removed 'this' pointer cast for amd64 compiler.
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.
Melchior has found another bug, I tried to skip some computation for a few
frames but that introduced some bad rendering bug with the aircraft moving
parts.
I corrected that and reduced a bit the cpu usage for ground objects.
- shadow volume vertex are now shared, using DrawElements instead of repeated
calls to glVertex, this can improve performance on some systems.
- added a rendering path that use the alpha channel instead of the stencill
buffer.
- releasing memory when tiles objects are destroyed
- objects sub parts will not cast shadows if their name begins with "noshadow"
or if they are in a <noshadow> animation
- bbcache.cxx :
don't ask for a 32 bits context when the primary context is only 16 bits
- RenderTexture.cpp :
corrected a crash when asking for a second rendering context
on win32 and extensions not being supported
- model.cxx, animation.cxx :
added a <noshadow> animation, added an animation type needed by the shadow
code.
- check for isTied() and refcount has to be made *before* we go into
recursion, so as to pertain subtrees of refcounted nodes, even if there
are no refcounted/tied nodes *in* this tree
- return value inverted, because it's more logical to say
removeChildren() == true --> everything removed; false --> failed
- further cleanup
- introduce removeChildren() and removeChildren(name) to remove all children
or all with a given name
- let removeChild() and removeChildren() also remove child trees, and let them
return a "dirty" boolean that indicates if one or more subnodes had to be
kept because of refcounting (removeChild returned a SGPropertyNode_ptr before)
- make alias/unalias increase/decrease the refcounter
- don't remove refcounted or tied nodes
This patch makes the SGPropertyNode_ptr actually useful. Until today, they did
proper refcounting (except for aliases), but no other part did check this counter.
But SGPropertyNode_ptr aren't only useful for the first time, they are now
highly recommended for every place that relies on a node address, and wants
to "lock" it (so that removeChild(ren) will never try to remove them). This
is not guaranteed for SGPropertyNode* (and never was). Of course, that's not
an imminent problem, as only four places currently use removeChild(ren) and
these are careful to only remove their own data.
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
This is the more elegant solution that Andy had proposed in a response
to my RFC on Nasal initialization code in joystick configuration files.
As Nasal is initialized last (for good reason), subsystem can currently
not use it for initializing. postinit() is called on all subsystems
after all have been initialized.
Changes
=======
- changed the rotation of sprites, they don't rotate strangely when we
approach them now
- corrected the strange movement of clouds when banking quickly
- it no more rain above cloud layers
- add a radar echo container used by the weather radar instrument
patches; my private version has rewritten both of these functions
(ironically fixing these bugs in the process) to handle negative
offsets meaning "from the end".
Turn the material animation's <transparency> property into a group, with
members <alpha-prop>/<alpha>, <offset-prop>/<offset>, <factor-prop>/<factor>,
<min>, and <max>. The "material" animation can now fully replace "blend" and
"alpha-test" (--> <threshold>) animations, with enhanced possibilities:
The "material" animation can be used for one or more explicit objects (like
"blend"), but also for all objects that share one material (<global>), which
avoids problems with objects being forced together into one tree. Also, an
object doesn't have to be semitransparent or textured with a semitransparent
texture to make blending work. Unlike the "blend" animation, the "material"
animation also makes fully opaque and untextured objects transparent. (This
fixes the bo105's formerly semi-transparent rotor.)
Erik:
The blend animation and alpha-test animation are depreciated as of now.
Currently, the material animation sets glColorMaterial(GL_AMBIENT_AND_DIFFUSE)
for all material properties. This breaks emission-only (e.g. cockpit lighting
for the p51d) or specular-only animation. ==> set glColorMaterial only where
it is really required.
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.
Vivian pointed out that a redefined Ctrl-U key binding didn't work
correctly. I found out that this is, because the definition in
$FG_ROOT/keyboard.xml sets <value type="bool"> for binding[1],
and ... [better sit down first!] ... and assigning <value type="double">
in a *-set.xml file doesn't *really* set "double" as new type!
Instead, the boolean is kept, and a double sqeezed into it. In other
words: once tainted as bool, you can throw all doubles in the universe
on a property node, and all it will accept is 0 and 1. Without warning!
BTW: I changed the patch: I was overly cautious: clear_value() does already
care for ties and for setting NONE, so we just need to make that public as
clearValue(), and use that. Makes the patch a bit more verbose, though. :-/
This is a minor bug fix for sgBucketDiff().
If you crossed the bucket size boundary, the answer for dx could be wrong.
E.g.
going from 0:0, 21:7 to 0:7, 21:7 would give you dx = 7 (correct)
but going from 0:0, 21:7 to 0:3, 22:0 would give you dx = 6 (instead of 7)
Previously it differenced the center longitudes of the buckets. When you
cross a boundary, the center point of the larger bucket now lies on the edge of the smaller bucket.
The result was a dx with an integer + 1/2 bucket, which rint() was rounding to the nearest even int.
This function only seems to be used in TerraGear.
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 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.
