Now the options can be localized as well. This adds a slight problem for
the --language options, but not that much (worst case, the strings are
loaded twice consuming some more memory). I tried to be as accurate as
posiible when copying the options texts, but there might be some
mostakes left.
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.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Here are some changes that gave me a significant frame rate increase of about 10 fps with random objects disabled. The interesting thing is that these changes aren't in the main loop but are in tile loader. My guess is that I've reduced the memory footprint just enough to reduce CPU cache misses, though I have no hard evidence of this.
Initially I modified all SGBinObject member functions to pass/return by reference instead of by-value. This gives little or no speed up but allows for some optimizations in fgBinObjLoad(). It is these changes that reduce the number of memory allocations. Needless copying of vectors, and vectors of vectors, can be very memory intensive, especially if they are large.
Anyway I would be interested to see if you get similar results. I would emphasize that the frame rate increase only occurs with random objects disabled. I lose about 10-15 fps on my GF2MX 32MB with random objects, probably a fill-rate limitation or texture memory thing.
Animations are now contained within the scene graph itself and are
updated whenever the graph is traversed -- that saves time by not
updating animations not currently in sight, and it allows animations
to be used for static objects and random objects as well.
Added new FGModelLoader and FGTextureLoader classes. These are intern
tables for models, to guarantee (mostly) that no model is loaded more
than once. FGTextureLoader is not yet used anywhere, but
FGModelLoader is now in place everywhere that ssgLoad* used to be
used (thus adding the ability to use animations).
In the future, FGModelLoader will add some interesting functionality,
including the ability to reload 3D models on the fly.
Your 3D models cause a stackdump when the base is separate from the
root. I've attached a patched newmat.cxx - you may want to test it
before committing!
I changed the code such that textures terrain also takes ambient,
diffuse, specular and emissive from the materials.xml file.
[note from dpm: doesn't seem to work yet]
name "random-objects".
Put the random objects for each tile inside a top-level
ssgRangeSelector with a maximum range of 20km. This saves a lot of
range tests for distant tiles, and gives about a 10% framerate boost
on my card at 1000ft AGL (possibly more on faster cards).
instead, use a separate dummy bounding sphere for each triangle and
each tile, with the actual bounds, to make sure that objects are
always added when they should be in sight.
-----------------------------------------------
Fixed a segfault on exit.
Changed the radius of the dummy bounding sphere from 10m to 1000m to
ensure that FOV culling doesn't leave anything out.
Allow an object to have more than one variant model, which will be
chosen randomly. Simply repeat the <path>...</path> property.
Removed the <billboard> property and replaced it with <heading-type>,
which can be set to "fixed" (leave the model oriented as it is),
"random" (give the model a random heading between 0 and 359 deg), or
"billboard" (always turn the model to face the camera). The default
is "fixed". Models look much better when they are not all facing the
same direction.
Allow the user to group models with the same visual range, so that
there can be *many* fewer nodes in the scene graph when the models are
not visible. This causes an XML-format change, so that instead of
<object>
<range-m>...</range-m>
...
</object>
<object>
<range-m>...</range-m>
...
</object>
...
we now have
<object-group>
<range-m>...</range-m>
<object>
...
</object>
<object>
...
</object>
...
</object-group>
Every object in a group can still have its own model(s), coverage, and
heading-type, but they all share the same range selector.
This change should already help users with tight memory constraints,
but it will matter much more when we add more object types -- for
example, we can now add dozens of different urban building types
without bloating the scene graph or slowing down the LOD tests for
tris that are out of range (i.e. most of them).
1. Only one copy of each object (and its texture) is stored in memory,
no matter how many materials use it.
2. Random objects are added to a triangle only when the objects are in
range, and they are deleted as soon as the objects are out of
range. That way, only a relatively small number of ssg nodes are
used at any one time.
This patch seems to eliminate freezes when tiles are freed. There are
occasional stutters at extremely high speeds (i.e. over 3,000kt), but
it seems smooth enough for normal aviation speeds.
- no extra nodes are created at all if the material has no random
objects defined
- the range selector is place correctly under the transformation
- there is only one range selector for each object type in each
triangle (experimental -- doesn't seem to make a difference in speed
or memory)
This patch removes Curt's patch that randomized ranges slightly, since
individual random objects no longer have their own range selectors.
It also leaves the object-group-range value unused, for now.
The FlightGear patch is to take account the change in the getChildren
function that now returns a vector<SGPropertyNode_ptr>. If the
removeChild functionnality is to be added in FlightGear, all those
SGPropertyNode * floating around should be changed to
SGPropertyNode_ptr.
The first hunk might not be necessary, but the light_coverage property
was the only one that wasn't explicitly defaulted, which is unfair. ;-)
The second hunk adds the missing initialization to the init routine.
This is necessary, because (unlike the material entries from material.xml)
the generated light entries don't get the light coverage set. Yet
obj.cxx:795 reads this information out fot every leaf, although not needed
in the case of lights. Avoiding this isn't worth the trouble.
The last hunk sets the missing normal_index. The POINTS branch in
gen_leaf was always called with this int_list empty, which made the normals
handling use data garbage.
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
