All logs and log entries are now disabled by default, unless
explicitly enabled by an 'enabled' property. This works much more
intuitively with the GUI dialog.
the whole electrical system. We will also need a mechanism to kill
individual suppliers (such as the alternator), but this is good enough
for most training.
if the station is too far away. Instead, simply return the closest station.
All the code that searches navaids does it's own range checking anyway.
This will make the navlist query functions a bit more useful for other
types of functionality where you may need to lookup a station without
consideration of range (i.e. presetting your position relative to a navaid.)
a spinning gyro.
Changed FGInstrumentMgr to inherit from FGSubsystemGroup, greatly
simplifying the (already simple) class. I should probably rename this
to FGInstrumentGroup or something similar, but not today.
Added the gyroscopic turn indicator (part of the TC).
hemisphere the distance is positive, if you are in the departure hemisphere
the distance is negature. (Possible use for graphing approach distance
vs. glide slope or cdi.)
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
(I thought I'd slip this in along with David's change to the default menu
configure option. I believe that will cause a new config.h to be generated
which will cause a near complete rebuild of FG (as will this globals.hxx
change) so it shouldn't cause additional grief to have these happen at the
same time.)
menubar. This one allows regular command bindings, with the
(temporary) condition that every menu item must have a unique text
label. The new menubar is disabled by default; to enable it,
configure --with-new-menubar.
input bindings. They will work only with the latest CVS; otherwise,
./configure will disable them. There is a new command, 'script',
which takes a single argument, also called 'script', containing PSL
code (currently PSL requires a main() function).
Erik Hofman has written some more elaborate code for triggering PSL
code from drop-down menus and scheduling events; I will look at
integrating that next.
and property-multiply:
Firstly, change back to wrapping modulo the interval, with "min <= x <
max" semantics. I believe the previous implementation did that. The
inline function that Norman mentioned also does that.
Secondly, make it snap to the nearest value (min + N*resolution) when a
"resolution" tag is present, taking special care of floating-point
precision. Or perhaps specify "number of divisions in the interval" as
an integer, instead of "resolution" by which I meant a floating-point
"size of a division".
[also fixed]
While working on this file I noticed some potentially serious warnings:
fg_commands.cxx: In function `bool do_property_adjust(const
SGPropertyNode*)':
fg_commands.cxx:435: warning: control reaches end of non-void function
fg_commands.cxx: In function `bool do_property_multiply(const
SGPropertyNode*)':
fg_commands.cxx:465: warning: control reaches end of non-void function
/usr/local/include/simgear/misc/props.hxx: At top level:
fg_commands.cxx:600: warning: `bool do_presets_commit(const
SGPropertyNode*)' defined but not used
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
experimental lighting rendering (which is very expensive on my
machine, for example). To use distance attenuation,
/sim/rendering/distance-attenuation must also be true.
It adds a command line options to enable/disbale distance attenuation
using a property rather than using a #define inside the code. It also
adds a small change for systems that don't support the OpenGL extension,
so that the lights *do* fade away as they get furher away but they don't
get smaller in size.
property-adjust.
Modified property-adjust and property-multiply so that they always
work with double values, to simplify the code.
Factored out some common code.
Added a 'mask' argument to the property-adjust and property-multiply
commands. If mask is set to "all" (the default), then the command
works as before; if mask is set to "integer", it works only to the
left of the decimal point; and if mask is set to "decimal", it works
only to the right of the decimal place. This functionality is useful
for tuning VHF COM and NAV radios.
Ensure that if a condition for a panel mouse binding fails, other
bindings for the same area will have a chance to run.
Add a repeatable flag for panel mouse bindings (defaults to true).
- dialog-open
- dialog-close
- dialog-update
- dialog-apply
The last two can copy a value from a property to a GUI field or
vice-versa either individually or across the whole dialog.
really useful unless we simultaneously change the per-iteration deltas
to be smaller. Add another pseudo-tunable to control the speed with
which we change values across iterations. As it turns out, this is
much more effective than the threshold tunable. It does come at the
cost of lower solution performance, however.
I wrote:
> I can confirm this. Layers on the 2D panels (but oddly, only the 2D
> panels) aren't drawing over the background with the current ATI
> drivers.
OK, this turns out to be a trivial fix, although I still think it's a
driver bug. There are two calls to glPolygonOffset in the panel
rendering code (shared by both 2D and 3D panels). One is called
per-layer, and sets up a layer-specific offset. The other is called
for drawing the background textures, to lift them off of any
underlying cockpit geometry.
I was using different "factor" values for each, incorrectly. Patch
attached. It was affecting only 2D panels because the 3D ones don't
use background images.
Problem is, by my reading of the specification the bug should have had
the effect of pushing the background texture *farther* behind the
instruments, instead of pulling it on top of them. Either I'm reading
the spec incorrectly or ATI has inverted the sense of the factor
argument. Dunno, I'll submit a bug report to them and see what
happens.
Link the standalone executable against the source files explicitly rather
than libYASim, as the Irix linker can't handle the unneeded dependance on
other parts of FlightGear.
isn't well-constrained by the solution process is the drag-vs-aoa curve.
The default value that YASim picked was very steep, and resulted in most
of the jets flying their approaches *way* behind the power curve. This
changes the default to be more forgiving, and adds an "idrag" tunable
to the configuration file for tweakers.
Also, change the default gear springiness to be less stiff.
Changed steering to use the rudder command rather than the rudder
position. During taxi, the rudder trim shouldn't affect the steering
in any serious way.
This should be configurable in the aircraft file, since not all
aircraft use the rudder pedals for ground steering.
[In FlightGear, this may make it easier to taxi straight.]
I have updated the lighting code to use fog to try to fade the runway lights
in smoothly, but still keep them from being visible until you are about 7-10
miles out, and then only have them be very faint at first. I think what I
have is a bit nicer than before since it completely avoids the "popping" effect,
but I've very open to tweaking the actual ranges based on people's real
world experiences.
option to specify a starting airport + specific runway. If you don't specify
a runway, you get the one that's closest to your specified (or default)
heading.
To compile the development CVS version of FlightGear(0.9.0) i had to
apply some small changes to SimGear and FlightGear.
The changes need probably some additional ifdefs for other platforms but
since my linux-hd crashed i can't verify that.
Here's a patch to fix the offsets bug. The problem was the transform was just
getting added to a local instance rather than being returned by the function.
> Jim Wilson wrote:
> > How hard would it be to have a property that toggles hotspot
> > visibility? It'd be nice to be able to turn it on and have yellow
> > rectangles show up on the hotspots...
>
> That's not a bad idea.
It's actually an astoundingly good idea, and implementable over lunch
to boot. :)
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property. I mapped a toggle event on this to a
spare joystick button, and had fun. :)
[dpm: bound to Ctrl-C]
avoid having the 2D instruments obscure 3D objects in front of them):
It's related to depth buffer precision. On my Geforce cards (2MX and
3), it never happens with the 24 bit depth buffer you get by default
at 32bpp. At 16bpp, it picks a slimmer depth buffer (probably 16 bit)
and the texture layers bleed through.
The code is using a pretty big argument to glPolygonOffset, and I've
never investigated how small it can be. If someone has a little time
the next time they see this issue, try changing the value of
POFF_UNITS at the top of Cockpit/panel.cxx. Decrease it until the
textures *just* start to interfere with each other, and post the value
that works for you.
The general idea is to help clean up some aspects of the FDM init and be
able to provide startup conditions in a less ambiguous manner.
Previously, things like positions, orientations, and velocites were set on
"the bus". These had to be read by the FDMs which then were supposed to
initialized themselves to those values and turn write around and start
modifying those values. It was messy and cumbersome.
Now, all the initial fdm conditions are written to a sub-[property-]tree
under /sim/presets/
The values in /sim/presets/ always stay set to what the user has specified.
The user can change these at his/her liesure, and then request a "reset"
which will reset to the new conditions. I don't even want to say how this
worked before. :-)
Now, an script, or gui interface can stage a set of initial conditions while
the sim is running (without disrupting it), and then call "reset" to commit
the change.
People who should worry about all this are FDM writters, and a small few
others who care about over all program structure and flow.
duration-sec. This animation may have any number of child objects,
and each one will be displayed for the requested duration before
moving on to the next one.
Added Animation::init for initialization after children have been
added to an animation.
Added a default implementation of Animation::update, and removed all
of the empty ones in derived classes.
Removed tabs from model.cxx.
Indeed, there was no check for panel visibility in the input code. I
guess we've never noticed because nothing was fighting for the same
real estate in the past. This one-liner appears to fix the problem.
[also converted all tabs to spaces for Norm Vine]
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.)
rabbit lights appear to almost work except the last light or two is never
included in the animation and longer strings of lights are drawn as all
light on ... :-(
a tile boundary. (Potentially imposes a slight performance penalty, but
getting the correct answer needs to be higher priority than getting the
wrong answer really quickly.)
I noticed that textures for scenery static objects are not loaded
anymore for a few weeks. Static objects have absolute path while
random objects and aircraft have relative path but fgLoad3DModel
unconditionally prepend fg_root to the model path. This patch test the
beginning of the model path to choose if fg_root has to be prepended
to the model path.
Ok, I found the problem. You're computing the dynamic pressure in
"psf" and adding it to the static pressure in "inHg" to form the
total pressure. The attached patch is the simple fix to the source.
With that fix, failing the pitot while in cruise at 3k' will cause
the airspeed to indicate beyond redline during climb ... well before 4k'.
Thus, a pitot problem can be detected on any IFR altitude change.
Similarly, failing the static (with working pitot) while cruising 4k'
causes the airspeed to indicate beyond redline during a descent
well before reaching 3k' (during which, of course, the ALT looks fine).
Thus, a static failure can be detected before the aircraft breaks out
of the pilot tolerance range and is blatantly conspicuous soon after.
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.
This adds supports for a language specific font, defined in locale.xml
I've also moved the fgInitLocale() routine from main.cxx to fg_init.cxx
to prevent an ungly extern definition in options.cxx.
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.
The FGGlobals constructor does not initialise the locale pointer.
Under MSVC, uninitialized pointer have a value of 0xcdcdcdcd, not
0, so a test in mainLoop fails and the program segfault.
This patch set un initial value to locale.
This patch fixes some bugs for correctly reporting un-updated
configuration files, and adds support for a --language=<code>
commandline option, overriding the language specified by the OS.
KEMT (w120n30 scenery), and you will have to set the property
/sim/ai-traffic/enabled to 'true' to see the other plane (and tune
comm1 to 121.2 to hear the other plane's radio calls).
For sounds that play while a value is in transit, use time rather than
the number of frames to judge when to halt the sound because it will be much
more reliable on high performance systems. It currently waits 10 ms.
before stopping the sound, but you might want to fiddle it a little by
changing MAX_TRANSIT_TIME defined int fg_sound.hxx
really see anything different in the day, but as day turns to night the
panel smoothly darkens and the lighting component becomes visible.
Lights are wired to electrical system so if you kill power, you lose the
lights.
The code reads the electrical system config and contructs an internal model.
Nothing is done beyond that yet ... the electrical system is not updated,
nor is it connected to the property system in anyway.
fgLoad3DModel() throws an exception if it fails to load the requested model.
This causes FGTileMgr::update(...) to exit. So I've added a try/catch block
to catch the exception and display an error message instead.
jump whenever you cross a tile, but there are currently a lot of other
positioning problems as well, so this doesn't really detract too much and
means you can play with 3d clouds from just about any starting point.
A bug lurked into our uiuc code.
There are two changes:
[1] Comment out the chunk of code as shown (compare w/ the old)
[2] Put back in the function call, and in that code change AlphaTail to Alpha.
Use getDisplayName instead of duplicated code: gives a better
decision on whether to display the index.
Replace unnecessary node lookups by name with direct access: tidier
and more efficient. E.g. "getValueTypeString
(node->getNode(name.c_str()))" -> "getValueTypeString (child)".
When the scroll bar slider is dragged, the list scrolls only far
enough to see all items; only the arrow buttons can scroll it so far
that the last item goes to the top of the view.
Fix scroll bar proportional size: was wrong when the list was only
a little longer than the visible area.
Minor fixes such as "delete files[i];" -> "delete[] files[i];"
(where the item being deleted is an array of characters) and removal of
global variables.
Smooth scrolling when dragging the slider: one item at a time,
rather than one tenth of the list at a time.
Fix a bug that would have occurred if instantiated with arrows=2.
Sort properties primarily by name and then by numerical index
order, rather than a simple ASCII string order. E.g. "js[1]", "js[2]",
"js[10]" rather than "js[1]", "js[10]", "js[2]".
Avoid crashing if the selected property path does not exist;
display an empty list instead. This cannot happen when the property
picker is working properly, but did happen due to missing indices prior
to this patch, and could happen if the user is allowed to type a
pathname, as in the http and telnet interfaces.
Fix truncation of strings to PUSTRING_MAX: was wrong when string
length was exactly 80.
Fix: move the scroll bar to the top each time a new list is
displayed. It was left at its previous position, while the top of the
new list was displayed, not corresponding to the slider.
Use getDisplayName instead of duplicated code: gives a better
decision on whether to display the index, and avoids invalid property
paths being generated which would previously crash find_props().
Replace unnecessary node lookups by name with direct access: tidier
and more efficient. E.g. "getValueTypeString
(node->getNode(name.c_str()))" -> "getValueTypeString (child)".
speedups to uiuc_menu.cpp.
(Note these were originally submitted before the cutoff date for new
features, but something was corrupted in the transfer so I granted a bit
of leeway in the schedule.)
I removed some pending random code and I also fixed a
small cosmetic glitch where dt_play was cleared before it was printed.
Curt: Erik changed the sound update intervale and I further I tweaked it.
The issue is that if we put too much into the sound buffer, then we can't react
quick enough to sounds like tire squeek that need to be synced with the visuals
and the action. We put too little into the sound buffer and we risk the
audio dropping out for moment if a frame takes longer to draw than the amount
of audio in the buffer.
I've modified the code to display a brief help message instead of the
whole bunch of options. To get the complete message -v or --verbose has
to be added to the command line.
Here is a FGIO class derived from FGSubsystem that replaces the fgIOInit()
and fgIOProcess() functions. The FGIO::update(double delta) doesn't use the
delta argument yet. I suspect it could be used as a replacement for the
calculated interval value but I'm not familiar enough with that piece of code
just yet.
I've also added two "command properties" to fg_commands.cxx that select the
next or previous view. Writing any value to these properties triggers the
corresponding action. As an example I modified my keyboard.xml:
<key n="118">
<name>v</name>
<desc>Next view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/next</property>
<value type="bool">true</value>
</binding>
</key>
<key n="86">
<name>V</name>
<desc>Prev view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/prev</property>
<value type="bool">true</value>
</binding>
</key>
And of course these actions can also be triggered from external scripts via
the props server.
- 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.
* 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. :-)
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.
I've merged FGProps and FGTelnet so there is just a single property server.
I've left in the --telnet=port# command line option but it could be removed
if we wanted to. The command line accepts two forms of the --props option.
The original (--props=medium,dir,hz,host,port#,style) and the shorter
--props=port#. If you accept this change then src/Network/telnet.[ch]xx
can be removed from the cvs repository.
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]
When the scroll bar slider is dragged, the list scrolls only far enough to see all items; only the arrow buttons can scroll it so far that the last item goes to the top of the view.
Fix scroll bar proportional size: was wrong when the list was only a little longer than the visible area.
Minor fixes such as "delete files[i];" -> "delete[] files[i];" (where the item being deleted is an array of characters) and removal of global variables.
Smooth scrolling when dragging the slider: one item at a time, rather than one tenth of the list at a time.
Fix a bug that would have occurred if instantiated with arrows=2.
Sort properties primarily by name and then by numerical index order, rather than a simple ASCII string order. E.g. "js[1]", "js[2]", "js[10]" rather than "js[1]", "js[10]", "js[2]".
Avoid crashing if the selected property path does not exist; display an empty list instead. This cannot happen when the property picker is working properly, but did happen due to missing indices prior to this patch, and could happen if the user is allowed to type a pathname, as in the http and telnet interfaces.
Fix truncation of strings to PUSTRING_MAX: was wrong when string length was exactly 80.
Fix: move the scroll bar to the top each time a new list is displayed. It was left at its previous position, while the top of the new list was displayed, not corresponding to the slider.
Use getDisplayName instead of duplicated code: gives a better decision on whether to display the index, and avoids invalid property paths being generated which would previously crash find_props().
Replace unnecessary node lookups by name with direct access: tidier and more efficient. E.g. "getValueTypeString (node->getNode(name.c_str()))" -> "getValueTypeString (child)".
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.
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.
the triangles containing the objects were out of the view Frustum,
they were never traversed by ssg (and thus, never culled). Now, every
200 frames, do a pass through the whole scene graph with cull-testing
disabled and without drawing anything; that will allow random-objects
to be collected incrementally.
-----------------------------------------------
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.
- tidies up the update-time-step handling (making it a simple "dt");
- makes the altimeter get a proper pressure, and the (unused) vacuum
calculation get a proper RPM (*);
- replaces property name look-ups with static pointers to property nodes.
Notes from DPM:
- the static pointers are a very bad idea, but they're only temporary;
I plan to make FGSteam into a proper subsystem soon, and then they
can be member variables
- I fixed the patch to get the current static pressure from the
/environment/pressure-inhg property, so that the altimeter interacts
properly with FGEnvironment
The present sets of bindings result in the throttle being "squared"
about its centre, which is silly. This is because the "squared"
parameter is not set by the throttle binding, but the default is
"true". We discussed this before and I think there was general
agreement that the default should be "false" on the basis of
generality.
situations for every kind of airplane. But at the moment we have nothing
implimented and this will cover the simpler cases until someone has a
chance to impliment a fuller solution.
GL/gl.h can't be included at the first position in windows. It requires
the inclusion of windows.h that must be included in other fgfs header
file. I only move down #include <GL/gl.h>
This patch eliminates about 10 of valgrind's "Use of uninitialised
value of size ..." messages. They are all caused by approachlist building
incomplete FGApproach class instances and then copying them into the
approchlist container, hence copying data garbage.
I know, I couldn't win a beauty contest with this patch, but the
alternative approach -- letting operator<< always leave complete
entries -- didn't look any better. And I do only add those seemingly
useless initialization where the values would be used uninitialized
else. The constructors are only run during setup and won't slow fgfs
down at runtime.
Make locally-used strings local instead of global. (The safety and
cleanliness benefit outweights the slight performance hit. If
performance is an issue, the way these strings are used should be
optimised.) Use existing defined constant instead of a literal
number.
+ The panel(s) are now an first-class SSG node inside the aircraft
scene graph. There's a little code added to model.cxx to handle the
parsing, but most of the changes are inside the new FGPanelNode
class (Model/panelnode.[ch]xx).
+ The old FGPanel source changed a lot, but mostly cosmetically. The
virtual-cockpit code moved out into FGPanelNode, and the core
rendering has been abstracted into a draw() method that doesn't try
to set any OpenGL state. I also replaced the old inter-layer offset
code with glPolygonOffset, as calculating the right Z values is hard
across the funky modelview matrix I need to use. The older virtual
panel code got away with it by disabling depth test, thus the "panel
draws on top of yoke" bug. PolygonOffset is really the appropriate
solution for this sort of task anyway.
+ The /sim/virtual-cockpit property is no more. The 2D panels are
still specified in the -set.xml file, but 3D panels are part of the
model file.
+ You can have as many 3D panels as you like.
Problems:
+ The mouse support isn't ready yet, so the 3D panels still aren't
interactive. Soon to come.
+ Being part of the same scene graph as the model, the 3D panels now
"jitter" in exactly the same way. While this makes the jitter of
the attitude gyro less noticeable, it's still *very* noticeable and
annoying. I looked hard for this, and am at this point convinced
that the problem is with the two orientation computations. We have
one in FGLocation that is used by the model code, and one in
FGViewer that is used at the top of the scene graph. My suspicion
is that they don't agree exactly, so the final orientation matrix is
the right answer plus the difference. I did rule out the FDMs
though. None of them show more than about 0.0001 degree of
orientation change between frames for a stopped aircraft. That's
within an order of magnitude of what you'd expect for the
orientation change due to the rotation of the earth (which we don't
model -- I cite it only as evidence of how small this is); far, far
less than one pixel on the screen.
[and later]
OK, this is fixed by the attached panel.cxx file. What's happened is
that the winding order for the text layer's polygons is wrong, so I
reverse it before drawing. That's largely a hatchet job to make
things work for now, though. We should figure out why the winding
order is wrong for only text layers and fix it. I checked the plib
sources -- they're definitely doing things CCW, as is all the rest of
the panel code.
Odd. I'm also not sure why the 2D panel doesn't care (it works in
both winding orders). But this will allow you to check in working
code, anyway. There's a big comment to this effect in there.
instrument. This needs to move somewhere permanent.
Also, remove a bogus fuel consumption setting that (1) was off by a factor
of 3600 (hours, not seconds) and (2) collided with identical code in FGFDM.
the amount of drag that the produced lift *would* have produced given an
unflapped air surface. A nifty trick involving the assumption that AoA is
small works for this, and produces plausible results in the high AoA case
as well.
Also, trim for approach using the elevator-trim control, not elevator.
Just cosmetic for current planes, but future ones might have differing
implementations of trim.
This is the small code fix which is needed for the new options.xml file.
It is needed because otherwise the "--prop:name=value" is showed
incorrectly.
There is another problem though, when compiling with --without-logging
the help message isn't displayed at all! We *must* change that somehow.
Curt: good point, the SG_LOG()'s have been switched to cout's ...
(and not the throttle setting), but the recalculation left in a degeneracy
when the target/throttle setting was exactly zero. Zero times a big number
is still zero. Fixed to use real math, not theoretical math.
- More progress with proper radio freq tuning and proper interpreting of the
hardware values.
- Filter ignition and flap switch values since the hardware implimentation has
a dead zone where the value can go to zero in the middle of a change in
switch position.
I've updated the FIXME in the code, and fixed a typo (descr instead of
description), but the SG_LOG() functions doesn't produce any output for
me. Could you confirm it's still working for you?
Curt Olson:
I did a bit of further tweaking and it all looks good now. The tricky thing
is that SG_LOG() always appends an endl at the end of every message.
This is an enhanced version of the options patch.
It's more robust now, and gives some helpful information if something
goes wrong. Also the naming in the options.xml file has changed to the
syntax David suggested.
Since no one objected to the patch I think it is safe to included it.
class, FGModelPlacement, while FG3DModel retains control of animation.
This way, we can have a single, top-level placement, but multiple
layers of nested models underneath. To include a nested model, use
something like this in the XML wrapper:
<model>
<path>Models/Stuff/my-component.xml</path>
<offsets>
<roll-offset-deg>45</roll-offset-deg>
</offsets>
</model>
contain colon-separated ranges. For examples, winds from 180 degrees
10 knots gusting 15 knots would be
--wind=180@10:15
Winds variable from 180-220 degrees 5 knots would be
--wind=180:220@5
FGEnvironment does not yet support variable-direction winds, so
nothing will yet happen in the second case.
Modifications to support querying navaid database by station ID (not just
frequency.) Some corresponding changes to testnavs.cxx to test new
functionality.
This is a small patch that makes the autopilot work much better with big heavy
airliners as well as the small Cessnas. Of course this doesn't address the
way autopilots should be modeled.
But by making a couple changes the "George" is now capable of landing either a
C172 or a 747 very close to the center line of the runway with a moderate
cross breeze (15-20kt).
The changes:
- Added turn configurability so that things like Max Aileron and Roll can be
configured per aircraft.
- Enhanced localizer routine (NAV mode) to begin lining up the aircraft as soon
as the cone is entered. The former model is adopted for the last 5km of the
approach in order to ensure greater precision (makes a very slight difference).
[float cast added by David Megginson to keep G++ 3.0 happy]
This is a small patch that makes the autopilot work much better with big heavy
airliners as well as the small Cessnas. Of course this doesn't address the
way autopilots should be modeled.
But by making a couple changes the "George" is now capable of landing either a
C172 or a 747 very close to the center line of the runway with a moderate
cross breeze (15-20kt).
The changes:
- Added turn configurability so that things like Max Aileron and Roll can be
configured per aircraft.
- Enhanced localizer routine (NAV mode) to begin lining up the aircraft as soon
as the cone is entered. The former model is adopted for the last 5km of the
approach in order to ensure greater precision (makes a very slight difference).
[float cast added by David Megginson to keep G++ 3.0 happy]
1. Typo where /environment/density-inhg instead of
/environment/density-slugft3 was flagged as archivable.
2. Density should no longer be archivable anyway, since it is
calculated internally and not directly settable by the user.
temperature, and dewpoint. The /environment/density-sea-level-slugft3
property has been removed, and the /environment/density-slugft3
property is read-only.
Fetch all pending remote fdm network packets so there is not chance of
getting behind.
Add support for driving control panel lights.
Working on better modeling KX 155 tuning behavior.
won't apply the right gross weight due to fuel differences.
When solving for zero force, do so in the global frame, not the
aircraft's. In principle, this shouldn't matter (zero is zero in all
frames), but in practice this should help to avoid oscillations.
Calculating lift as force perpendicular to the ground (and not the
wing plane) is clearly the Right Thing, anyway.
Also added support for a /yasim/gross-weight-lbs property, which
should be generically useful.
