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.
The attached patch allows to put comments in *.stg files[1]. Lines with
# in the first column (and only there!) are skipped. This has no effect
on overall performance, but has two advantages:
A) possibility to temporarily comment out objects during scenery design,
(or to put other remarks there);
B) possibility to put marks like "# BEGIN" and "# END" there that allow
automated merging of local landmarks etc.
--
[1] actually, comments are possible now, too. But they aren't explicitly
handled and fgfs tries to parse words in "comments" piece by piece. Ugly!
[2] Idea by Chris METZLER, that I make already use of. I have a local
scenery dir for some tiles with extra objects, such as VOR/DME for
all of Austria. These are surrounded by "# BEGIN LOCAL" and "# END LOCAL",
and today I was able to merge the new 0.9.7 scenery with my locally
changed files. :-)
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
paging system much more robust when position change is very rapid and sporadic.
Recall that we must load 3d models in the main render thread because model
loading can trigger opengl calls (i.e. with texture loading) and all opengl
calls *must* happen in the main render thread.
To accomplish this we load the base tile in the pager thread and build a work
queue of external models that need to be loaded. We never allow a tile to be
paged out of the tile cache until all it's pending model loads are complete.
However, when changing position very rapidly, we can quickly create a huge
backlog of pending model loads because we are changing positions faster than we
can load the associated models for the existing tiles. The end result is
that tiles that are long out of range can't be removed because there is still
a huge backlog of pending model load requests and memory blows up.
This change being committed allows the tile paging system to remove tiles
if they are out of range, even when there are pending models to load. The
model loading code in the render thread can now check to see if the tile
exists and discard any model load request for tiles that no longer exist.
This situation should never occur in normal operation, but could occur in
"contrived" situations where an external script was rapidly changing
the simulator position to then be able to query FG terrain height, and doing
this for a large number of points that are distributed across a large area.
Wouldn't it be better to prepare the whole list of paths (or two
separate ones for Terrain/Objects if necessary) in FGGlobals::set_fg_scenery,
and to pass the vector<string>s to FGTileEntry::load? It doesn't seem to make
a lot of sense to split the path up, modify it, mount it together to one string
again, and then let FGTileEntry::load split it up again.
Here we go:
Main/globals.cxx
================
As fg_scenery is now a string_list, we don't need initialization. Furthermore,
this list is cleared with every set_fg_scenery() call.
ctor: create default dir from fg_root if necessary. Otherwise check all paths
of --fg-scenery/FG_SCENERY: If the path doesn't exist, ignore it. If it contains
a dir Terrain and/or Objects, then only add that to the list. If it contains
neither, then use the path as is.
Scenery/tileentry.cxx
=====================
Trivial: don't split a "base path", but use the given path_list as is.
(I considered a variable name "path_list" better suited than "search".)
Scenery/FGTileLoader.cxx
========================
No more fiddling with sub-paths. This has to be delivered by get_fg_scenery
already.
account for variation in lighting alignment, but it's more useful than the
previous attempt which was based on a misunderstanding of how environment
mapping worked.
1. Do not stop scanning STG files after OBJECT_BASE is found.
2. Load OBJECT_BASE only once.
3. Load OBJECT only when no OBJECT_BASE has been found or when
OBJECT_BASE was found in the same file (probably should be only the
latter, if we constrain OBJECT_BASE always to come first).
4. Always load OBJECT_STATIC and OBJECT_SHARED.
from the rest of the runway lighting. VASI/PAPI lights are generally
always on. Also, the red/white VASI coloring has never worked right.
This is also a step towards fixing that problem.
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.
search when loading scenery tiles. (I am not set on using ";" as the
delimiter because it is a command separator in unix, but ":" is a critical
part of the windows file naming scheme (c:\foo\bar) so that is even worse.)
Example:
--fg-scenery=/stage/fgfs04/curt/Scenery-0.9.1/Scenery;/stage/helio1/curt/Scenery
-0.7.9
the ascii scenery file format has actually worked in quite some time, and the
ADA runway light code has been supersceded by a slightly different mechanism.
maintianed or upgraded in a *long* time so it didn't support many new
features like the runway lighting. If anyone was using it for anything,
it should not be a huge amount of work to switch to the binary format.
SimGear includes a reader and writer for the binary format.
That's a little too small to resolve differences at 16bpp. Try the
patch below. It decreases the lifting substantially. You will see
a slight increase in z-buffer flickering but it isn't bad. Note
that we removed the "distance" component the other day, the purpose
of it was to lift the lights higher when viewed at shallow viewing
angles. The distance component is critical for the street lights that
can be very long distances away.
But with the distances we're working with here it really doesn't
do all that much. The factor used in this patch is about as shallow
a lift as can be used when looking straight down at the airport. At
24bpp there's no effect from incorporating a distance component.
The choice is to reintroduce a distance component...one that works (and
only for 16bpp), or alter the factor used in the patch below to strike an
acceptable balance between different viewing angles when in 16bpp mode.
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all "3D" cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another "update" hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
"mouse press delay", and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
parts of the tree left over at the end which the failsafe was catching, but
this could impose a huge framerate hit if the missed portion of the tree
was large enough (and it very often was.)
are now working. A runway light is defined by a point and a direction. The
point and direction are combined with the local up vector to create a small
triangle orthogonal to the direction. The two ficticous corners of the
triangle are given an alpha value of zero, the orignal corner is given an
alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT)
mode which means only the corner points are drawn, and since two have alpha=0
only the original point is drawn. This is a long way to go to draw a point,
but it ensures that the point is only visible within 90 degrees of the light
direction, behind the light it is not visible. This is still a long way
to get to drawing a point, but we use an environement map, with the direction
vector as the normal to mimic a light that is brightest when viewed head
on and dimmest when viewed perpendicularly or disappears when viewed from
behind.
- warning, there is a bug in how the current runway light direction vector
is calculated which will adversely effect runway lighting. The airports
should be regenerated in order to fix this problem.
* Finally I think I have the partial ssg tree deletion routine working correctly
after I managed to break it (and other confusion in the code cause it to
never be called so I didn't notice the problem.)
* Converted several SG_INFO statements to SG_DEBUG to clean up some
extraneous console output.
* This *should* conclude my investigation into a massive memory leak. :-)
the tile cache it's ssg elements are disconnected from the main ssg scene
graph, and then the tile is thrown on the end of a delete queue. The
tilemgr->update() routine runs every frame. It looks at this queue and if
it is non-empty, it incrementally frees the compents of the first tile
on the queue. When the tile is completely free it is removed from the queue.
The amount of time to free the memory for even a single tile can be quite
substantial, especially with the increased overhead of dynamic/random
ground objects. This change allows the system to spread the work of freeing
tile memory out over many frames so you don't get a noticable single frame
hit or stutter.
