[Flightgear-devel] LFRK scenery
Hi, I have improved the apt.dat.gz for Caen-Carpiquet (LFRK) but I have a problem with TerraGear: the terrain is too low and there are holes. Can someone generate the scenery or explain me how to do?? I'll place some points (a antenna, a cement work, a bridge...) Thank you, Guillaume LFRK.dat Description: MOPAC data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi,
It looks like I'm beginning to get a bit of a handle on the periodic hang-ups
appearing in FlightGear/Plib.
All tests ran on an AMD Athlon XP 2400+, 1024 MB ram, with a GeForce FX 5700
(256 mb texture ram IIRC) video card (AGP based). Suse Linux 10.2 is
installed, and FlightGear, SimGear, and plib were compiled using
gcc 4.1.2 20061115 (prerelease) (SUSE Linux)
Tests were conducted using the following settings in my .fgfsrc file:
--airport=EHAM
--time-match-local
--prop:/environment/params/real-world-weather-fetch=true
--fg-scenery=/home/durk/FlightGear-Scenery-0.9.10/
--fg-root=/home/durk/src/FlightGear-0.9/data-cvs
#--atlas=socket,out,1,localhost,5500,udp
#--nmea=socket,out,1,42.0.1.4,5501,udp
--verbose
--visibility-miles=25
--geometry=1280x1024
Using the SenecaII-jsbsim as aircraft, specified on the command line. Here are
some results.
Firstly, yesterday I managed to speed-up the replay system, by using dynamic
allocation instead of pushing copies of rather large objects into the STL
lists. Using the timestamping code I mentioned yesterday, and committed to
CVS earler today, I found that memory allocation was very slow on my machine.
By preallocating a significant number of replay objects, and recycling used
ones instead of reallocating them I managed to get minimize the amount of
replay timing errors considerably.
Secondly, there are a selected number of processes that take disproportionally
long to execute. The most significant one I found sofar is a call in
src/Input/input.cxx (around line 911). I have surrounded this statement by
debug timestamp information:
stamp(update_joystick_fire_prep );
a.bindings[modifiers][k]-fire(axis_values[j]);
stamp(update_joystick_fire_end);
and plotted the time it takes between the update_joystick_fire_prep
and update_joystick_fire_end stamps. The result is rather dramatic:
http://durktalsma.xs4all.nl/FlightGear/joystick-timing.png
X-axis displays the rank number of all FGInput calls with a timing Alert.
Y-axis shows the executiontime of the
a.bindings[modifiers][k]-fire(axis_values[j]);
line.
Thirdly, there is a relation between execution time and listeners, as proven
by the following experiment:
The heading indicator is one instrument showing frequent timing warnings. So I
also booby trapped the FGHeadingIndicator::update() function. Timing
information shows that it consistently takes about 4 usec to get from the
start of this function to the
_heading_out_node-setDoubleValue(heading);
line and than can take up to several ms or more to execute this statement.
That would be rather bizarre, because the update function also contains a
call to _offset_node-setDoubleValue(offset), which is executed within the
total of 4 useconds to execute the first function. That is, until I found
that the SenecaII has a listener attached to the property that
_heading_out_node refers to.
So I decided to do a little experiment: I copied the listener in
data/Aircraft/SenecaII/Nasal/hsi.nas, but set it to listen to offset-deg, the
property updated by _offset_node:
setlistener( /instrumentation/heading-indicator/offset-deg, func {
h = cmdarg().getValue();
v = h - aphb.getValue();
if( v 0.0 ) {
v = v + 360.0;
}
hsihb.setDoubleValue( v );
v = h - rad.getValue();
if( v 0.0 ) {
v = v + 360.0;
}
hsics.setDoubleValue( v );
});
Of course, the function as such doesn't make sense, but it would serve to
verify my hypothesis that if attaching a listener to a property slows its
execution, I would now expect to see that running the first half of the
function would take a lot longer. And this is indeed what happened:
Subsystem Timing Alert : 16032 instrument-8-heading-indicator
Getting to timestamp : HDG_06 takes 15936 usec.
Getting to timestamp : HDG_07 takes 91 usec.
Subsystem Timing Alert : 19071 instrumentation
Subsystem Timing Alert : 17724 instrument-8-heading-indicator
Getting to timestamp : HDG_06 takes 58 usec.
Getting to timestamp : HDG_07 takes 17655 usec.
When we remove the fake listener, _heading_out_node updating is consistently
fast again. One interesting observation from the above test, though, is that
the setDoubleValue() call is not consistently slow. So it's probably not the
listener itself, but probably an unexpected side effect we're dealing with.
I'm still hoping to find a common cause that can explain all of the stutters.
B.t.w., if you're interested, you can find the logfile of an about one hour
session here.
http://durktalsma.xs4all.nl/FlightGear/logfile
Cheers,
Durk
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 30 September 2007: Thirdly, there is a relation between execution time and listeners, Err ... Nasal listeners trigger Nasal code when the listened-to property is written to. Executed code costs cpu cycles. Anyone surprised? If listeners are used badly and trigger bad code, then this will, of course, hurt the framerate. But that's not because listeners are bad. The problem that I see in the Seneca is that several listeners are used on properties that are written to in every frame, which make no sense. That's a slow replacement for a simple Nasal loop. If you turn on listener logging, then you see a continuous flood of triggered listener code: $ fgfs --aircraft=SenecaII --log-level=debug 21|grep listener ... setting listener #50 in $FG_ROOT/Aircraft/SenecaII/Nasal/SenecaII.nas, line 269 setting listener #51 in $FG_ROOT/Nasal/aircraft.nas, line 216 setting listener #52 in $FG_ROOT/Nasal/aircraft.nas, line 216 setting listener #62 in $FG_ROOT/Aircraft/SenecaII/Nasal/SenecaII.nas, line 437 setting listener #63 in $FG_ROOT/Aircraft/SenecaII/Nasal/SenecaII.nas, line 438 setting listener #69 in $FG_ROOT/Aircraft/SenecaII/Nasal/hsi.nas, line 16 setting listener #79 in $FG_ROOT/Aircraft/SenecaII/Nasal/NLG.nas, line 66 setting listener #80 in $FG_ROOT/Aircraft/SenecaII/Nasal/NLG.nas, line 67 ... trigger listener #50 trigger listener #51 trigger listener #52 trigger listener #62 trigger listener #63 trigger listener #79 trigger listener #80 trigger listener #69 ... That's bad and the reason why I added listener logging. Listener should only be used on nodes that only change occasionally, as I've said numerous times. But I can't *force* people to use them correctly. :-} If you run the bo105 with turned on logging, you won't see a flood of triggered listeners (unless you move the mouse, #21 and #22). You'll only see them if some special event happens. Try that. It can't cause any stuttering. m. BTW: the two listener #51 and #52 are attached to light switches, and those aren't usually written to in every frame. In the Seneca they are, though ... :-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Melchior FRANZ -- Sunday 30 September 2007: If listeners are used badly and trigger bad code, then this will, of course, hurt the framerate. But that's not because listeners are bad. I have to add, though, that the listener code in hsi.nas doesn't look particularly slow, so it shouldn't cause any problems. I checked if the properties that it writes to have listeners attached themselves, but that's not the case. There must be some other cause. /me scratching head m. :-/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi Durk,
Firstly, yesterday I managed to speed-up the replay system, by using
dynamic allocation instead of pushing copies of rather large objects into
the STL lists. Using the timestamping code I mentioned yesterday, and
committed to CVS earler today, I found that memory allocation was very slow
on my machine. By preallocating a significant number of replay objects, and
recycling used ones instead of reallocating them I managed to get minimize
the amount of replay timing errors considerably.
Concerning the replay subsystem, I also found what appears to be a c'n'p error
in FGReplay::init(), which results in the long term queue not being cleared.
Probably not significant in this case, though...
Index: replay.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Aircraft/replay.cxx,v
retrieving revision 1.5
diff -u -r1.5 replay.cxx
--- replay.cxx 21 Mar 2006 18:52:19 - 1.5
+++ replay.cxx 30 Sep 2007 16:30:50 -
@@ -76,8 +76,8 @@
while ( !medium_term.empty() ) {
medium_term.pop_front();
}
-while ( !medium_term.empty() ) {
-medium_term.pop_front();
+while ( !long_term.empty() ) {
+long_term.pop_front();
}
}
bye,
Manuel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 30 September 2007 17:14, Melchior FRANZ wrote: * Durk Talsma -- Sunday 30 September 2007: Thirdly, there is a relation between execution time and listeners, Err ... Nasal listeners trigger Nasal code when the listened-to property is written to. Executed code costs cpu cycles. Anyone surprised? Although most people will have a global idea as to what listeners are, I don't think that *that* many people are aware of the fact that the actual setValue function is the very same code that calls these Nasal functions. If you are not aware of this, it can be very puzzling why a seemingly simple function can take so long to execute. That was actually the triggering question for my little experiment, and this statement. On Sunday 30 September 2007 17:33, Melchior FRANZ wrote: * Melchior FRANZ -- Sunday 30 September 2007: If listeners are used badly and trigger bad code, then this will, of course, hurt the framerate. But that's not because listeners are bad. I have to add, though, that the listener code in hsi.nas doesn't look particularly slow, so it shouldn't cause any problems. I checked if the properties that it writes to have listeners attached themselves, but that's not the case. There must be some other cause. /me scratching head I'm still hoping that there is a common root cause for all this. I'm currenty investigating on the basis of a working theory that memory management is somehow involved. Yesterday, I noted that a simple new FGReplay statement was also showing intermittently long execution times, which seemed to grow over time. I didn't make plots, like I did for the joystick fire code, but will try to do that in a minute. If we see similar increases in execution time in a function like that, we know for sure it can't just be a single badly written piece of code. I actually wish it was that simple, so I could stop watching my hair turn grey. :-) Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 30 September 2007 18:43, Manuel Massing wrote: Concerning the replay subsystem, I also found what appears to be a c'n'p error in FGReplay::init(), which results in the long term queue not being cleared. Probably not significant in this case, though... Hi Manuel, Yes, I saw that too. It's actually fixed in CVS. Currently PLIB branch only, but I will port everything over to the OSG branch later. Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 30 September 2007: Although most people will have a global idea as to what listeners are, I don't think that *that* many people are aware of the fact that the actual setValue function is the very same code that calls these Nasal functions. Ah, ok. Indeed, things can quickly get mysterious if you don't know that. :-) I'm still hoping that there is a common root cause for all this. Sigh. Yes, that would be nice. While I could cause the stutter problem reliably by activating AI traffic in the past, this is no longer the case. The only way to reproduce it now is to run MP, and I'm not sure if that's the same problem. Gahh ... I'm currenty investigating on the basis of a working theory that [...] I was so busy to defend my listeners, that I forgot to say: thanks for investigating all that. It's a lot of work and quite hard to do. All my attempts to find the cause failed so far. Unfortunately, we have lots of places where CPU cycles are wasted needlessly. One area is handling of STL containers. Other projects are much more careful with them and have strict policies. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] geodinfo with OSG Ocean tile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Moore wrote: gh.robin wrote: hello, With OSGwhen flying over Ocean tile (not Ocean Coast line) GeodInfo returns nil instead of Ocean Can you try this patch? Thanks, Tim I've committed this. Tim - diff --git a/simgear/scene/tgdb/SGOceanTile.cxx b/simgear/scene/tgdb/SGOceanTile.cxx index af1dddf..59083b9 100644 - --- a/simgear/scene/tgdb/SGOceanTile.cxx +++ b/simgear/scene/tgdb/SGOceanTile.cxx @@ -298,11 +298,11 @@ osg::Node* SGOceanTile(const SGBucket b, SGMaterialLib *matlib) + 2 * (latPoints - 1))); fillDrawElementsWithApron(latPoints, lonPoints, drawElements-begin()); geometry-addPrimitiveSet(drawElements); +geometry-setStateSet(stateSet); osg::Geode* geode = new osg::Geode; geode-setName(Ocean tile); geode-addDrawable(geometry); - -geode-setStateSet(stateSet); osg::MatrixTransform* transform = new osg::MatrixTransform; transform-setName(Ocean); - - - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ - ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG//6aeDhWHdXrDRURAhlPAJ4z+MGQQ7jjnDeOmqCJVnvkEbXIHACcDWmo upKtOiTuanClnR/AcTHDFGg= =HOaC -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSG: Blended Reflect-Effect on aircraft-skins
Hi, I found a way to have a quite realistic looking reflect-effect on aircraft skins. The trick is to use multitexture. It is in principale the same technique like seen in MSFS without any hits on fps. Unfortunately I did not found yet a comfortable way to controll it- so I modified the chrome-texture. But I'm sure there is a way somewhere in OSG- maybe someone can help. I did a small .tar.gz with a example file and a small note. Copy the files to the A380 and you will see the effect. http://www.hoerbird.net/fgfs-screen-457.jpg http://www.hoerbird.net/fgfs-screen-456.jpg http://www.hoerbird.net/fgfs-screen-458.jpg http://www.hoerbird.net/osg-reflect-effect-example.tar.gz It is only a simple hack- so it can be improved easliy. Greetings HHS Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG: Blended Reflect-Effect on aircraft-skins
On dim 30 septembre 2007, Heiko Schulz wrote: Hi, I found a way to have a quite realistic looking reflect-effect on aircraft skins. The trick is to use multitexture. It is in principale the same technique like seen in MSFS without any hits on fps. Unfortunately I did not found yet a comfortable way to controll it- so I modified the chrome-texture. But I'm sure there is a way somewhere in OSG- maybe someone can help. I did a small .tar.gz with a example file and a small note. Copy the files to the A380 and you will see the effect. http://www.hoerbird.net/fgfs-screen-457.jpg http://www.hoerbird.net/fgfs-screen-456.jpg http://www.hoerbird.net/fgfs-screen-458.jpg http://www.hoerbird.net/osg-reflect-effect-example.tar.gz It is only a simple hack- so it can be improved easliy. Greetings HHS Hello, Heiko Thanks That is a nice demonstration, and with it, you open the door to a lot of questions about osg model format. I dare one :) =How to have Internal animations within the model triggered by SG/FG (aileron, elevators, ..) ? Cheers -- Gérard http://perso.orange.fr/GRTux/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
