Re: [Flightgear-devel] FlightGear compilation problem
Brian Topping wrote: make[1]: Entering directory `/home/topping/dev/unix/FlightGear/tests' if gcc -DHAVE_CONFIG_H -I. -I. -I../src/Include -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -MT est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o est-epsilon.c; \ then mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po; else rm -f .deps/est-epsilon.Tpo; exit 1; fi est-epsilon.c:13:19: GL/glut.h: No such file or directory well, glut is missing. On my system (SuSE 9.0/9.1) the header file is /usr/include/GL/glut.h (GLUT = OpenGL Utility Toolkit). Normally comes together with OpenGL. You need the devel-packages (.h - files) in addition to the runtime files (libraries) [if fedora makes this distinction] to compile OpenGL/GLUT sources. HJW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
Oliver C. wrote: Here are my results: With VBO enabled i get 150-195 frames/s With VBO disabled i only get 90-120 frames/s So VBO makes a difference of 60-75 more frames per seconds. I made this benchmark test on a computer with an Athlon Thunderbird 1 GHz CPU, 512 MB SDRam and a Geforce 4 4200 Ti with 64 MB videoram. The OS was Slackware 10 running a Linux kernel Version 2.4.26 and the NVidia driver version was 53.36. I'm not quite sure, but I think the problems *I* encounter have been introduced in driver version 6111. Before other people think WOW, FG could run 60% faster!!!, please keep in mind that an application like FG can't do everything just by using VBOs and DLists. The test program compares 'brute force' vs. VBO, not 'optimized' vs. VBO. And fg/sg/plib already do some optimizations. The maximum possible improvement will be *much* smaller. And that stuff has somehow to be integrated into the scene graph code (plib). Btw., about half a year ago I installed OSG, but didn't reinstall it after upgrading my system. It seemed to be *very* heavy-weight, but I didn't take a closer look. I have no idea how it performs compared to plib's ssg. Being still quite new to FG, I'm afraid that I'm generating too much newcomer noise on Flightgear-devel. If that is the case, please tell me (if possible, without too much harsh wording). I like this project very much, and for me fiddling with source code is at least as much fun as running the binaries. Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test
Paul Surgeon wrote: On Friday, 15 October 2004 22:04, Horst J. Wobig wrote: If somebody wants to try it on his box: just fetch lesson 45 from http://nehe.gamedev.net. On windows this should compile without problems, on linux you need sdl. It segfaults in glGenBuffersARB () on my system. Mandrake 9.1, Ti 4200, nVidia 6111 Paul Thanks for the test. Not very encouraging :-( Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: VBOs - performance test
Alex Romosan wrote: Paul Surgeon [EMAIL PROTECTED] writes: On Friday, 15 October 2004 22:04, Horst J. Wobig wrote: If somebody wants to try it on his box: just fetch lesson 45 from http://nehe.gamedev.net. On windows this should compile without problems, on linux you need sdl. It segfaults in glGenBuffersARB () on my system. Mandrake 9.1, Ti 4200, nVidia 6111 works fine on a radeon mobility 9000 m9 with the open source drivers (this is a thinkpad t40). Thanks. Have you tried with #define NO_VBOS? What is the difference in framerate? Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] VBOs - performance test
I just tried VBO's on my SuSE 9.1 nvidia GF2 MX driver 6111 and xfree86. VBOs are available but do not behave as expected. I get additional stuff rendered :-( Seems to be a bug in the driver when used with MX cards. Maybe it's just the GF2 MX. Now I'm curious how much improvement can be expected on other cards. If somebody wants to try it on his box: just fetch lesson 45 from http://nehe.gamedev.net. On windows this should compile without problems, on linux you need sdl. On my system I just had to untar it, then make and run. It tells you if VBO is available and the framerate with 32k triangles. With #define NO_VBO you can turn VBO off and check the difference. Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
Lee Elliott wrote: On Monday 11 October 2004 10:37, Jon Stockill wrote: Martin Spott wrote: Martin Spott wrote: This patch is great - it works and it significantly increases the frame rate on a simple Linux-PC (old 600 MHz PentiumIII with Radeon9200) from 4-5 to 7-8 fps on the default location, With the recent display list changes things now settle at stable 10 fps. I'd like to express my thanks to everyone who participated in this tremendous improvement(s) ! crease + display list = WOW! I've gone from 3-4FPS at KSFO in the C172 to a rock solid 12 - this seems to be limited by the instruments, because turning the view, or selecting an external view gets 25-35, even with all those models around. I've NEVER seen FlightGear run so smoothly. The fact that a forward cockpit view is so stable (it doesn't matter how many models you point the aircraft at) makes landings at KSFO really smooth, where they used to be almost impossible before because the frame rate was so unpredictable. Thanks to all who contributed. The crease patch works well for me here but the DList patch seems to result in a consistent seg fault. I suspect it's due to the ATI Linux drivers for my Radeon 9200. Can anyone else running Linux with a Radeon 9xxx series card, using ATI's drivers confirm if it works for them? TIA LeeE Are you sure you use the latest simgear? makeDList() should now be in simgear/scene/model/model.cxx Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
1) crease is a patch to PLIB 2) dlist has been solved within simgear: *NO PATCH REQUIRED* Erik could fix this *without* touching plib by moving the call to another thread. It now lives in simgear's model.cxx Make sure that simgear/scene/tgdb/leaf.cxx *does not* contain a call to makeDList(). Horst Chris Metzler wrote: On Tue, 12 Oct 2004 21:27:54 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Forgot the Dlist patch that was posted on the list by Erik and get the all new 0.9.6 or CVS Now I'm a bit confused (again!). I thought that Erik's patch, like Matthias', was a patch to plib. I saw a bunch of CVS commits for SimGear and FlightGear relating to his patch; but they looked like they were merely efforts to determine whether one was using a plib that had the patch in it or not. And over on plib-devel, I saw Erik discussing a patch with Steve Baker that I thought was the final version of the DList patch, http://sourceforge.net/mailarchive/message.php?msg_id=9755451 after Horst Wobig fixed what he thought (and Erik seemed to agree) was the problem. http://baron.flightgear.org/pipermail/flightgear-devel/2004-October/031161.html So I would naively think that in addition to fetching the latest SimGear CVS, one still needs to patch it into plib. Where am I mixed up here? -c -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
Lee Elliott wrote: Hmm... Now I'm getting: config.status: error: cannot find input file: simgear/scene/fgsg/Makefile.in Making all in src-libs make[1]: Entering directory `/common/cvs/CVSROOT/SimGear/src-libs' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/common/cvs/CVSROOT/SimGear/src-libs' Making all in simgear make[1]: Entering directory `/common/cvs/CVSROOT/SimGear/simgear' cd .. /bin/sh ./config.status simgear/simgear_config.h config.status: creating simgear/simgear_config.h make all-recursive make[2]: Entering directory `/common/cvs/CVSROOT/SimGear/simgear' Making all in xml make[3]: Entering directory `/common/cvs/CVSROOT/SimGear/simgear/xml' make[3]: *** No rule to make target `all'. Stop. make[3]: Leaving directory `/common/cvs/CVSROOT/SimGear/simgear/xml' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/common/cvs/CVSROOT/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/common/cvs/CVSROOT/SimGear/simgear' make: *** [all-recursive] Error 1 ...sure enough, there's nothing in ~CVSROOT/simgear/scene/fgsg - the directory's empty. :( LeeE Seems to be a problem in CVS (see a mail a few hours ago concening simgear). I had to edit 2 files in the actual CVS: 1) configure.ac (remove the line with fgsg) 2) simgear/scene/Makefile.am (remove fgsg) Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
Mathias Frhlich wrote: On Freitag 08 Oktober 2004 19:54, Norman Vine wrote: This patch won't be acceptable to the PLIB team unless we can fix this. Hmm, from my local machine, I would say that these are different things mixed together. If I understand right Eriks DList change works on the scenery, not on the imported ac3d models. Correct? This one line change does not work for my radeon on the notebook and gives everything from funny colours to coredumps on my r200 chip in the desktop machine. That plib patch changes the function loading the ac3d models. I have also done a quick check what happens if I make display lists for the ac3d models in the plib loader code. This works well for me. From that, I would tell the plib patch is ok. Any different experience? well, it works for me :-) SuSE Linux 9.1, NVidia GF2 MX 64MB, Driver 6111. Framerate improvement is about 30-40%. *Thanks!* So far I couldn't take off because my joystick stopped working. I'm just recompiling plib with #define JS_NEW 1 in js.h. Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
I wrote: Mathias Frhlich wrote: On Freitag 08 Oktober 2004 19:54, Norman Vine wrote: This patch won't be acceptable to the PLIB team unless we can fix this. Hmm, from my local machine, I would say that these are different things mixed together. If I understand right Eriks DList change works on the scenery, not on the imported ac3d models. Correct? This one line change does not work for my radeon on the notebook and gives everything from funny colours to coredumps on my r200 chip in the desktop machine. That plib patch changes the function loading the ac3d models. I have also done a quick check what happens if I make display lists for the ac3d models in the plib loader code. This works well for me. From that, I would tell the plib patch is ok. Any different experience? well, it works for me :-) SuSE Linux 9.1, NVidia GF2 MX 64MB, Driver 6111. Framerate improvement is about 30-40%. *Thanks!* So far I couldn't take off because my joystick stopped working. I'm just recompiling plib with #define JS_NEW 1 in js.h. Horst but I can confirm the missing ADF scale :-( What I did: (1) - compiled/installed actual plib - compiled/installed simgear - compiled fg == ADF is ok (2) - patched plib (crease.diff) - compiled/installed patched plib - compiled/installed simgear - compiled fg == Framerate improvement, but ADF scale is missing (as Melchior told us) Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sub-model and joystick problems
Lee Elliott wrote: Hello Horst, thanks very much for posting that again - the bit I missed first time was ** --enable-ai-models** When I include this param it works here too. Doh! LeeE Glad I could help. The hint concerning --enable-ai-models came from somebody else. I just checked if it stops working without (what makes sense to me seeing how it's implemented) and included it here to be sure you give it a try. Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sub-model and joystick problems
Lee Elliott wrote: could someone on Linux confirm that the ballistic sub-model stuff works properly for them? The only outstanding difference Vivian and I could identify between our systems is that his is Windows based whereas I'm running Linux. Things work properly on his system but don't on either of the two different (in both h/w s/w respects - i.e. different video cards cpu etc to different kernels 2.4.x vs. 2.6.x and different Debian unstable snap-shots) systems that I've tried. If we can eliminate this difference we know we need to dig deeper into something else... LeeE well, as I mailed two weeks ago, for me it works :-) Maybe I don't know *exactly* what that stuff is supposed to do. What I have is - FG/SG/etc CVS 2004-09-18 23:00 UTC - plib-1.8.3 - Linux SuSE 9.1 - Kernel 2.6.4 - nVidia GF2 MX What I do is - start FG with --fg-root=/usr/local/FlightGear/data --fg-scenery=/usr/local/FlightGear/data/Scenery --airport-id=KNUQ --runway=14L --aircraft=spitfireIIa --control=joystick --enable-random-objects --enable-horizon-effect --enable-enhanced-lighting --enable-distance-attenuation --enable-ai-models --geometry=1024x768 --bpp=32 --timeofday=noon - trigger via property browser What I see/hear is - I canon firing - (very)little red dots from within the cockpit seeming to leave the cannon - (very)little red dots from outside seeming to leave the cannon *that works with --enable-ai-models* - without I see nothing If you need additional info, tell me! Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Effortless Scenery
Hello, Jon Stockill wrote: If you combine calc-tile.pl and find-elevation.pl the end result is something rather useful. Feed a list like this: (1) I'm just making a few perl modules and I would like to use the coding in calc-tile.pl. Is this ok??? (2) Is it possible to store the elevation for objects in stg files *relative* to ground level at a given longitude/latitude? I looked at tileentry.cxx, but I'm not familiar enough with the FG sources/internals to say how this could be done. Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: ---snip If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE Just a thought - can anyone else confirm either behaviour? Well, I upgraded to cvs (simgear/flightgear about 23:00 UTC 2004-09-18). I'm not exactly sure what behaviour is expected, but when I trigger via property browser - I can hear the cannon firing - I can see (very)little red dots from within the cockpit seeming to leave the cannon - I can see (very)little red dots from outside seeming to leave the cannon - I stops after - hmm... 20-30secs? - maybe out-of-submodels :-))) (using plib-1.8.3) Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
