Re: [Flightgear-devel] Multiple graphics card and displays on one machine
On Sat, Mar 15, 2008 at 12:55 AM, Vikas N Kumar [EMAIL PROTECTED] wrote: My graphics cards are capable since I can run fgfs in single screen mode on each screen and it works fine. But when I run with 3 screens, it seems slow. I also see this warning when I run fgfs with 3 screens. Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Ok, so since I have 2 dual head cards and 3 monitors, I moved one of the monitors to the powerful card instead of the less powerful card and the rendering speed became alright. So that problem is solved. The RenderBin warning for FBO 0x8cd5 which seems to be from OSG remains. Now instead of 1 I get two warnings. Also the application on clicking Exit does not exit but hangs. -- http://www.vikaskumar.org/ - 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] Multiple graphics card and displays on one machine
* Vikas N Kumar -- Saturday 15 March 2008: I was able to get the 3 screen thing working but the performance was quite bad. The load scenery objects took more than 2-3 minutes to load [...] You said that you were using everything from CVS/SVN. But this sounds a bit like you aren't using OSG/SVN/*HEAD*, which you should. Also make sure you configured OSG with either of $ cmake . -DCMAKE_BUILD_TYPE=Release $ cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo because without specifying a build-type you'll get Debug, which is quite slow. 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
[Flightgear-devel] Another strange bug
I've just run into another strange FG bug. Climbing up through ~45000ft the frame-rate seems to start dropping to very low rates. While climbing up to ~45000ft I'm getting 35-40 fps but once the problem starts it drops down to somewhere around 4-6 fps. The strange thing is that if I enable the fps display in the bottom right hand corner, it's showing about 20-22 fps. It's clear, from looking at various animations, or even just panning the view to track the ground beneath the aircraft, that the actual fps is closer to 4-6 fps, with distinct stepping or juddering, regardless of the indicated fps. Descending to lower altitudes doesn't stop the problem and doing a rest doesn't work either - the splash screen gets displayed and eventually, after a much longer time than usual, FG starts, but at the same 4-6 fps. It seems very odd that a reset doesn't fix it. I haven't noticed the problem at low altitudes at all. I don't think this is related to the 12 mile radius island effect, or the polygon hole in the white sky either, although both are very apparent at this altitude - the island effect is always there and the hole in the white sky disappears again once you're below ~8000ft. This is with plib-1.8.5, OSG-2.3.4 and current cvs SG FG. Is anyone specifically working on the 'island' and hole-in-the-white-sky problems? These, together with this new 45000ft problem are really quite serious bugs. LeeE - 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] $ fgfs --version
I've now committed a first stab at a --version option. In my copy it works like this: $ fgfs --version 2.0pre-20080314 FG_ROOT=/usr/local/share/FlightGear FG_HOME=/home/me/.fgfs .. but only because my build system sets VERSION in config.h to 2.0pre-build-date. For others this will wrongly show 1.0.0 instead. I think the VERSION should be just the version number in releases (2.0.0), but should contain the build date (actually the configure date) in CVS versions. But this would require that build systems for MS Windows and OSX are also able to set that. (It's easy in automake and scons.) Because I don't know how feasable it is, I haven't committed the description to options.xml yet. For Unices you'd just change this AM_INIT_AUTOMAKE(FlightGear, 1.0.0) in configure.ac to BUILDDATE=`date +%Y%m%d` AM_INIT_AUTOMAKE(FlightGear, 2.0pre-$BUILDDATE) 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
[Flightgear-devel] Airport dependent ATC background chatter patch
Hello flightgear developers,
I created a patch for the Nasal script 'atc-chatter.nas' which makes ATC
background chatter dependent on the airport id.
Currently the airport id used is the one set in
'/sim/presets/airport-id' (but should probably be
'/sim/atc/freq-airport' - the problem is that this property never has a
value when I run fgfs).
The patch works as follows: for every airport there can be a directory
'$FG_ROOT/data/ATC/Chatter/$AIRPORT_ID' containing the specific chatter
.wav files. This directory is queried for existence by the patch and -
if it exists for the current preset airport - is used for background
chatter playback.
If there is no directory for the current airport id, the default
background chatter is used ('UK').
The list of background chatter files is only updated if the airport id
changes from one sample to another. The default background chatter is
always loaded on init to save loading time because there currently are
no airport specific chatter files.
That leads me to another point: I am planning on creating several new
chatter files for KSFO, as this is _the_ airport in fgfs. I have already
save d some audio streams of live KSFO tower/ground/clearance ATC
chatter to my hdd which only need to be chopped into pieces and added to
fgfs.
Another thing I am planning to change in ATC background chatter handling
is the differentiation between ground, tower, clearance chatter. Then
there will be chatter depending on where your airplane currently is
(ground, air,...).
I uploaded the patch (created with fg-submit) to
http://www.ramforth.com/flightgear/Nasal.diff.bz2 and I hope that I am
not the only one to find having more versatile background chatter a nice
feature.
Regards,
Tobias Ramforth
PS: I appreciate suggestions, comments, bug reports on this patch, very
much!
begin:vcard
fn:Tobias Ramforth
n:Ramforth;Tobias
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard
signature.asc
Description: OpenPGP digital 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
Re: [Flightgear-devel] Airport dependent ATC background chatter patch
Hello again, due to the lack of experience with the Nasal scripting system, I initially looked for a changed airport id every time a new ATC chatter message should be played. Now that I 'discovered' the setlistener function, I changed my code to listen to /sim/presets/airport-id. New version at old position http://www.ramforth.com/flightgear/Nasal.diff.bz2. Regards, Tobias Ramforth begin:vcard fn:Tobias Ramforth n:Ramforth;Tobias email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard signature.asc Description: OpenPGP digital 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
Re: [Flightgear-devel] Follow Me / Livery over MP
* Gijs de Rooy -- Friday 14 March 2008: I've used the livery selection system for that. But the problem is that I don't see the changes someone else made when multiplaying. So the livery isn't sended to the MP-servers I think. A vague description deserves a vague response: the livery system works for the R22, the ch47, and the bo105. If it doesn't for you then you made a mistake. Did you follow all my tutorial points, and did you check what the R22 does? 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
[Flightgear-devel] FG build fails with plib 1.8.5 and SLD
I have just tried to build today's cvs. My configure options are normally --disable-glut --enable-sdl --enable-osg viewer. I have downloaded and installed the latest plib svn version. Now, if I include the --enable-sdl option, the make fails as shown in the attached file. I am running debian (sid) and the SDL version from the disro is 1.2.13. I have never experienced ant problems with building and running FGFS until installing plib-1.8.5 (now mandatory). Can anyone help? Kind regards, Alasdair dominatrix:/usr/local/src/flightgear_cvs#make Making all in tests make[1]: Entering directory `/usr/local/src/flightgear_cvs/tests' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/flightgear_cvs/tests' Making all in man make[1]: Entering directory `/usr/local/src/flightgear_cvs/man' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/flightgear_cvs/man' Making all in scripts make[1]: Entering directory `/usr/local/src/flightgear_cvs/scripts' Making all in debug make[2]: Entering directory `/usr/local/src/flightgear_cvs/scripts/debug' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/flightgear_cvs/scripts/debug' Making all in perl make[2]: Entering directory `/usr/local/src/flightgear_cvs/scripts/perl' Making all in examples make[3]: Entering directory `/usr/local/src/flightgear_cvs/scripts/perl/examples' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/flightgear_cvs/scripts/perl/examples' make[3]: Entering directory `/usr/local/src/flightgear_cvs/scripts/perl' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/usr/local/src/flightgear_cvs/scripts/perl' make[2]: Leaving directory `/usr/local/src/flightgear_cvs/scripts/perl' Making all in python make[2]: Entering directory `/usr/local/src/flightgear_cvs/scripts/python' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/flightgear_cvs/scripts/python' make[2]: Entering directory `/usr/local/src/flightgear_cvs/scripts' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/usr/local/src/flightgear_cvs/scripts' make[1]: Leaving directory `/usr/local/src/flightgear_cvs/scripts' Making all in src make[1]: Entering directory `/usr/local/src/flightgear_cvs/src' Making all in Include make[2]: Entering directory `/usr/local/src/flightgear_cvs/src/Include' make all-am make[3]: Entering directory `/usr/local/src/flightgear_cvs/src/Include' make[3]: Leaving directory `/usr/local/src/flightgear_cvs/src/Include' make[2]: Leaving directory `/usr/local/src/flightgear_cvs/src/Include' Making all in Aircraft make[2]: Entering directory `/usr/local/src/flightgear_cvs/src/Aircraft' if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/local/include -g -O2 -D_REENTRANT -MT aircraft.o -MD -MP -MF .deps/aircraft.Tpo -c -o aircraft.o aircraft.cxx; \ then mv -f .deps/aircraft.Tpo .deps/aircraft.Po; else rm -f .deps/aircraft.Tpo; exit 1; fi In file included from /usr/include/plib/pu.h:1591, from ../../src/GUI/gui.h:36, from ../../src/Cockpit/hud.hxx:62, from aircraft.cxx:42: /usr/include/plib/puSDL.h:32:17: error: SDL.h: No such file or directory In file included from /usr/include/plib/pu.h:1591, from ../../src/GUI/gui.h:36, from ../../src/Cockpit/hud.hxx:62, from aircraft.cxx:42: /usr/include/plib/puSDL.h: In function 'void puGetWindowSizeSDL(int*, int*)': /usr/include/plib/puSDL.h:42: error: 'SDL_Surface' was not declared in this scope /usr/include/plib/puSDL.h:42: error: 'display' was not declared in this scope /usr/include/plib/puSDL.h:42: error: 'SDL_GetVideoSurface' was not declared in this scope make[2]: *** [aircraft.o] Error 1 make[2]: Leaving directory `/usr/local/src/flightgear_cvs/src/Aircraft' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/flightgear_cvs/src' make: *** [all-recursive] Error 1 dominatrix:/usr/local/src/flightgear_cvs# - 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] FG build fails with plib 1.8.5 and SLD
* Alasdair Campbell -- Saturday 15 March 2008: /usr/include/plib/puSDL.h:32:17: error: SDL.h: No such file or directory No sdl-devel installed, apparently. But using SDL is depreciated. Dump the --enable-sdl and use --enable-osgviewer instead and *only*. You can't have both. 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
[Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hello, Coming back to computers, we have tried the last 1.00 scenery version. We are very disappointed with it. The coastline process is wrong (or not existing) here two snapshot near LFMN -first, that one with scenery 0.9.10 which was partly wrong (0.9.8 was better) http://pagesperso-orange.fr/GRTux/Scenery0.9.10.jpg -second, the same one with scenery 1.0.0 http://pagesperso-orange.fr/GRTux/Scenery-1.0.jpg With 0.9.10 versus 0.9.8 we had lost some island. But the shape was more or less right. with 1.0.0, It seems that every low level ground near the sea are not correctly processed, getting only straight ground tiles. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - 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] Scenery 1.0.0 coastline is not processed
Hi Gerard! gerard robin wrote: The coastline process is wrong (or not existing) here two snapshot near LFMN -first, that one with scenery 0.9.10 which was partly wrong (0.9.8 was better) http://pagesperso-orange.fr/GRTux/Scenery0.9.10.jpg -second, the same one with scenery 1.0.0 http://pagesperso-orange.fr/GRTux/Scenery-1.0.jpg Hm, we did check a lot of tiles at random for glitches, but these went through our filters. Thank you for the pointer, I will check were this is coming from. Cheers, Ralf - 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] FG build fails with plib 1.8.5 and SLD
On Sat, 2008-03-15 at 17:31 +0100, Melchior FRANZ wrote: * Alasdair Campbell -- Saturday 15 March 2008: /usr/include/plib/puSDL.h:32:17: error: SDL.h: No such file or directory No sdl-devel installed, apparently. But using SDL is depreciated. Dump the --enable-sdl and use -- instead and *only*. You can't have both. m. Thanks Melchior. I tried your option of ./configure --enable-osgviewer and the build went just fine. But I did have the sdl-dev package installed. No matter, sdl in debian looks horribly complicated with many dependencies, so I prefer to leave it alone. So all is OK now except for the hotspots on my c172 radio stack which have gone haywire. Clicking on the COM2 swap button switches COM1 radio, Clicking the ADF buttons change the COM2 radio, the Autopilot buttons are ineffective, etc.etc. Can anyone confirm this behaviour? Kind regards, Alasdair - 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 - 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] MP forest fire model!
On Fri, Mar 14, 2008 at 6:25 PM, Robert Black wrote: On Fri, Mar 14, 2008 at 6:09 AM, Anders Gidenstam wrote: On Mon, 25 Feb 2008, Anders Gidenstam wrote: I thought about making a cellular automata model of a forest fire some And now I finally got around to do that :) It is not quite ready for prime time yet but I have the base cellular automata based on the first paper I stumbled upon [0] - http://fgfs.i-net.hu/modules/xcgal/displayimage.php?pid=57album=15pos=2 http://fgfs.i-net.hu/modules/xcgal/displayimage.php?pid=58album=15pos=3 http://fgfs.i-net.hu/modules/xcgal/displayimage.php?pid=59album=15pos=0 http://fgfs.i-net.hu/modules/xcgal/displayimage.php?pid=60album=15pos=1 [0] http://dx.doi.org/10.1016/j.advengsoft.2006.09.002 The fact that you managed to leverage the multiplayer message passing to propogate the fire through the multiplayer system is really cool (although will people that join after the fire is established be able to catch up and see the same view? ... I'm not trying to nitpick ... not such a big deal if the answer is no ...) So now if we can borrow a better fire/smoke anmation and maybe laydown a semi-translucent black region on the ground beneath the fire we'd be in really good shape. Also, is it possibly to add some natural randomization to the location of the new bits of the fire? A very regular pattern is distracting, but might be less distracting once we've added more realistic smoke and fire. One thing I've seen in other particle systems is the ability to rotate the smoke texture as it grows and drifts ... this gives the impression of localized eddy patterns and more interesting motion within the smoke. I thought that was a cool touch and it doesn't seem like it should be that hard to add to our particle system ... ? Just tossing ideas and comments your direction ... :-) Great work, this is exciting stuff! 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] MP forest fire model!
Curtis Olson schrieb: ... ... ... Just tossing ideas and comments your direction ... :-) Great work, this is exciting stuff! Regards, Curt. -- Hi, getting more and more features into the multiplayer system is really great - the only limiting factor is the causing desaster by design. At the moment I get an enormous impact on the controllabilty of my aircraft when flying an area with a lot of other mp-participants. If you are landing with a helicopter or even hovering your a/c gets nearly uncontrollable. That is the reason I gave up joining the mp-system as it is only fun if you are flying an area where other mp-user are. It is caused by bad design. The local FDM and Display Systems MUST KEEP PRIORITY against the updating of the mp-system, ie. other mp-aircraft, positions, movement, etc. Even if this causes some jumpy display of other mp-objects. That is why there should be a better splitting and limiting of the processortime the MP-SYSTEM has available against that of the FDM/DISPLAY SYSTEM of the local running FlightGear. I don't know how difficult it is to realize such an intelligent time-slicing with privilege to the FDM and display of the local aircraft but it gets more and more important with an increasing number of mp-users and new features. Just my thoughts. I know that there are some arguments against my proposals, ie. towing, formation flying or push-back is only possible if there is a good realtime display of the other party. But retaining control over the own aircraft is more important after my opinion. Regards Georg EDDW - 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] MP forest fire model!
On Sat, 15 Mar 2008, Curtis Olson wrote: The fact that you managed to leverage the multiplayer message passing to propogate the fire through the multiplayer system is really cool (although will people that join after the fire is established be able to catch up and see the same view? ... I'm not trying to nitpick ... not such a big deal if the answer is no ...) Currently, they will not, but the last event by each player will be available to late joiners. It might be possible to fast forward the automata to catch up. (The model is supposed to be deterministic, though my implementation might not.) So now if we can borrow a better fire/smoke anmation and maybe laydown a semi-translucent black region on the ground beneath the fire we'd be in really good shape. Also, is it possibly to add some natural randomization to the location of the new bits of the fire? A very regular pattern is distracting, but might be less distracting once we've added more realistic smoke and fire. I'm toying a bit with the particle systems in FlightGear. The trade-off between visual impact and performance impact isn't easy :) One thing I've seen in other particle systems is the ability to rotate the smoke texture as it grows and drifts ... this gives the impression of localized eddy patterns and more interesting motion within the smoke. I thought that was a cool touch and it doesn't seem like it should be that hard to add to our particle system ... ? I hope to get some help from a visual wiz. My 3d skills are not too good. Just tossing ideas and comments your direction ... :-) Great work, this is exciting stuff! I have a little problem with my normal web hosting so these are only available when my desktop box is up and dyndns is updated (the auto update in my FW/router seems to have broken down): http://gidenstam.dyndns.org:8080/users/anders/FlightGear/ForestFire-20080315.tar.gz http://91.50.93.238:8080/users/anders/FlightGear/ForestFire-20080315.tar.gz Note that this is pre-alpha software :) Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/ - 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] MP forest fire model!
I would like to point out that the primary performance issues induced by the multiplayer system relate to loading new models when new people join (some of the aircraft are quite complex and large). There are probably secondary performance issues with rendering a large number of different MP aircraft (texture paging?) Also, if MP aircraft continue to execute all their associated nasal scripts, there could be a potentially large amount of time that gets spent executing all those scripts. We certainly do need to think about the MP system as we move forward, but the bulk of the problem is in loading new aircraft when new people join, and that is always going to be an issue unless we somehow are able to come up with a lower LOD version of every aircraft for use in the MP system ... and only that lower LOD is actually loaded and used. Regards, Curt. On Sat, Mar 15, 2008 at 2:44 PM, Georg Vollnhals wrote: Curtis Olson schrieb: ... ... ... Just tossing ideas and comments your direction ... :-) Great work, this is exciting stuff! Regards, Curt. -- Hi, getting more and more features into the multiplayer system is really great - the only limiting factor is the causing desaster by design. At the moment I get an enormous impact on the controllabilty of my aircraft when flying an area with a lot of other mp-participants. If you are landing with a helicopter or even hovering your a/c gets nearly uncontrollable. That is the reason I gave up joining the mp-system as it is only fun if you are flying an area where other mp-user are. It is caused by bad design. The local FDM and Display Systems MUST KEEP PRIORITY against the updating of the mp-system, ie. other mp-aircraft, positions, movement, etc. Even if this causes some jumpy display of other mp-objects. That is why there should be a better splitting and limiting of the processortime the MP-SYSTEM has available against that of the FDM/DISPLAY SYSTEM of the local running FlightGear. I don't know how difficult it is to realize such an intelligent time-slicing with privilege to the FDM and display of the local aircraft but it gets more and more important with an increasing number of mp-users and new features. Just my thoughts. I know that there are some arguments against my proposals, ie. towing, formation flying or push-back is only possible if there is a good realtime display of the other party. But retaining control over the own aircraft is more important after my opinion. Regards Georg EDDW - 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] MP forest fire model!
hi georg, i am currently working on a patch that adds model-paging. models (ai, multiplayer and, to some degree, scenery) will be loaded in a different thread. this is more or less what you describe. some successful testing has been done already. so i hope to get it integrated into cvs soon. if you'd like to (beta-)test, feel free to get the latest versions of my patch at: http://flight.bux.at currently these are: http://flight.bux.at/0001-model-paging-v0.4.0-beta-simgear.patch http://flight.bux.at/0001-model-paging-v0.4.2-beta-flightgear.patch note that i'm not pushing for integration yet. the changes still need some clean-up and minimal documentation ;-) i'll be glad for any comments (success or regression reports, for the matter) cheers, -till On Saturday 15 March 2008, Georg Vollnhals wrote: Hi, getting more and more features into the multiplayer system is really great - the only limiting factor is the causing desaster by design. At the moment I get an enormous impact on the controllabilty of my aircraft when flying an area with a lot of other mp-participants. If you are landing with a helicopter or even hovering your a/c gets nearly uncontrollable. That is the reason I gave up joining the mp-system as it is only fun if you are flying an area where other mp-user are. It is caused by bad design. The local FDM and Display Systems MUST KEEP PRIORITY against the updating of the mp-system, ie. other mp-aircraft, positions, movement, etc. Even if this causes some jumpy display of other mp-objects. That is why there should be a better splitting and limiting of the processortime the MP-SYSTEM has available against that of the FDM/DISPLAY SYSTEM of the local running FlightGear. I don't know how difficult it is to realize such an intelligent time-slicing with privilege to the FDM and display of the local aircraft but it gets more and more important with an increasing number of mp-users and new features. Just my thoughts. I know that there are some arguments against my proposals, ie. towing, formation flying or push-back is only possible if there is a good realtime display of the other party. But retaining control over the own aircraft is more important after my opinion. Regards Georg EDDW - 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] FG build fails with plib 1.8.5 and SLD
Alasdair Campbell wrote: So all is OK now except for the hotspots on my c172 radio stack which have gone haywire. Clicking on the COM2 swap button switches COM1 radio, Clicking the ADF buttons change the COM2 radio, the Autopilot buttons are ineffective, etc.etc. Can anyone confirm this behaviour? Try resizing the window. I pointed this out more that a month ago, but Tim Moore (who is maintaining osgviewer) was unable to reproduce the problem on his system. The resize can be dragging a side of the window or minimize/maximize the window. The mouse coordinates are not properly initialized (I speculate) until this is done. - Dave Perry - 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] Multiple graphics card and displays on one machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vikas N Kumar wrote: | On Sat, Mar 15, 2008 at 12:55 AM, Vikas N Kumar | [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | | My graphics cards are capable since I can run fgfs in single screen mode on each screen and it works fine. But when I run with 3 screens, | | it seems slow. | | I also see this warning when I run fgfs with 3 screens. | | Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) | RenderStage::drawInner(,) FBO status= 0x8cd5 | | Ok, so since I have 2 dual head cards and 3 monitors, I moved one of the | monitors to the powerful card instead of the less powerful card and the | rendering speed became alright. So that problem is solved. | | The RenderBin warning for FBO 0x8cd5 which seems to be from OSG | remains. Now instead of 1 I get two warnings. This appeared with the new trees code which uses shaders. It seems to be harmless. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH3E8ceDhWHdXrDRURAr2BAJ4mToyh22XXHr5NurLWGQ28RZAuPgCguM4h 4IT0uxdBXRooux+Yb1EKoHg= =/awE -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
Re: [Flightgear-devel] Multiple graphics card and displays on one machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vikas N Kumar wrote: | On Sat, Mar 15, 2008 at 12:55 AM, Vikas N Kumar | [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | | My graphics cards are capable since I can run fgfs in single screen mode on each screen and it works fine. But when I run with 3 screens, | | it seems slow. | | I also see this warning when I run fgfs with 3 screens. | | Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) | RenderStage::drawInner(,) FBO status= 0x8cd5 | | Ok, so since I have 2 dual head cards and 3 monitors, I moved one of the | monitors to the powerful card instead of the less powerful card and the | rendering speed became alright. So that problem is solved. | | The RenderBin warning for FBO 0x8cd5 which seems to be from OSG | remains. Now instead of 1 I get two warnings. This appeared with the new trees code which uses shaders. It seems to be harmless. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH3E2/eDhWHdXrDRURAl3CAJ9FeBKwZQWFj/TMBokUZb7kFp1NCQCfYqnj 9ICFp2tQN3Kk121eH6TqT0Y= =Q7jq -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
Re: [Flightgear-devel] MP forest fire model!
till busch schrieb: hi georg, i am currently working on a patch that adds model-paging. models (ai, multiplayer and, to some degree, scenery) will be loaded in a different thread. this is more or less what you describe. some successful testing has been done already. so i hope to get it integrated into cvs soon. if you'd like to (beta-)test, feel free to get the latest versions of my patch at: http://flight.bux.at currently these are: http://flight.bux.at/0001-model-paging-v0.4.0-beta-simgear.patch http://flight.bux.at/0001-model-paging-v0.4.2-beta-flightgear.patch note that i'm not pushing for integration yet. the changes still need some clean-up and minimal documentation ;-) i'll be glad for any comments (success or regression reports, for the matter) cheers, -till Hi Till, I just downloaded the patches and will try them and report afterwards. Thank you very much for your work, a better working MP system with all the possibilities one can think about would make that principially strong part of FlightGear much more enjoyable and more important - usable. Georg - 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] MP forest fire model!
Curtis Olson schrieb: I would like to point out that the primary performance issues induced by the multiplayer system relate to loading new models when new people join (some of the aircraft are quite complex and large). There are probably secondary performance issues with rendering a large number of different MP aircraft (texture paging?) Also, if MP aircraft continue to execute all their associated nasal scripts, there could be a potentially large amount of time that gets spent executing all those scripts. We certainly do need to think about the MP system as we move forward, but the bulk of the problem is in loading new aircraft when new people join, and that is always going to be an issue unless we somehow are able to come up with a lower LOD version of every aircraft for use in the MP system ... and only that lower LOD is actually loaded and used. Regards, Curt. Hi Curtis, thank you very much for your answer and explanations. I will try Till's patches, hoping that these might improve the situation. I expect even more user of the MP system in the future as we see increasing interest in FG especially from younger people who are very interested in doing things together - either MP or meeting in the International Forum. Something one can really be happy about. Regards Georg - 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] autopilot u_min and u_max...
Hi all , I've been trying to change the xmlautopilot to use prop and value for the u_min and u_max properties , and currently have quite a mess on my hands right now :) The idea is to have a min and max property to control bank-limit / pitch with a panel knob ... setting the u_min and u_max from a property seems to be working , but I get some strange things happening . The pi-simple controller isnt clamped anymore (so i removed the clamp check )... and the output goes immediately to the u_min value...although u_min and u_max are checked every update... Has anyone else attempted this , with good results ? Or , hopefully , already implemented this ? Anyway , I'll keep plugging away at it, the answer is probably staring me in the face and I can't see it. Is this something that should be implemented anyway ? Cheers -- SydSandy [EMAIL PROTECTED] - 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] Rogue objects at KSQL
Hi All, There are a few objects that have been misplaced at KSQL. 1. Light tower to the right of Runway 30. 2. A large building (black and grey at the end of the same runway) It seems that the green and white light from the tower is solid. I have take a screen shot or two which I haven;'t attached to this email. Assuming that this is not a known bug, any comments on how to fix these two artifacts. (I though the problem of light being solid was fixed.) I am using Flightgear CVS version with glut. 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] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-03-09_17:09:52 (fredb) /var/cvs/SimGear-0.3/source/projects/VC7.1/SimGear.vcproj Update MSVC 7.1 projects 2f585eeea02e2c79d7b1d8c4963bae2d - 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
