Re: [Flightgear-devel] configure/make/run on MacOS X
Hans Fugal wrote: It may not be the same problem, but I remember getting almost no helpful indications from either of those debug methods so OTOH it may indeed be the same problem. Make sure you don't have conflicting plugins in /Library or wherever the OSG release readme says to put them, try moving them from /usr/local to /usr, try setting some environment variable that I wish I had written down, etc. After checking the system again I'm confident that the *only* OSG is in /usr/local/lib. And again, all the osgexamples as well as my other OSG projects are fine. One way to be sure is to see if you can tell if this is the first texture that it's trying to load. My guess is yes, but if it's not I put a breakpoint on applyTexImage2D_load and it picked up the following textures being loaded: - Splash1... - wxecho.rgb - cirrus.rgba *BANG* So it's not the first but awfully close. The first one obviously is the splash screen which I can see. No idea about the second one. The third one gives the segfault. Is there anything exciting happening before the environment is initialized? then it's not the same problem. Also, if you built OSG from scratch maybe you didn't get all the plugins needed by flightgear? Don't think so, I can open the texture using 'osgviewer --image cirrus.rgba' Lost a sea, /ulrich - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] native protocol flight control transfer
Greetings. We're still experimenting with flight slaving (two fgfs instances, the master sends flight data to the slave using the native protocol). Other than the stability concerns already discussed in other threads, the most significant problem seems to be that some important data isn't sent through the link. For instance, flight controls aren't sent at all (this would be crucial); neither is the flight time (which affects at least day/night status, and we guess the dynamic scenery, too). Is there an accepted, already existing solution to this? Or should we be using a custom-designed protocol using the generic i/o system? Or are we simply doing it wrong. :) Regards, Mate Nagy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bizarre dynamic scenery
We noticed a rather peculiar effect, having landed our plane near (under) a grey parking passenger jet. Fiddling with our flight controls made the control surfaces of the jet move in the same way. The jet was otherwise inert, and the effect didn't happen with other nearby planes on the ground. (This was noticed on the master half of a native protocol slaved pair.) Has anyone else seen something like this before? :) - Mate Nagy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bizarre dynamic scenery
On Mon, 2008-01-21 at 14:32 +0100, Nagy Mate wrote: We noticed a rather peculiar effect, having landed our plane near (under) a grey parking passenger jet. Fiddling with our flight controls made the control surfaces of the jet move in the same way. The jet was otherwise inert, and the effect didn't happen with other nearby planes on the ground. (This was noticed on the master half of a native protocol slaved pair.) Has anyone else seen something like this before? :) - Mate Nagy Yes, it sounds like the jet model config has absolute paths instead of relative paths for the control animations. If you tell us which jet it was someone will fix it. Thanks, Ron - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bizarre dynamic scenery
On Jan 21, 2008 2:32 PM, Nagy Mate [EMAIL PROTECTED] wrote: We noticed a rather peculiar effect, having landed our plane near (under) a grey parking passenger jet. Fiddling with our flight controls made the control surfaces of the jet move in the same way. The jet was otherwise inert, and the effect didn't happen with other nearby planes on the ground. Has anyone else seen something like this before? :) Looks like the usual leading-slash bug. Figure out what type of aircraft and then look in the xmls to see if the animations use a leading slash. If so, they will always reference the user's aircraft, rather than the proper AI model. For example, property/surface-positions/left-aileron-pos-norm/property Should be: propertysurface-positions/left-aileron-pos-norm/property (ie. no leading slash) Actually I found this in the AI A320 xml, so maybe that was the aircraft you have seen? -- HCS - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bizarre dynamic scenery
On Mon, 21 Jan 2008, Nagy Mate wrote: We noticed a rather peculiar effect, having landed our plane near (under) a grey parking passenger jet. Fiddling with our flight controls made the control surfaces of the jet move in the same way. The jet was otherwise inert, and the effect didn't happen with other nearby planes on the ground. (This was noticed on the master half of a native protocol slaved pair.) Has anyone else seen something like this before? :) Hi, One possible explanation would be that the animations in the jet model contain absolute property paths (i.e. paths starting at the root /). That would cause them to be animated based on the user's /controls/* properties. Making those paths relative by removing the leading / should solve the problem. Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
On Fri, 18 Jan 2008, Torsten Dreyer wrote:
Hi all,
I think there is a bug when using the native protocol to link two instances of
FlightGear via network or when recording and playing back flights using
fgfs --native=file,out,20,fgfs.out
and
fgfs --native,file,in,20,fgfs.out --fdm=external
The external FlightGear crashes and after some investigation I think the
problem is a missing operator =() method in FDM/flight.hxx
The problem is:
In Network/native.cxx a buffer is read either from network of from a file
containing the previously written fdm state. The content of the buffer is
than assigned to the current fdm state by doing
*cur_fdm_state = buf;
both variables are of type FGInterface which currently lacks a operator =()
method, so the compiler uses a simple memcpy to copy one object to the other.
This is almost ok but for the ground_cache object. This is a complex object
containing a std::vectorFGGroundCache::Triangle. This vector seems to store
memory pointers to the Triangle-vertices. This is a very bad thing because
these pointers are invalid for any other FlightGear session and dereferencing
them causes a segmentation fault.
A very ugly - if not disgusting - workaround is adding the following to the
public methods of FGInterface in FDM/flight.hxx:
virtual const FGInterface operator = ( FGInterface src ) {
char * start = (char*)inited;
char * end = (char*)ground_cache;
memcpy( inited, src.inited, end-start );
prepare_ground_cache_m( 0, geodetic_position_v, 100.0 );
}
This gets called instead of a memcpy when assinging one FGInterface to another
and it does the memcpy for all member variables but the ground_cache. The
ground_cache itself is initialized for the recovered position with a fix
reference time of 0 and a radius of 100m.
At least this change fixes the segfault when replaying with the native
protocol, but I don't think this is the kind of code we want to see in
FlightGear for two reasons:
a) The pointer arithmetic assuming simple datatypes between the inited and
ground_cache variable
b) A constant used for reference time and the radius.
While a) may be circumnavigated by using explicit assignments for all
variables, I have no good idea for b). The radius might be saved when doing
the output, but I do not understand the idea of the reference time...
And there is one thing that is going round in my head: Curt reported, that he
does not have this problem at all and no one else (except tpalinkas) reported
this crash. Maybe this a a compiler/library problem?
Thanks for reading all that - any comment or help is appreciated.
Torsten
We applied your patch and it fixed the initial segfault in slave.
(However, we experience double-free/corruption when the slave quits.)
Another strange bug is that if we start up in the wrong order (master
first, without the patch, this order caused an immediate segfault), the
initial states of the slave are messed up (altitude is - ft; plane
permanently stuck in the ground). Doing a reset on the slave
fixes the problem even if we've taken off with the master.
TIA
Tibor Palinkas
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] PLIB data branch created
With Curt's OK I have now created a PLIB branch for the data directory. For developers this means: - work on HEAD can go on as usual -- there's no need to care about the PLIB branch at all - HEAD does no longer have to be compatible with fg/plib and fgfs v1.0 - only changes that should be contained in a possible plib based fgfs v1.1 release have to be committed to the PLIB branch Merging changes to the PLIB branch that you have already made to the HEAD branch is easy: $ cvs up -rPLIB -jHEAD foo.xml # switch file to PLIB branch # and merge the HEAD changes $ cvs ci foo.xml# commit to the PLIB branch $ cvs up -A foo.xml # switch back to HEAD m. PS: there's also an old PRE_OSG_PLIB_20061029 branch, which is unmaintained and to be ignored. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Fwd: Re: [osg-submissions] AC3D loader resets optional path list
FYI, I proposed a patch to the AC3D loader to preserve Optional database path and it was accepted. It should be included in the next 2.3.3 developer release. -Fred - Forwarded message from Robert Osfield [EMAIL PROTECTED] - Date: Mon, 21 Jan 2008 11:24:22 + From: Robert Osfield [EMAIL PROTECTED] Reply-To: OpenSceneGraph Submissions [EMAIL PROTECTED] Subject: Re: [osg-submissions] AC3D loader resets optional path list To: OpenSceneGraph Submissions [EMAIL PROTECTED] Thanks Frederic, the change looks reasonable, and is now merged and checked into SVN. On Jan 20, 2008 1:39 PM, Frederic Bouvier wrote: Hi, I noticed the AC3D loader resets database path given as Options, preventing users to put textures in another directory. This patch adds the model path to the path list instead of replacing it. file changed : src\osgPlugins\ac\ac3d.cpp - End forwarded message - -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] PLIB data branch created
Now that HEAD is for fg/osg only, some aircraft and other stuff will soon start to work badly or not at all with v1.0 and fg/plib. No problem for exclusive fg/osg users, but some people still like volumetric shadows and 3D clouds and will therefore also use fg/plib for a while. (Helicopters in outside view without shadows are very hard to handle.) There are different ways to deal with this problem: (a) If it's only a few aircraft that you run in fg/plib only, just switch those aircraft (or other files) to the PLIB branch: $ cd $FG_ROOT/Aircraft/bo105 $ cvs up -rPLIB This works for single files as well. $ cvs up -rPLIB foo.xml you can at any time switch back to HEAD: $ cvs up -A (b) Keep full data for both branches (if you have a lot of free disk space): $ cp -a Data.OSG Data.PLIB $ cvs up -rPLIB Data.PLIB (c) Create a shadow PLIB data dir, where all files dirs are only links to their HEAD counterparts, except for those where you want a plib version. Do something like this (untested): $ mkdir Data.PLIB $ cd Data.PLIB $ ln -s ../Data.OSG/* . $ rm Aircraft# remove dir link $ mkdir Aircraft # and make it a real dir $ cd Aircraft $ ln -s ../../Data.OSG/Aircraft/* . $ rm bo105 $ cp -a ../../Data.OSG/Aircraft/bo105 . $ cvs up -rPLIB bo105 Now you can run $ fgfs.osg --fg-root=foo/Data.OSG and $ fgfs.plib --fg-root=foo/Data.PLIB while saving lots of disk space. I use (c). :-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
I am testing the udp version of doing master/slave copies of FlightGear here
this morning. I'm doing this with a stock v1.0 version. So far everything
seems to be behaving well. I'm not seeing any rapid memory leak, and so far
no crash.
Are you seeing this only with file I/O? Are you seeing this with network
I/O? How long do you need to have the system running before you see memory
thrashing or a crash?
Thanks,
Curt.
On Jan 21, 2008 7:03 AM, tpalinkas wrote:
On Fri, 18 Jan 2008, Torsten Dreyer wrote:
Hi all,
I think there is a bug when using the native protocol to link two
instances of
FlightGear via network or when recording and playing back flights using
fgfs --native=file,out,20,fgfs.out
and
fgfs --native,file,in,20,fgfs.out --fdm=external
The external FlightGear crashes and after some investigation I think
the
problem is a missing operator =() method in FDM/flight.hxx
The problem is:
In Network/native.cxx a buffer is read either from network of from a
file
containing the previously written fdm state. The content of the buffer
is
than assigned to the current fdm state by doing
*cur_fdm_state = buf;
both variables are of type FGInterface which currently lacks a operator
=()
method, so the compiler uses a simple memcpy to copy one object to the
other.
This is almost ok but for the ground_cache object. This is a complex
object
containing a std::vectorFGGroundCache::Triangle. This vector seems to
store
memory pointers to the Triangle-vertices. This is a very bad thing
because
these pointers are invalid for any other FlightGear session and
dereferencing
them causes a segmentation fault.
A very ugly - if not disgusting - workaround is adding the following to
the
public methods of FGInterface in FDM/flight.hxx:
virtual const FGInterface operator = ( FGInterface src ) {
char * start = (char*)inited;
char * end = (char*)ground_cache;
memcpy( inited, src.inited, end-start );
prepare_ground_cache_m( 0, geodetic_position_v, 100.0 );
}
This gets called instead of a memcpy when assinging one FGInterface to
another
and it does the memcpy for all member variables but the ground_cache.
The
ground_cache itself is initialized for the recovered position with a fix
reference time of 0 and a radius of 100m.
At least this change fixes the segfault when replaying with the native
protocol, but I don't think this is the kind of code we want to see in
FlightGear for two reasons:
a) The pointer arithmetic assuming simple datatypes between the inited
and
ground_cache variable
b) A constant used for reference time and the radius.
While a) may be circumnavigated by using explicit assignments for all
variables, I have no good idea for b). The radius might be saved when
doing
the output, but I do not understand the idea of the reference time...
And there is one thing that is going round in my head: Curt reported,
that he
does not have this problem at all and no one else (except tpalinkas)
reported
this crash. Maybe this a a compiler/library problem?
Thanks for reading all that - any comment or help is appreciated.
Torsten
We applied your patch and it fixed the initial segfault in slave.
(However, we experience double-free/corruption when the slave quits.)
Another strange bug is that if we start up in the wrong order (master
first, without the patch, this order caused an immediate segfault), the
initial states of the slave are messed up (altitude is - ft; plane
permanently stuck in the ground). Doing a reset on the slave
fixes the problem even if we've taken off with the master.
TIA
Tibor Palinkas
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] native protocol flight control transfer
On Jan 21, 2008 7:32 AM, Nagy Mate wrote: Greetings. We're still experimenting with flight slaving (two fgfs instances, the master sends flight data to the slave using the native protocol). Other than the stability concerns already discussed in other threads, I am not able to reproduce these stability problems on my own system. Can someone summarize how to reproduce these problems and which version of FlightGear they are using? Using udp socket communication and Fedora Core 8 here, things seem to be running really well for me. the most significant problem seems to be that some important data isn't sent through the link. For instance, flight controls aren't sent at all (this would be crucial); neither is the flight time (which affects at least day/night status, and we guess the dynamic scenery, too). There is an --native-ctrls= command line option to send a set of flight control related properties. It works just like the --native-fdm option, just remember to use a different port number. For past projects, I've used the --props= option to accept property configuration changes (things like weather effects and time of day.) You can use this interface to read/write individual properties. I setup a separate gui that was configured to know the ip addresses of all the slaves so it could update them appropriately when I wanted to make a change. For the time of day, this presupposes that all the computer clocks are pretty closely in sync ... then you can send the same time offset to them (in seconds) so they all can display the same time of day effects. Is there an accepted, already existing solution to this? Or should we be using a custom-designed protocol using the generic i/o system? Or are we simply doing it wrong. :) I'm still interested in getting to the bottom of any master/slave problems since this is a critical feature for some of my future day job work. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Lags only in multiplayer mode
Hello, Me and my friends having several lags when using FG in multiplayer mode, because low internet speed(dial-up connection) or fully network usage(occurs for me even network usage is 90% or above) . I believe this is in the procedure for send/receive position and aircraft data. My machine: CPU Intel P4 3.0Ghz 2Gb RAM Nvidia GeForce 6600 DVI 256Mb DSL Cable connection 1000kbps down/512kbps up Regards, Cleber Santz - Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Lags only in multiplayer mode
Hi Cleber, Every pc will experience some lag when the MP-server is bussy. When there is a great number of pilots online the lag will be larger. There are periods that I've got about every 5 minutes a few seconds lag. The servers isn't calculated at this amount of pilots I think. Gijs Date: Mon, 21 Jan 2008 15:22:46 -0300From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [Flightgear-devel] Lags only in multiplayer modeHello, Me and my friends having several lags when using FG in multiplayer mode, because low internet speed(dial-up connection) or fully network usage(occurs for me even network usage is 90% or above) . I believe this is in the procedure for send/receive position and aircraft data.My machine:CPU Intel P4 3.0Ghz 2Gb RAMNvidia GeForce 6600 DVI 256MbDSL Cable connection 1000kbps down/512kbps upRegards,Cleber Santz Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! _ Probeer Live Search: de zoekmachine van de makers van MSN! http://www.live.com/?searchOnly=true- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] (no subject)
With the following model: world '' (2) group 'testgroup1' (2) poly 'test1' group 'testgroup2' (1) poly 'test2' I can use a material animation on testgroup1 and both test1 and test2 respond, which is what I would expect. I can't seem to get a material animation to work for testgroup2 though, as long as there is a material animation for it's parent group. It does not matter what order the animations are given in the model.xml file, it always fails. Removing the animation for testgroup1 allows the animation for testgroup2 to work. Also, using name tags for the animations doesn't change the behavior. This was not the case before the OSG changeover, and breaks a few important animations in the ch53e cockpit. I can work around this, but it will be inelegant and require a lot of extra animations as I will have to flatten out the structure of the cockpit. Any ideas? Josh PS, here are the animations: animation typematerial/type object-nametestgroup2/object-name property-basesim/model/ch53e/test-mat-2/property-base diffuse red-propdiffuse/red/red-prop green-propdiffuse/green/green-prop blue-propdiffuse/blue/blue-prop /diffuse ambient red-propambient/red/red-prop green-propambient/green/green-prop blue-propambient/blue/blue-prop /ambient specular red-propspecular/red/red-prop green-propspecular/green/green-prop blue-propspecular/blue/blue-prop /specular emission red-propemission/red/red-prop green-propemission/green/green-prop blue-propemission/blue/blue-prop /emission shininess/ /animation animation typematerial/type object-nametestgroup1/object-name property-basesim/model/ch53e/test-mat-1/property-base diffuse red-propdiffuse/red/red-prop green-propdiffuse/green/green-prop blue-propdiffuse/blue/blue-prop /diffuse ambient red-propambient/red/red-prop green-propambient/green/green-prop blue-propambient/blue/blue-prop /ambient specular red-propspecular/red/red-prop green-propspecular/green/green-prop blue-propspecular/blue/blue-prop /specular emission red-propemission/red/red-prop green-propemission/green/green-prop blue-propemission/blue/blue-prop /emission shininess/ /animation - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Lags only in multiplayer mode
Hi Gijs,
This cannot be solved using asynchronous procedures ? Or there any plan to
make this asynchronous ? With this, the lag occurs only in the server and the
user will not affected by this.
Tks,
Cleber.
Gijs de Rooy [EMAIL PROTECTED] escreveu:.hmmessage P { margin:0px;
padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Hi Cleber,
Every pc will experience some lag when the MP-server is bussy.
When there is a great number of pilots online the lag will be
larger.
There are periods that I've got about every 5 minutes a few
seconds lag. The servers isn't calculated at this amount of
pilots I think.
Gijs
-
Date: Mon, 21 Jan 2008 15:22:46 -0300
From: [EMAIL PROTECTED]
To: flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] Lags only in multiplayer mode
Hello,
Me and my friends having several lags when using FG in multiplayer mode,
because low internet speed(dial-up connection) or fully network usage(occurs
for me even network usage is 90% or above) .
I believe this is in the procedure for send/receive position and aircraft
data.
My machine:
CPU Intel P4 3.0Ghz 2Gb RAM
Nvidia GeForce 6600 DVI 256Mb
DSL Cable connection 1000kbps down/512kbps up
Regards,
Cleber Santz
-
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para
armazenamento!
-
In 2 tellen je eigen webpagina voor al je foto's! Makkelijk en gratis met
Windows Live
Spaces-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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
-
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! -
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Lags only in multiplayer mode
On Jan 21, 2008 12:27 PM, Gijs de Rooy wrote: Hi Cleber, Every pc will experience some lag when the MP-server is bussy. When there is a great number of pilots online the lag will be larger. There are periods that I've got about every 5 minutes a few seconds lag. The servers isn't calculated at this amount of pilots I think. If you are talking about position lags and not frame rate lags, then I believe the MP server builds in about a 10 second buffer delay to try to prevent buffer starvation and show continuous motion on the client side. Frame rate delays are typically caused by someone entering the MP system requiring all the participant systems to load the corresponding 3d model. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
Am Montag, 21. Januar 2008 18:21 schrieb Curtis Olson:
I am testing the udp version of doing master/slave copies of FlightGear
here this morning. I'm doing this with a stock v1.0 version. So far
everything seems to be behaving well. I'm not seeing any rapid memory
leak, and so far no crash.
Are you seeing this only with file I/O? Are you seeing this with network
I/O? How long do you need to have the system running before you see memory
thrashing or a crash?
I get the segfault with file-io and a udp link.
This is my environment:
- SuSE Linux 10.3 running x86_64 on a Intel(R) Core(TM)2 CPU.
- Two instances of FlightGear frame-rate-throttled to 25 fps each
- FlightGear stock 1.0.0 build from source and current plib cvs built with gcc
4.2.1
commandline for slave (launched first):
fgfs --native=socket,in,20,localhost,5556,udp --aircraft=c172p
--geometry=640x480 --timeofday=noon --fdm=null
commandline for master (launched after slave startup)
fgfs --native=socket,out,20,localhost,5556,udp --aircraft=c172p
--geometry=640x480 --timeofday=noon
segfaults the slave anything between immediately and after a couple of
minutes. Sometimes, terminating the master and starting at other locations in
the world immediately kills the slave, like --airport=KJFK or --airport=LOWI
Doing some more tests with the operator = () method added, I never got a
crash.
BTW the operator =() could be reduced to
virtual const FGInterface operator = ( FGInterface src ) {
char * start = (char*)inited;
char * end = (char*)ground_cache;
memcpy( inited, src.inited, end-start );
}
since the prepare_ground_cache will be called later automatically by the
FGInterface::get_groundlevel.
And while we are at the native protocols: I am sorry to say that the
native-ctrls is broken, too. The encoding swaps bytes for little endian
machines when encoding to the net, but does not when decoding from the net.
This part is commented out in version 1.32:
http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/source/src/Network/native_ctrls.cxx?r1=1.31r2=1.32
(check line 296 and 353)
Is this by intention?
Torsten
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Lags only in multiplayer mode
Curtis, The problem is about Frame delay, but in stand-alone mode i have not lags even when aircraft is near to land. Because this i suppose the problem with frame delay is on the server, maybe by user number (27 at critical time). If the problem occur by the new users, why this not occurs for load scenery in stand-alone ? because aircraft 3D model is more heavy then scenery ??. Regards, Cleber Santz. Curtis Olson [EMAIL PROTECTED] escreveu: On Jan 21, 2008 12:27 PM, Gijs de Rooy wrote: Hi Cleber, Every pc will experience some lag when the MP-server is bussy. When there is a great number of pilots online the lag will be larger. There are periods that I've got about every 5 minutes a few seconds lag. The servers isn't calculated at this amount of pilots I think. If you are talking about position lags and not frame rate lags, then I believe the MP server builds in about a 10 second buffer delay to try to prevent buffer starvation and show continuous motion on the client side. Frame rate delays are typically caused by someone entering the MP system requiring all the participant systems to load the corresponding 3d model. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 - Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bizarre dynamic scenery
Ron Jensen a écrit : On Mon, 2008-01-21 at 14:32 +0100, Nagy Mate wrote: We noticed a rather peculiar effect, having landed our plane near (under) a grey parking passenger jet. Fiddling with our flight controls made the control surfaces of the jet move in the same way. The jet was otherwise inert, and the effect didn't happen with other nearby planes on the ground. (This was noticed on the master half of a native protocol slaved pair.) Has anyone else seen something like this before? :) - Mate Nagy Yes, it sounds like the jet model config has absolute paths instead of relative paths for the control animations. If you tell us which jet it was someone will fix it. Thanks, Ron the bo105 has this problem, specialy the doors witch are invisible when it's an mp aircraft. (and the livery change is global) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
On Jan 21, 2008 12:51 PM, Torsten Dreyer wrote: Am Montag, 21. Januar 2008 18:21 schrieb Curtis Olson: I am testing the udp version of doing master/slave copies of FlightGear here this morning. I'm doing this with a stock v1.0 version. So far everything seems to be behaving well. I'm not seeing any rapid memory leak, and so far no crash. Are you seeing this only with file I/O? Are you seeing this with network I/O? How long do you need to have the system running before you see memory thrashing or a crash? I get the segfault with file-io and a udp link. This is my environment: - SuSE Linux 10.3 running x86_64 on a Intel(R) Core(TM)2 CPU. - Two instances of FlightGear frame-rate-throttled to 25 fps each - FlightGear stock 1.0.0 build from source and current plib cvs built with gcc 4.2.1 Here's one possible difference, I'm running with plib-1.8.4 ... any chance you could try that and see if it makes a difference. I realize a complete ground up recompile is not trivial, but flightgear does leverage plib's low level network code, so is it possible that a change in plib since v1.8.4 is causing us grief? The native_ctrls issue you point out is a surprise to me, but as I look in the cvs web browser pages, I see that Erik Hofman's name is attached to these, and the specific commit was adding some new fields to the structure. I think it makes sense to remove the comments that disable network byte order. That appears to have been a mistake that slipped through the cracks. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Lags only in multiplayer mode
On Mon, 21 Jan 2008, Curtis Olson wrote:
If you are talking about position lags and not frame rate lags, then I
believe the MP server builds in about a 10 second buffer delay to try to
prevent buffer starvation and show continuous motion on the client side.
Yes, we have such a buffer but it is implemented on the client side. The
servers only forward data packets as fast as they can. The communication
to and from the servers are done using UDP so that in itself should not
cause lag. If the amount of traffic exceeds the available capacity either
at the server's or the user's end dropped packets might lead to jerky
motion of MP aircraft.
Frame rate delays are typically caused by someone entering the MP system
requiring all the participant systems to load the corresponding 3d model.
Yes. Some aircraft are quite heavy - a 787 joining stalls my system for
some 10 - 15 seconds.
One thing I have noticed now when the number of pilots is larger than ever
is that during startup my FlightGear joins and leaves the MP network
repeatedly greatly prolonging the startup time (I suspect the MP models
get purged and reloaded each join/leave cycle). This is due to the MP
system starting to send data early and the extremely low frame rate
during initialization - the MP code probably looks for new packets once
per frame.
To make it bearable I delayed the MP joining some in multiplaymgr:
--- a/src/MultiPlayer/multiplaymgr.cxx
+++ b/src/MultiPlayer/multiplaymgr.cxx
@@ -310,6 +310,10 @@ FGMultiplayMgr::SendMyPosition(const FGExternalMotionData
motionInfo)
return;
}
+ if (fgGetDouble(/sim/time/elapsed-sec) 2.0) {
+return;
+ }
+
T_PositionMsg PosMsg;
This is pretty ugly but made a huge difference on my system.
Note, though, it only reduces startup time - it doesn't do much when
connected except that by not having join/leave/join cycles joining
players are less tough on the rest of the participants.
Cheers,
Andersdiff --git a/src/MultiPlayer/multiplaymgr.cxx b/src/MultiPlayer/multiplaymgr.cxx
index f59b403..5505d07 100644
--- a/src/MultiPlayer/multiplaymgr.cxx
+++ b/src/MultiPlayer/multiplaymgr.cxx
@@ -310,6 +310,10 @@ FGMultiplayMgr::SendMyPosition(const FGExternalMotionData
motionInfo)
return;
}
+ if (fgGetDouble(/sim/time/elapsed-sec) 2.0) {
+return;
+ }
+
T_PositionMsg PosMsg;
strncpy(PosMsg.Model, fgGetString(/sim/model/path), MAX_MODEL_NAME_LEN);
PosMsg.Model[MAX_MODEL_NAME_LEN - 1] = '\0';
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
On Jan 21, 2008 1:45 PM, Torsten Dreyer wrote: Here's one possible difference, I'm running with plib-1.8.4 ... any chance you could try that and see if it makes a difference. I realize a complete ground up recompile is not trivial, but flightgear does leverage plib's low level network code, so is it possible that a change in plib since v1.8.4is causing us grief? I am running 1.8.4, too: (checked plib/ul.h) #define PLIB_MAJOR_VERSION 1 #define PLIB_MINOR_VERSION 8 #define PLIB_TINY_VERSION 4 But I am still convinced, that the ground_cache object causes the crash. The gdb backtrace, the invalid pointers - everything makes sense to me. On the contrary this means, that the native protocol is broken since Nov 22nd 2004 when the ground_cache object made its way into flight.hxx... But native_ctrls tell me, that is sometimes takes years for bugs to show up or be detected ;-) I'm not able to replicate the problem here. :-( I don't use --native-ctrls very often but I use --native-fdm frequently for a variety of projects and it has always been working well for me and seems to continue to work well. I'm running gcc-4.1.2 here. g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33) So the problem could also be related to your newer version of gcc (perhaps being more picky or more standards compliant.) Or there could be a libc difference too. The problem could very well be in the ground cache code and something about that code is blowing up on your system? Often, newer versions of the gcc compiler or compilers on other platforms expose weaknesses or problems in code that worked fine before. It would be really great if Mathias could comment since he is the author of the ground cache code. I have not looked at that code myself in any detail. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33) So the problem could also be related to your newer version of gcc (perhaps being more picky or more standards compliant.) Or there could be a libc difference too. Yeah that's what I think, too. I assume a different implementation in the STL to be more precise: the std:vector. I don't think I like the idea to build a gcc 4.1.2 and rebuild FlightGear from source with that compiler but I would not be surprised, if the crash disappears that way. Which compilier is tpalinkas using? Torsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
The native_ctrls issue you point out is a surprise to me, but as I look in
the cvs web browser pages, I see that Erik Hofman's name is attached to
these, and the specific commit was adding some new fields to the structure.
I think it makes sense to remove the comments that disable network byte
order. That appears to have been a mistake that slipped through the
cracks.
I have just recompiled FlightGear with the comments that disable the byte
order code removed, and the native-ctrls protocol works like magic.
Can you change the source in CVS? I just removed the two comments:
Index: native_ctrls.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Network/native_ctrls.cxx,v
retrieving revision 1.33
diff -u -p -r1.33 native_ctrls.cxx
--- native_ctrls.cxx21 Feb 2006 01:19:47 - 1.33
+++ native_ctrls.cxx21 Jan 2008 20:53:27 -
@@ -293,7 +293,6 @@ void FGNetCtrls2Props( FGNetCtrls *net,
int i;
SGPropertyNode * node;
-/***
if ( net_byte_order ) {
// convert from network byte order
net-version = htonl(net-version);
@@ -350,7 +349,6 @@ void FGNetCtrls2Props( FGNetCtrls *net,
net-speedup = htonl(net-speedup);
net-freeze = htonl(net-freeze);
}
-*/
if ( net-version != FG_NET_CTRLS_VERSION ) {
SG_LOG( SG_IO, SG_ALERT,
Version mismatch with raw controls packet format. );
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
Yes, this should already be done in both plib and osg branches. Regards,
Curt.
On Jan 21, 2008 2:55 PM, Torsten Dreyer wrote:
The native_ctrls issue you point out is a surprise to me, but as I look
in
the cvs web browser pages, I see that Erik Hofman's name is attached to
these, and the specific commit was adding some new fields to the
structure.
I think it makes sense to remove the comments that disable network byte
order. That appears to have been a mistake that slipped through the
cracks.
I have just recompiled FlightGear with the comments that disable the byte
order code removed, and the native-ctrls protocol works like magic.
Can you change the source in CVS? I just removed the two comments:
Index: native_ctrls.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Network/native_ctrls.cxx,v
retrieving revision 1.33
diff -u -p -r1.33 native_ctrls.cxx
--- native_ctrls.cxx21 Feb 2006 01:19:47 - 1.33
+++ native_ctrls.cxx21 Jan 2008 20:53:27 -
@@ -293,7 +293,6 @@ void FGNetCtrls2Props( FGNetCtrls *net,
int i;
SGPropertyNode * node;
-/***
if ( net_byte_order ) {
// convert from network byte order
net-version = htonl(net-version);
@@ -350,7 +349,6 @@ void FGNetCtrls2Props( FGNetCtrls *net,
net-speedup = htonl(net-speedup);
net-freeze = htonl(net-freeze);
}
-*/
if ( net-version != FG_NET_CTRLS_VERSION ) {
SG_LOG( SG_IO, SG_ALERT,
Version mismatch with raw controls packet format. );
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
On Jan 21, 2008 2:38 PM, Torsten Dreyer wrote: g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33) So the problem could also be related to your newer version of gcc (perhaps being more picky or more standards compliant.) Or there could be a libc difference too. Yeah that's what I think, too. I assume a different implementation in the STL to be more precise: the std:vector. I don't think I like the idea to build a gcc 4.1.2 and rebuild FlightGear from source with that compiler but I would not be surprised, if the crash disappears that way. Which compilier is tpalinkas using? The other thing that concerns me is that even with your patch, tpalikas is reporting order depencies in the master/slave startup sequence and doing it wrong results in a crash. Also some new double free errors when exiting. The communication between master slaves is UDP so there should be absolutely no order dependencies in startup. Any machine should be able to start (or restart) in any order without affecting the stability of the system. Somehow the master must be sending garbage during startup and crashing the slaves. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
Am Montag, 21. Januar 2008 22:00 schrieb Curtis Olson: The other thing that concerns me is that even with your patch, tpalikas is reporting order depencies in the master/slave startup sequence and doing it wrong results in a crash. Also some new double free errors when exiting. The communication between master slaves is UDP so there should be absolutely no order dependencies in startup. Any machine should be able to start (or restart) in any order without affecting the stability of the system. Somehow the master must be sending garbage during startup and crashing the slaves. Neither of this is occouring here. When I run the master without a slave, there are many Error writing data. messages on the master's console which stops again when the slave is up. But I can startup/shutdown the master or slave independently without crash or double free error messages. Sorry - no idea for that one. Torsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
Torsten Dreyer schreef: Neither of this is occouring here. When I run the master without a slave, there are many Error writing data. messages on the master's console which stops again when the slave is up. But I can startup/shutdown the master or slave independently without crash or double free error messages. Sorry - no idea for that one. Torsten That sounds like you're using TCP, since if you were using UDP, the master would not know if the slave(s) received the message -- UDP is an unreliable protocol and the master does not know if it is transmittiing into oblivion or reaching an actual slave instance of FlightGear. Provided the native protocol doesn't have a mechanism to provide feedback of received messages to the master, that is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bug in native protocol was: simgear 1.0.0 crash -- and yet another bug
That sounds like you're using TCP, since if you were using UDP, the master would not know if the slave(s) received the message -- UDP is an unreliable protocol and the master does not know if it is transmittiing into oblivion or reaching an actual slave instance of FlightGear. Provided the native protocol doesn't have a mechanism to provide feedback of received messages to the master, that is. It's udp I swear by the life of my dog (mine is to precious): The commandline pasted fresh from the clipboard: fgfs --native=socket,out,20,localhost,5556,udp --aircraft=c172p --geometry=640x480 --timeofday=noon --native-ctrls=socket,out,20,localhost,5557,udp And the output of netstat -un after the above command (sorry - german output. s/VERBUNDEN/CONNECTED/g): Proto Recv-Q Send-Q Local Address Foreign Address State udp0 0 127.0.0.1:32817 127.0.0.1:5556 VERBUNDEN udp0 0 127.0.0.1:32818 127.0.0.1:5557 VERBUNDEN Torsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Bizarre dynamic scenery
On Jan 22, 2008 12:53 AM, Csaba Halász [EMAIL PROTECTED] wrote: On Jan 21, 2008 2:32 PM, Nagy Mate [EMAIL PROTECTED] wrote: We noticed a rather peculiar effect, having landed our plane near (under) a grey parking passenger jet. Fiddling with our flight controls made the control surfaces of the jet move in the same way. The jet was otherwise inert, and the effect didn't happen with other nearby planes on the ground. Has anyone else seen something like this before? :) Looks like the usual leading-slash bug. Figure out what type of aircraft and then look in the xmls to see if the animations use a leading slash. If so, they will always reference the user's aircraft, rather than the proper AI model. For example, property/surface-positions/left-aileron-pos-norm/property Should be: propertysurface-positions/left-aileron-pos-norm/property (ie. no leading slash) Actually I found this in the AI A320 xml, so maybe that was the aircraft you have seen? Hi All, Would it be worth grepping the aircraft sub directories for the string property/ which probably shouldn't occur anywhere? Regards George - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] valgrind diff no 2 and 3
hi all,
i have continued my random optimizations to flightgear (and simgear, this
time).
changes in the attached diffs
=
in simgear:
* removed _tex_cache from SGMaterial (osg takes care of texture caching)
* made textures load on demand when SGMaterial::get_state() is first called
(the only drawback so far is get_state() becoming non-const)
* osg::State held a reference to its parent material in userData - this
prevented the reference count for SGMaterial from dropping to 0
in flightgear:
* valgrind showed leaks in HUD -- all SGCondition * changed to
SGSharedPtrSGCondition
* also changed HUD_decue to dequeSGSharedPtrinstr_item
* simplified (and switchified) the nav.dat-loading code
* f_interpolate in NasalSys was leaky (valgrind)
* just cosmetics. if noone is working on Traffic/Schedule.cxx i'd like to
have it produce less noise in info-log
both patches need to be applied for SGMaterial to work properly.
future plans
===
i'd like to look at apt.dat-loading more closely. as pietro reported, the
default.tower and default.atis files are out of sync. since the data exists
in apt.dat, i'd like to load it all in one go from there.
also there is version 850 of apt.dat with interesting new features. is anyone
working on getting this into terragear?
i consider the changes to SGMaterial only the first step. ideally, textures
should get unloaded when not being used anymore.
of course there is also still a lot of output from valgrind, which i plan to
investigate further.
as last time: please comment and / or commit
regards,
-till
Index: simgear/scene/material/mat.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/material/mat.cxx,v
retrieving revision 1.40
diff -u -3 -p -r1.40 mat.cxx
--- simgear/scene/material/mat.cxx 4 Dec 2007 22:38:41 - 1.40
+++ simgear/scene/material/mat.cxx 21 Jan 2008 21:23:47 -
@@ -52,8 +52,6 @@ SG_USING_STD(map);
#include mat.hxx
-static mapstring, osg::ref_ptrosg::Texture2D _tex_cache;
-
// Constructors and destructor.
@@ -222,35 +220,24 @@ SGMaterial::init ()
}
}
-bool
-SGMaterial::load_texture ( int n )
-{
-int i = (n = 0) ? n : 0 ;
-int end = (n = 0) ? n+1 : _status.size();
-
-for (; i end; i++)
-{
-if ( !_status[i].texture_loaded ) {
-SG_LOG( SG_GENERAL, SG_INFO, Loading deferred texture
- _status[i].texture_path );
-assignTexture(_status[i].state.get(), _status[i].texture_path,
- wrapu, wrapv, mipmap);
-_status[i].texture_loaded = true;
- }
-}
-return true;
-}
-
osg::StateSet *
-SGMaterial::get_state (int n) const
+SGMaterial::get_state (int n)
{
if (_status.size() == 0) {
SG_LOG( SG_GENERAL, SG_WARN, No state available.);
return NULL;
}
+
+int i = n = 0 ? n : _current_ptr;
+
+if(!_status[i].texture_loaded)
+{
+assignTexture(_status[i].state.get(), _status[i].texture_path,
+ wrapu, wrapv, mipmap);
+_status[i].texture_loaded = true;
+}
+osg::StateSet *st = _status[i].state.get();
-osg::StateSet *st = (n = 0) ? _status[n].state.get()
- : _status[_current_ptr].state.get();
_current_ptr += 1;
if (_current_ptr = _status.size())
_current_ptr = 0;
@@ -279,13 +266,7 @@ SGMaterial::build_state( bool defer_tex_
stateSet-setMode(GL_LIGHTING, osg::StateAttribute::ON);
-if ( !defer_tex_load ) {
-SG_LOG(SG_INPUT, SG_INFO, _status[i].texture_path );
- assignTexture( stateSet, _status[i].texture_path, wrapu, wrapv);
-_status[i].texture_loaded = true;
-} else {
-_status[i].texture_loaded = false;
-}
+_status[i].texture_loaded = false;
osg::Material* material = new osg::Material;
material-setColorMode(osg::Material::AMBIENT_AND_DIFFUSE);
@@ -320,21 +301,11 @@ void SGMaterial::set_state( osg::StateSe
void SGMaterial::assignTexture( osg::StateSet *state, const std::string fname,
int _wrapu, int _wrapv, int _mipmap )
{
- mapstring, osg::ref_ptrosg::Texture2D ::iterator _tex_cache_iter;
- _tex_cache_iter = _tex_cache.find(fname);
- if (_tex_cache_iter == _tex_cache.end())
- {
- osg::Texture2D* texture = SGLoadTexture2D(fname, 0, _wrapu, _wrapv,
-mipmap ? -1 : 0);
- texture-setMaxAnisotropy( SGGetTextureFilter());
- state-setTextureAttributeAndModes(0, texture);
- _tex_cache[fname] = texture;
- }
- else
- {
- state-setTextureAttributeAndModes(0, _tex_cache_iter-second.get());
- // cout Cache hit: fname endl;
- }
+ osg::Texture2D* texture =
Re: [Flightgear-devel] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
dave perry wrote: Tim Moore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dave perry wrote: | Patch adds a member function to FGRenderer class that returns the | current aspect ratio. Uses this in place of 4.0/3.0 in setFOV and | setNearFar. | | The diff follows: | This seems a little confusing / confused. In setFOV, why would you ignore the w argument? Now, I happen to know that /sim/startup/xsize is set to the value of w somewhere in one of the callers, but this is not clear at all. Can we untangle this a bit? In setFOV, you can use w/h for the aspect ratio. But in setNearFar just below this, w and h are not defined in that context, so you need to get the real current aspect ratio from some where. Hi Tim, The following patch uses w/h for the aspect ratio in setFOV and then uses xsize/ysize (from /sim/startup) for the aspect ratio in setNearFar. This accomplishes using the actual aspect ratio in place of 4.0/3.0 without having to add a new member function to the FGRenderer class. Please commit this patch. It fixes the same issue as the last patch and the behavior is the same as described on my last note. renderer.cxx patch follows: Index: renderer.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v retrieving revision 1.100 diff -p -u -r1.100 renderer.cxx --- renderer.cxx6 Jan 2008 23:03:20 -1.100 +++ renderer.cxx21 Jan 2008 15:48:33 - @@ -872,7 +872,7 @@ void FGRenderer::setFOV( float w, float fov_width = w; fov_height = h; osgViewer::Viewer* viewer = globals-get_renderer()-getViewer(); -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, 4.0/3.0, +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, w/h, fov_near, fov_far); } @@ -885,8 +885,10 @@ void FGRenderer::setNearFar( float n, fl n = 0.1; fov_near = n; fov_far = f; +float xsize = fgGetInt(/sim/startup/xsize); +float ysize = fgGetInt(/sim/startup/ysize); osgViewer::Viewer* viewer = globals-get_renderer()-getViewer(); -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, 4.0/3.0, +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, xsize/ysize, fov_near, fov_far); } Thanks, Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] valgrind diff no 2 and 3
On Jan 21, 2008 4:03 PM, till busch wrote: hi all, Hi Till, I don't know all the nuances of the OSG branch and OSG usage, but originally the common material library textures were all loaded at start time so they'd be available at any time and not hit the fps like they would if they needed to be loaded on demand. Then we bumped up the reference count by one so they would never be deleted from the system. Regards, Curt. i have continued my random optimizations to flightgear (and simgear, this time). changes in the attached diffs = in simgear: * made textures load on demand when SGMaterial::get_state() is first called (the only drawback so far is get_state() becoming non-const) * osg::State held a reference to its parent material in userData - this prevented the reference count for SGMaterial from dropping to 0 Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] (no subject)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | With the following model: | | world '' (2) | group 'testgroup1' (2) | poly 'test1' | group 'testgroup2' (1) | poly 'test2' | | I can use a material animation on testgroup1 and both test1 | and test2 respond, which is what I would expect. I can't | seem to get a material animation to work for testgroup2 | though, as long as there is a material animation for it's | parent group. It does not matter what order the animations | are given in the model.xml file, it always fails. Removing | the animation for testgroup1 allows the animation for | testgroup2 to work. Also, using name tags for the | animations doesn't change the behavior. | | This was not the case before the OSG changeover, and breaks | a few important animations in the ch53e cockpit. I can work | around this, but it will be inelegant and require a lot of | extra animations as I will have to flatten out the | structure of the cockpit. Any ideas? | | Josh | | Yeah, this is a side effect of the way I implemented material animations in OSG, in which the material animations set on a parent group override the values of materials in the children, including those set by animations in the children. I'm going to rewrite this soon, so I think you'll see this problem disappear. However, would you expect to animate red-prop in a parent and blue-prop in a child? I don't think that will work in the future. Tim | | | PS, here are the animations: | | animation | typematerial/type | object-nametestgroup2/object-name | property-basesim/model/ch53e/test-mat-2/property-base | diffuse | red-propdiffuse/red/red-prop | green-propdiffuse/green/green-prop | blue-propdiffuse/blue/blue-prop | /diffuse | ambient | red-propambient/red/red-prop | green-propambient/green/green-prop | blue-propambient/blue/blue-prop | /ambient | specular | red-propspecular/red/red-prop | green-propspecular/green/green-prop | blue-propspecular/blue/blue-prop | /specular | emission | red-propemission/red/red-prop | green-propemission/green/green-prop | blue-propemission/blue/blue-prop | /emission | shininess/ | /animation | | animation | typematerial/type | object-nametestgroup1/object-name | property-basesim/model/ch53e/test-mat-1/property-base | diffuse | red-propdiffuse/red/red-prop | green-propdiffuse/green/green-prop | blue-propdiffuse/blue/blue-prop | /diffuse | ambient | red-propambient/red/red-prop | green-propambient/green/green-prop | blue-propambient/blue/blue-prop | /ambient | specular | red-propspecular/red/red-prop | green-propspecular/green/green-prop | blue-propspecular/blue/blue-prop | /specular | emission | red-propemission/red/red-prop | green-propemission/green/green-prop | blue-propemission/blue/blue-prop | /emission | shininess/ | /animation | | | | - | This SF.net email is sponsored by: Microsoft | Defy all challenges. Microsoft(R) Visual Studio 2008. | 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 iD8DBQFHlY8YeDhWHdXrDRURAnsFAJ4uTuirFvgRwQKCm8Cxkwsdm/3a7ACfRcD5 YVQv5U3ZBC5fiNRNz1RtLcM= =pRqF -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
