Re: [Flightgear-devel] Aircraft loading problem in 9.8
On January 21, 2005 09:01 am, Frederic Bouvier wrote: > Quoting Innis Cunningham: > > "Curtis L. Olson" writes > > > > >Innis, > > > > > >I had no problem loading the version Ampere sent me in v0.9.8. I did > > >notice there was a large (and seemingly arbitrary) mix of file > > > permission, capitalization, etc. I'm running linux. If you are > > > running windows, perhaps there is a dos/unix line ending problem in one > > > of the files? > > > > Thanks Curt and yes I am runing windows. > > But if there was a line ending problem would this have not showed up > > in 9.6 and 9.5.In these versions it runs without trouble. > > The ac loader has been overhauled and many features were added, and > regressions or stricter checked could have sneak in. Send me privately this > model if you want me to test on the windows platform with adequate > debugging tools. > > -Fred Problem fixed. There was a dependency on the 747. This will be removed in the future. Now, I got a little problem of my own. Initially, I couldn't compile plib because it kept saying that I am missing glList and glLookat. This was "fixed" after I installed mesag3, and the computer automatically removed libraries belonged to x-window and x-lib-mesa. There was no problem during compilation after that. Everything went smoothly until I tried to run FlightGear. After entering the command line, the FlightGear window poped up, showed me the splash screen, then the entire system frozed. I could hear the harddrive working like crazy. This went on for about 5 minutes, then FlighGear terminated with a message "Terminated"... very helpful. I tried pipping the output into a text file. Unfortunately, the file was incompleted for some reason. I assume this problem I am having is related to the package changes. I want to hear opinions from you guys before I reinstall x-lib-mesa again. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rain and snow videos or photos
On January 24, 2005 06:16 pm, Roman Grigoriev wrote: > Thanx Ampere! > The main thing I got - blur on terrain and objects and blurry runway lights > and also reflections from wet runway. Ok I try to implement it ;-) > Thanx Speaking of blur, is there someway to apply antialiasing effect in the area bounded by the windshield? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft loading problem in 9.8
On January 24, 2005 03:45 am, Erik Hofman wrote: > I expect you have replaced the accelerated drivers by a software only > driver now. You should have installed the mesag3-dev package only. > > Erik On January 24, 2005 07:32 am, Curtis L. Olson wrote: > As someone else mentioned, it sounds like you need to revisit your > accelerated driver config and make sure that is all running. It sounds > like you very likely could be back to software only rendering. > > Curt. Thanks guys. I guess I will have to reinstall all the packages that the computer uninstalled. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On January 24, 2005 12:50 pm, Jim Wilson wrote: > Just out of curiosity, is anyone getting this slowdown with ATI cards? > > Best, > > Jim If you mean whether I get slow down on airport at night, the answer is yes. In external view, I get about 6-7fps. At night, the framerates get halved. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
How about not rendering ground textures at night? Has this been done yet? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flightgear to demo 747 at Scale 3x.
Please take some pictures and videos of the Expo. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Curiosity about antialiasing
At the moment, is antialiasing applied to textures themselves? If so, what will happen if antialiasing is applied to the final render/output instead? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speedbrakes / Spoilers
On February 10, 2005 08:27 am, James Turner wrote: > BTW, there is no keybinding for reverse thrust : I'm going to test with > some nasal code i found in one of the joystick files, but is there a > free key I should use? Ctrl-R perhaps? For commercial airliners at least, it will make more sense to map the reverser to Ctrl+PgDown. The reason being is that the throttles are mapped to PgUp and PgDown, and thrust-reverse is part of the throttles. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GLSL shaders for flightgear
On February 17, 2005 11:03 am, Dave Culp wrote: > > http://fgfs.narod.ru/fgfs-006.jpg > > Roman > > I had a really slow download from there so I'm mirroring it here: > > http://home.comcast.net/~davidculp2/3207.0.fgfs-006.jpg > > This should work better, at least over on this side of the Atlantic. > > > Dave It looks nice, but I think the lights should be larger and sharper as they become closer. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Cool photo
On February 17, 2005 02:42 pm, Josh Babcock wrote: > Found a link to this on fark.com. > > http://www.airliners.net/open.file?id=777174&size=L&sok=&photo_nr=&prev_id= >&next_id= > > Josh This photo brings up one question again: curved taxiways. With aircrafts like the A380 and B747, you can't make a turn in game without going into the grass. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: Okay ... who was it?
On February 18, 2005 08:02 am, Melchior FRANZ wrote: > I'll find out anyway. I can't stand people borrowing things from me and > returning them like *that*! > > http://members.aon.at/mfranz/exhibit_A.jpg > > m. Yes, that's a very nice touch. =) On February 18, 2005 12:45 pm, Christian Mayer wrote: > This reminds me, that we don't have a nice crash simulation yet. (It > doesn't need to be realistic). > > We probably could do this, when an crash occures: > > 1) switch to external view (that should be easy) > 2) split up the scenegraph of the model and solve a simple motion > equation for the parts (so that they "bounce" on the ground - that needs > a heavy damping though) > 3) put a fireball in the middle > > The result isn't realistic but much "nicer" than the current approach > (it looks more like an arcade game though...) > > Step 1 and 2 shouldn't be too hard to do with the current code. > > CU, > Christian Every landing is basically a crash... or every crash is basically a landing. The two terms just differ in how much damage the aircraft received. ;-) In my opinion, it will be better in the long run to model fatigue instead. By modelling fatigue: * damages can be accumlated. For example, the aircraft can make 19 hard landings without incident, but has its landing gears break off in the 20th. * parts can still break off right away if enough force is applied, like what you've suggested in #2. For visualizations, different effects can be created for different materials contacting with some other material. For contacts with concrete or asphalt: rubber will create smoke, metal will create sparks, fuel tanks will create fireballs and black smoke, etc. Putting all the above into a fatigue-routine or a fatigue-class, we can make a call to it everytime the aircraft makes a contact with the ground. We can make a call to it every second, too. Afterall, aicrafts can disintegrate at any time. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Cool photo
On February 18, 2005 04:07 pm, Ampere K. Hardraade wrote: > On February 17, 2005 02:42 pm, Josh Babcock wrote: > > Found a link to this on fark.com. > > > > http://www.airliners.net/open.file?id=777174&size=L&sok=&photo_nr=&prev_i > >d= &next_id= > > > > Josh > > This photo brings up one question again: curved taxiways. > > With aircrafts like the A380 and B747, you can't make a turn in game > without going into the grass. > > > > Ampere Oops... sorry, I meant SIMULATOR. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear booth at Scale 3X
On February 18, 2005 04:11 am, Erik Hofman wrote: > It really is a nice setup. Good work John. > It also looks to me like a pleasant isle of joy in an otherwise boring > event (am I right about that?). > > > Erik lol... I have a similar thought about the event. Nice simulator, pictures and videos, by the way. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument headaches
On February 22, 2005 04:20 pm, Paul Surgeon wrote: > The way I see it is an instrument should be able to have it's own set of > animation, input and sound config files as well as nasal scripts. > Then only a single include has to be done in an aircraft config file to > load the instrument at the right location. I like that idea. In fact, I think the samething should be done for other aircraft's systems, especially for the engines. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs
On February 22, 2005 06:09 am, Steve Hosgood wrote: > I might suggest that those of us who've seen this sort of problem seem > to have slow 3D rendering. Yes, I have slow rendering. When the ground is within view, the framerate never goes beyond 15. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Help with B-29
On March 15, 2005 07:27 am, Josh Babcock wrote: > I abandoned the idea of using JSBSim mostly though because I can't find any > polar data on the superfort wing. I think DATCOM+can give you the data that you want. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b-29 alpha
I get the following outputs from FlightGear 0.9.8 on Debian Linux: [EMAIL PROTECTED]:~$ /usr/local/FlightGear/bin/fgfs --fg-scenery=/usr/local/FlightGear/share/FlightGear/Scenery-0.9.8 --airport=LFBO --enable-real-weather-fetch --aircraft=b29 --lat=43.62176 --lon=1.377905 WARNING: ssgSGIHeader::: Failed to open '/usr/local/FlightGear/share/FlightGear/Aircraft/b29/Models/b29-tail-mark.rgb' for reading. WARNING: ssgSGIHeader::: Failed to open '/usr/local/FlightGear/share/FlightGear/Aircraft/b29/Models/m51.rgb' for reading. Object LeftAileron not found Object RightNavLightOn not found Object RightNavLightOn not found Object RightLandLightOn not found Object RightLandLightOn not found Object OpaqueWindows not found Altitude = 499 Temp at alt (C) = 9 Temp sea level (C) = 9.95687 Altitude = 499 Dewpoint at alt (C) = 8 Dewpoint at sea level (C) = 8.0998 Incorrect path in configuration file. b29-common.xml initialized WARNING: Legacy engine definition in YASim configuration file. Please fix. WARNING: Legacy engine definition in YASim configuration file. Please fix. WARNING: Legacy engine definition in YASim configuration file. Please fix. WARNING: Legacy engine definition in YASim configuration file. Please fix. Segmentation fault Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
On April 6, 2005 05:18 am, Melchior FRANZ wrote: > Here is an improved version. It initializes "gear" with settimer, > because otherwise using "/controls/gear" could lead to collisions with > other parts that messed with it at startup. You can instead use a > different property path. And then, we keep SDL's auto-key-repeats from > triggering the same function again and again. This isn't a big problem > and works, too. It's just a waste of CPU cycles and then, you may want > to use the gear functions for other effects, where it could be a problem. Something along these lines may be able to free up those CPU cycles: nasal # Command flaps' movement. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
On April 7, 2005 03:09 am, Melchior FRANZ wrote: > Your standard Nasal > key binding skeleton with one commented out line would do (literally) > nothing to solve this problem. But maybe I just didn't understand your > performance enhancement!? Are you suggesting that we replace all nasal > key bindings by NOOPs to save CPU cycles? :-] > > m. It was merely a pseudo code. Forgive me if I interpeted the problem incorrectly. ;-) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Was: Re: [Flightgear-devel] realistic scenery
On April 19, 2005 09:24 pm, Curtis L. Olson wrote: > I can't afford a lot of scsi ... Have you tried getting these off E-Bay? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] What happened to Flitetutor
I have been meaning to ask this for a while: Does anybody know what happened to the project? Whoever was working on it seems to have just diappeared. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Congratulation to Airbus for the successful first flight of the A380
I was up all morning watching it. =) http://www.airliners.net/open.file/825950/L/ http://www.airliners.net/open.file/825949/L/ Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Congratulation to Airbus for the successful first flight of the A380
http://www.airbus.com/A380/Seeing/indexminisite.aspx Click on Discover, then Videos for the video of the take off. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Congratulation to Airbus for the successfulfirst flight of the A380
Another congratulation is in order -- successful landing. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Error compiling FlightGear
I've just upgraded SimGear, but I was getting the following errors when I was trying to compile FlightGear today: localhost:/usr/local/src/FlightGear-0.9.8# make Making all in tests make[1]: Entering directory `/usr/local/src/FlightGear-0.9.8/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 gcc -g -O2 -D_REENTRANT -L/usr/X11R6/lib -L/usr/local//lib -o est-epsilon est-epsilon.o if gcc -DHAVE_CONFIG_H -I. -I. -I../src/Include -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -MT gl-info.o -MD -MP -MF ".deps/gl-info.Tpo" -c -o gl-info.o gl-info.c; \ then mv -f ".deps/gl-info.Tpo" ".deps/gl-info.Po"; else rm -f ".deps/gl-info.Tpo"; exit 1; fi gcc -g -O2 -D_REENTRANT -L/usr/X11R6/lib -L/usr/local//lib -o gl-info gl-info.o -lSM -lICE -lXi -lXext -lX11 -ldl -lm gl-info.o(.text+0xd): In function `getPrints': /usr/local/src/FlightGear-0.9.8/tests/gl-info.c:28: undefined reference to `glGetString' gl-info.o(.text+0x44): In function `getPrint2f': /usr/local/src/FlightGear-0.9.8/tests/gl-info.c:34: undefined reference to `glGetFloatv' gl-info.o(.text+0x84): In function `getPrintf': /usr/local/src/FlightGear-0.9.8/tests/gl-info.c:41: undefined reference to `glGetFloatv' gl-info.o(.text+0xc4): In function `getPrint2i': /usr/local/src/FlightGear-0.9.8/tests/gl-info.c:48: undefined reference to `glGetIntegerv' gl-info.o(.text+0x104): In function `getPrinti': /usr/local/src/FlightGear-0.9.8/tests/gl-info.c:55: undefined reference to `glGetIntegerv' gl-info.o(.text+0x147): In function `main': /usr/local/src/FlightGear-0.9.8/tests/gl-info.c:61: undefined reference to `glutInit' gl-info.o(.text+0x153):/usr/local/src/FlightGear-0.9.8/tests/gl-info.c:62: undefined reference to `glutInitDisplayMode' gl-info.o(.text+0x15f):/usr/local/src/FlightGear-0.9.8/tests/gl-info.c:63: undefined reference to `glutCreateWindow' collect2: ld returned 1 exit status make[1]: *** [gl-info] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear-0.9.8/tests' make: *** [all-recursive] Error 1 I am seeing double slashes in the above outputs. These double slashes also appeared while I was running configure: checking for extra include and lib directories... + found /usr/local/FlightGear/bin + found /usr/X11R6/include + found /usr/X11R6/lib + found /usr/X11R6/bin + found /usr/local//include + found /usr/local//lib + found /usr/local//bin I've moved to Xorg recently by downloading the Debian packages from ubuntu repostory. I've also got glut and mesa from the same server, but I'm not sure whether this downloads contribute to the above errors. I have no idea what I did wrong, so any advise will be helpful. Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling FlightGear
I have tried everything I can think off. I have reinstalled the plib1.8.4 and
plib1.8.4-dev packages. I have recompiled simgear. I have even reinstalled
all the graphics-related package, but I still get the same error messages
when I was trying to compile FlightGear.
In the attachment is a list of packaged that I have installed. Perhaps
someone can point out the package that I am missing?
If I have all the necessary packages, would faulty simlinks be the cause of my
problems?
Please help, =(
Ampere
ii adduser3.63 Add and remove users and groups
ii alien 8.52 install non-native packages with dpkg
ii alsa-base 1.0.8-7ALSA driver configuration files
ii alsa-utils 1.0.8-4ALSA utilities
ii apt0.5.28.6 Advanced front-end for dpkg
ii apt-utils 0.5.28.6 APT utility programs
ii aptitude 0.2.15.9-2 terminal-based apt frontend
ii ark3.3.2-1KDE archiving tool
ii ash0.5.2-4Compatibility package for the Debian Almquis
ii at 3.1.8-11 Delayed job execution and batch processing
ii autoconf 2.59a-3automatic configure script builder
ii automake1.81.8.5-3A tool for generating GNU Standards-complian
ii autotools-dev 20050422.1 Update infrastructure for config.{guess,sub}
ii base-config2.64 Debian base system configurator
ii base-files 3.1.2 Debian base system miscellaneous files
ii base-passwd3.5.9 Debian base system master password and group
ii bash 3.0-14 The GNU Bourne Again SHell
ii bc 1.06-17The GNU bc arbitrary precision calculator la
ii binutils 2.15-5 The GNU assembler, linker and binary utiliti
ii bsdmainutils 6.0.17 collection of more utilities from FreeBSD
ii bsdutils 2.12p-4Basic utilities from 4.4BSD-Lite
ii bzip2 1.0.2-5high-quality block-sorting file compressor -
ii console-common 0.7.51 Basic infrastructure for text console config
ii console-data 2002.12.04dbs- Keymaps, fonts, charset maps, fallback table
ii console-tools 0.2.3dbs-56Linux console and font utilities
ii coreutils 5.2.1-2The GNU core utilities
ii cpio 2.5-1.2GNU cpio -- a program to manage archives of
ii cpp3.3.5-3The GNU C preprocessor (cpp)
ii cpp-3.33.3.5-12 The GNU C preprocessor
ii cpp-3.43.4.3-12 The GNU C preprocessor
ii cramfsprogs1.1-6 Tools for CramFs (Compressed ROM File System
ii cron 3.0pl1-87 management of regular background processing
ii cryptplug 0.3.16-1 Collection of plugins to crytographic engine
ii cvs1.12.9-13 Concurrent Versions System
ii dash 0.5.2-4The Debian Almquist Shell
ii dbus-1 0.23.4-1 simple interprocess messaging system
ii debconf1.4.48 Debian configuration management system
ii debconf-i18n 1.4.48 full internationalization support for debcon
ii debconf-utils 1.4.48 debconf utilities
ii debhelper 4.2.35 helper programs for debian/rules
ii debianutils2.13.2 Miscellaneous utilities specific to Debian
ii defoma 0.11.8-0.1 Debian Font Manager -- automatic font config
ii dhcp-client2.0pl5-19.1DHCP Client
ii dialog 1.0-20050306-1 Displays user-friendly dialog boxes from she
ii dictionaries-c 0.25.8 Common utilities for spelling dictionary too
ii diff 2.8.1-11 File comparison utilities
ii discover 2.0.7-2.1 hardware identification system
ii discover-data 2.2005.02.13-1 Data lists for Discover hardware detection s
ii dpkg 1.10.27Package maintenance system for Debian
ii dpkg-dev 1.10.27Package building tools for Debian
ii drm-trunk-modu 2005.02.08-1 Source for the DRI CVS trunk DRM modules
ii dselect1.10.27a user tool to manage Debian packages
ii e2fslibs 1.37-2 ext2 filesystem libraries
ii e2fsprogs 1.37-2 ext2 file system utilities and libraries
ii ed 0.2-20 The classic unix line editor
ii eject 2.0.13deb-8sar ejects CDs and operates CD-Changers under Li
ii emacsen-common 1.4.16 Common facilities for all emacsen
ii enscript 1.6.4-7Converts ASCII text to Postscript, HTML, RTF
ii esound-common 0.2.35-2 Enlightened Sound Daemon - Common files
ii exim4 4.50-6 metapackage to ease exim MTA (v4) installati
ii exim4-base 4.50-6 support files for all exim MTA (v4) packages
ii exim4-config 4.50-6 configuration for the exim MTA (v4)
ii exim4-daemon-l 4.50-6 lightweight exim MTA (v4) daemon
ii fdutils5.4-20040228-3 Linux floppy utilities
ii festival
Re: [Flightgear-devel] Error compiling FlightGear
On May 2, 2005 07:42 am, Arnt Karlsen wrote: > ..I don't see X.org installed in your list, you compiled from source and > put it in the /usr/local tree? No. I put a source in my /etc/apt/sources.list and got the binary from http://www.nixnuts.net/files/. I didn't perform any compilation. Xorg is installed: ii xserver-xfree8 2005.02.08-1 The Xorg X server [DRI trunk] I even confirmed it running by running the Check.sh script from ATI's website. Here's the output: Detected configuration: Architecture: i686 (32-bit) X Server: Xorg 6.8.1.99 Oh, one more thing. Could this be the problem? [EMAIL PROTECTED]:~$ cat /var/log/Xorg.0.log | grep EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (EE) Failed to load /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so (EE) Failed to load module "GLcore" (loader failed, 7) (II) Loading extension MIT-SCREEN-SAVER (EE) Couldn't load XKB keymap, falling back to pre-XKB keymap Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Error compiling FlightGear
On May 2, 2005 03:39 am, Melchior FRANZ wrote: > Oh. freeglut and something that looks like opengl is already there, but the > commend in brackets looks suspicious: > > xlibmesa-gl4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] > > For XFree86? But you are running Xorg's X11R6.8.* now? Maybe you need a > different [Xorg] version of these packages? > > m. I now got the Xorg versions of mesa from ubuntu repostory. ii xlibmesa-dev 6.8.2-10 X.Org Mesa development libraries transitiona ii xlibmesa-dri 6.8.2-10 Mesa 3D graphics library modules [X.Org] ii xlibmesa-gl6.8.2-10 Mesa 3D graphics library [X.Org] ii xlibmesa-gl-de 6.8.2-10 Mesa 3D graphics library development files [ ii xlibmesa-gl1-d 2005.02.08-1 Mesa 3D graphics library [DRI trunk] ii xlibmesa-glu 6.8.2-10 Mesa OpenGL utility library [X.Org] ii xlibmesa-glu-d 6.8.2-10 Mesa OpenGL utility library development file They didn't make any different. I'm still getting the same errors when I am trying to compile FlightGear. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Error compiling FlightGear
On May 2, 2005 04:41 pm, Melchior FRANZ wrote: > This does indeed look ugly. I assume that no 3d apps are running HW > accelerated? I don't really know. glxinfo says direct rendering: yes. Xorg.0.log also reports direct rendering is enabled. Enemy Territory also runs, although it is virtually unplayable just like the days when I was using XFree. All these evidences are telling me that applications are using hardware acceleration, but I have a feeling that applications are still relying on software rendering. > I still wonder, though, how fgfs' "configure" could run through without > complaint. You should also clean the source trees if you haven't already > (make clean; rm -rf autom4te.cache) and configure again. Configure returned no problem, but FlightGear still failed to compile. Same errors. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling FlightGear
On May 2, 2005 04:55 pm, Arnt Karlsen wrote: > ..their Check.sh is meant for what??? Their own proprietary drivers, or > also for open source X.org It meant to check what version of xserver you are running: XFree4.1.0, XFree4.2.0, XFree4.3.0 and Xorg6.8.0, so people can download the appropiate prorietary drivers. I merely used the script to check what version of xserver is current running. > ..no, it's possibly a symptom pointing to the problem, this line only > says GLcore failed to load, further up in your log we might see why. > > ..try 'grep -B10 EE', to see 10 lines immediately ahead of each EE. (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "SyncMaster 172T" (**) | |-->Device "ATI 9200SE" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xorg" (**) XKB: rules: "xorg" (**) Option "XkbModel" "pc104" -- [19] -1 0 0xe400 - 0xe4ff (0x100) IX[B] [20] -1 0 0xe000 - 0xe01f (0x20) IX[B] [21] -1 0 0xffa0 - 0xffaf (0x10) IX[B] [22] -1 0 0xec00 - 0xec1f (0x20) IX[B] [23] -1 0 0xe880 - 0xe89f (0x20) IX[B] [24] -1 0 0xe800 - 0xe81f (0x20) IX[B] [25] -1 0 0xd800 - 0xd8ff (0x100) IX[B](B) (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so dlopen: /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so: undefined symbol: __glXLastContext (EE) Failed to load /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so (II) UnloadModule: "GLcore" (EE) Failed to load module "GLcore" (loader failed, 7) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Error compiling FlightGear
On May 2, 2005 04:31 pm, Melchior FRANZ wrote:
> My favorite "strace" could give you some hint in either case:
>
> A) $ strace -fF -eopen glxinfo 2>&1|tee /tmp/strace.log
>
> B) $ strace -fF -eopen ./configure 2>&1|tee /tmp/strace.log
>
> If you search through that log file, you'll see *where* and *what* either
> program searches, and why it doesn't find what it searches. Especially
> "/libopengl" would be interesting.
Interesting. It seems configure is searching for libGLcore.so and
libGL.core.a in /usr/X11R6/lib and other directories, but
not /usr/X11R6/lib/modules-dri-trunk where the modules are actually in.
[pid 10686] open("/usr/X11R6/lib/libGL.so", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 10686] open("/usr/X11R6/lib/libGL.a", O_RDONLY) = 13
[pid 10686] open("/usr/X11R6/lib/libGL.a", O_RDONLY) = 14
[pid 10686] open("/usr/X11R6/lib/libGL.a", O_RDONLY) = 8
[pid 10703] open("/usr/X11R6/lib/libGLcore.so", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 10703] open("/usr/X11R6/lib/libGLcore.a", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 10703] open("/usr/local//lib/libGLcore.so", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 10703] open("/usr/local//lib/libGLcore.a", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 10703] open("/usr/lib/gcc-lib/i486-linux/3.3.5/libGLcore.so", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 10703] open("/usr/lib/gcc-lib/i486-linux/3.3.5/libGLcore.a", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 10703] open("/usr/lib/gcc-lib/i486-linux/3.3.5/../../../libGLcore.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 10703] open("/usr/lib/gcc-lib/i486-linux/3.3.5/../../../libGLcore.a",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 10703] open("/usr/bin/../lib/libGLcore.so", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 10703] open("/usr/bin/../lib/libGLcore.a", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 10703] open("/usr/i386-linux/lib/libGLcore.so", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 10703] open("/usr/i386-linux/lib/libGLcore.a", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 10703] open("/usr/local/lib/libGLcore.so", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 10703] open("/usr/local/lib/libGLcore.a", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 10703] open("/lib/libGLcore.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
[pid 10703] open("/lib/libGLcore.a", O_RDONLY) = -1 ENOENT (No such file or
directory)
[pid 10703] open("/usr/lib/libGLcore.so", O_RDONLY) = -1 ENOENT (No such file
or directory)
[pid 10703] open("/usr/lib/libGLcore.a", O_RDONLY) = -1 ENOENT (No such file
or directory)
...
...
Do you think adding /usr/X11R6/lib/modules-dri-trunk to /etc/ld.so.conf will
fix the problem?
Ampere
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling FlightGear
First, let me say thank you for all the help, guys. I have reinstalled all the graphics related packages again. For some reasons, it worked this time. I managed to compile FlightGear without problems. But now I am having another issue: FlightGear doesn't run and gives me the following messages instead: WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgSGIHeader::: Failed to open '/usr/local/FlightGear/share/FlightGear/Textures/Sky/cl_cumulus.rgb' for reading. WARNING: ssgSGIHeader::: Failed to open '/usr/local/FlightGear/share/FlightGear/Textures/Sky/cl_stratus.rgb' for reading. X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 39 Current serial number in output stream: 40 There are a lot of results when I search for "X Error of failed requste", but very little when I include "GLXUnsupportedPrivateRequest" in the search string. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling FlightGear
On May 2, 2005 07:12 pm, Arnt Karlsen wrote: > ..play with grep -B 20, 25 etc, I find it hard to believe this: > > undefined symbol: __glXLastContext > > ..is causing DRI to fall over. That command doesn't work, nor does grep -B=20. So I have just attached the entire log. Sorry. Ampere log.tar.gz Description: application/tgz ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling FlightGear
On May 2, 2005 10:26 pm, Arnt Karlsen wrote: > cat /var/log/Xorg.0.log | grep -B 20 EE -- [9] -1 0 0xf000 - 0xefff (0x0) MX[B]O [10] -1 0 0xff8c - 0xff8d (0x2) MX[B](B) [11] -1 0 0xff8f - 0xff8f (0x1) MX[B](B) [12] -1 0 0xc000 - 0xcfff (0x1000) MX[B](B) [13] -1 0 0x1f80 - 0x1f8003ff (0x400) MX[B] [14] -1 0 0x2000 - 0x27ff (0x800) MX[B](B) [15] -1 0 0x - 0x (0x1) IX[B] [16] -1 0 0x - 0x00ff (0x100) IX[B] [17] -1 0 0xd400 - 0xd4ff (0x100) IX[B] [18] -1 0 0xe080 - 0xe0bf (0x40) IX[B] [19] -1 0 0xe400 - 0xe4ff (0x100) IX[B] [20] -1 0 0xe000 - 0xe01f (0x20) IX[B] [21] -1 0 0xffa0 - 0xffaf (0x10) IX[B] [22] -1 0 0xec00 - 0xec1f (0x20) IX[B] [23] -1 0 0xe880 - 0xe89f (0x20) IX[B] [24] -1 0 0xe800 - 0xe81f (0x20) IX[B] [25] -1 0 0xd800 - 0xd8ff (0x100) IX[B](B) (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so dlopen: /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so: undefined symbol: __glXLastContext (EE) Failed to load /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so (II) UnloadModule: "GLcore" (EE) Failed to load module "GLcore" (loader failed, 7) -- (II) Module dri: vendor="X.Org Foundation" compiled for 6.8.1.99, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/X11R6/lib/modules-dri-trunk/linux/libdrm.so (II) Module drm: vendor="X.Org Foundation" compiled for 6.8.1.99, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules-dri-trunk/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 6.8.1.99, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER -- (**) Generic Mouse: Protocol: "Microsoft" (**) Option "SendCoreEvents" "true" (**) Generic Mouse: always reports core events (**) Option "Device" "/dev/ttyS0" (**) Option "BaudRate" "1200" (**) Option "StopBits" "1" (**) Option "DataBits" "7" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "0" (**) Option "FlowControl" "None" (**) Option "Emulate3Buttons" "true" (**) Generic Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5" (**) Generic Mouse: ZAxisMapping: buttons 4 and 5 (**) Generic Mouse: Buttons: 5 (**) Generic Mouse: BaudRate: 1200 (II) XINPUT: Adding extended input device "Generic Mouse" (type: MOUSE) (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD) (EE) Couldn't load XKB keymap, falling back to pre-XKB keymap I have gone through the entire log. Aside from the errors in loading libGLcore.so, there's also a couple of lines about success in loading libGLcore.so (as a sub module). =/ (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so dlopen: /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so: undefined symbol: __glXLastContext (EE) Failed to load /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so (II) UnloadModule: "GLcore" (EE) Failed to load module "GLcore" (loader failed, 7) ... ... ... (II) LoadModule: "glx" (II) Loading /usr/X11R6/lib/modules-dri-trunk/extensions/libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 6.8.1.99, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 6.8.1.99, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 I guess the problem isn't from libGLcore.so itself. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Error compiling FlightGear
On May 3, 2005 02:39 am, Melchior FRANZ wrote: > > WARNING: ssgSGIHeader::: Failed to open > > '/usr/local/FlightGear/share/FlightGear/Textures/Sky/cl_cumulus.rgb' for > > reading. > > So? What's with theses files? Are you sure you have these, at this weird > path? But anyway ... Those files aren't there. As for the directory, yes, it is correct. You have no idea how much time I spent on poking around until I found out that the base-package should reside in there (as opposed to what the documentry said). =P I think it may have to do with the fact that I placed FlightGear under /usr/local/FlightGear instead of /usr/local. > > X Error of failed request: GLXUnsupportedPrivateRequest > > It is quite likely that the X server dynamically links against the wrong > libGL, just like fgfs. So I'd stay with the easier debugging target now, > and that's fgfs. Also, I don't know if the X server even needs OpenGL. I > doesn't have to run in HW accelerated mode (Xrender extension) to run 3D > apps with HW acceleration. (Disclaimer: I'm no X expert. :-) Okay. > I suppose that there's still an old libGL around that's used instead of the > new one. Try this: > >$ ldd `which fgfs` > > and check if all the relevant libraries do really use what libs you think > it *should* use. I have this here: > >... >libglut.so.3 => /usr/X11R6/lib/libglut.so.3 (0x4005a000) >libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x40082000) >libGL.so.1 => /usr/lib/libGL.so.1 (0x40114000) >... >libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40537000) >libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0x40c28000) > > and I'm happy with it. Running strace again and checking the lib paths > is also a good idea. Obviously, I don't have the libnvidia-tls.so.1 symlink. Other than that, everything else is similar to your's except libGLcore.so.1 -- it's not even listed. As for strace, FlightGear is looking at everywhere for libGL.so except in the right directory. I don't get it. =/ I am going to recompile FlightGear again tomorrow morning. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in theHimalayas
On May 3, 2005 01:52 pm, Paul Furber wrote: > Thanks - I did have it the right way around when running it - just typed > it in wrong in the previous e-mail. I've just downloaded the e080n20 > tileset and there now seems to be a large peak of ~29 000ft on the > China/Nepal border :] Some screenshots will be nice. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling FlightGear
On May 3, 2005 09:59 am, Arnt Karlsen wrote: > On Mon, 2 May 2005 23:17:39 -0400, Ampere wrote in message > > <[EMAIL PROTECTED]>: > > I have gone through the entire log. > > ..put it on a web server and post the url to it here. http://www.students.yorku.ca/~ampere/Xorg.0.log http://www.students.yorku.ca/~ampere/xorg.conf Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling FlightGear
> ..according to your log, it _is_ loaded between (II) LoadModule: "glx" > and (II) Loading extension GLX , despite the first loading failure. Yes, I see that too. It is being loaded as a submodule. [EMAIL PROTECTED]:~$ dpkg -S /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.so xserver-xfree86-dri-trunk: /usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.so xserver-xfree86-dri-trunk: /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.so [EMAIL PROTECTED]:~$ COLUMNS=120 dpkg -l | grep X.Org ii xlibmesa-dri 6.8.2-10 Mesa 3D graphics library modules [X.Org] ii xlibmesa-gl 6.8.2-10 Mesa 3D graphics library [X.Org] ii xlibmesa-gl-dev 6.8.2-10 Mesa 3D graphics library development files [X.Org] ii xlibmesa-glu 6.8.2-10 Mesa OpenGL utility library [X.Org] ii xlibmesa-glu-dev 6.8.2-10 Mesa OpenGL utility library development files [X.Org] [EMAIL PROTECTED]:~$ COLUMNS=120 dpkg -l | grep XFree86 ii xfree86-common 4.3.0.dfsg.1-12 X Window System (XFree86) infrastructure ii xserver-xfree86 4.3.0.dfsg.1-12.0.1 the XFree86 X server [EMAIL PROTECTED]:~$ libGL_DEBUG=verbose glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20041207 x86/MMX/SSE2 TCL OpenGL version string: 1.3 Mesa 6.3 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_S3_s3tc glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc
Re: [Flightgear-devel] Error compiling FlightGear
Thanks for all the help guys. It seems the depth-rate setting was preventing FlightGear to run. After I have changed the depth from 24-bits to 16-bits, FlightGear runs fine. Unfortunately, enemy-territory slows down even more under 16-bits (not that it is playable anyway). As far as hardware acceleration goes, even though it is available, I really don't think those 3D applications are using it. glxgears is running at ~500 fps. I once managed to get the same amount of fps with no direct rendering, so... =/ Also, the framerates of glxgears seem to be extremely dependent on CPU cycles. I have seen it falls to 9 while the system is accessing something from the harddrive. I don't know whether that is normal though. One thing for sure is that glxgears is taking up CPU cycles. Check: http://www.students.yorku.ca/~ampere/cpuload.jpg Ignoring the first and last peak, the description for the CPU Load graph is: Idle -> glxgears running -> idle Anyway, The 'Failed to load module "GLcore" ' is still here, and so the search to why continues. =/ Would you mind sending me your xorg.conf, Arnt? Thanks, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3d city
On May 5, 2005 08:30 am, Giles Robertson wrote: > The major problem is modelling the city anyway; if you are prepared to > model NY accurately, then feel free - but be aware of the size of the > task, and if you already have the data, tell us where it is :) > > Giles Robertson Too bad the Manhattan model up on sell at Turbosquid has been taking down. Otherwise, a couple hundreds dollars would get us the model we need. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: opening window & splash screen
On May 4, 2005 05:40 pm, Melchior FRANZ wrote: > I thought about a progress bar, or better: an info line that says: > "initializing navigation data", "initializing airport data", etc. > That entertains people a lot and makes the startup time appear shorter. > > m. Just an idea: would it be possible to throw in some random and irrelevent messages in there as well, such as "tying pilot's shoelase", so people can have a laugh or two while waiting for FlightGear to load? > Lazyness is the way to go here, I'd suggest. Or binary file formats. I like binary file formats. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
The new 3D clouds are great! However, on the ground, I noticed the clouds seem a bit grainy. They are also darker than they should be. On closer observation, I see this: http://www.students.yorku.ca/~ampere/fgfs-screen-006.jpg Does anybody know I am seeing these artifacts? Would my use of 16-bits depth be one of the contributions? Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
On May 5, 2005 06:32 pm, Curtis L. Olson wrote: > They look a lot nicer in 24bit depth, there are some issues, but I > assume this is still a work in progress so I'll wait a bit longer before > I start complaining. :-) hehe. I see why you would think I am complaining. I missed the word "why" in one of my sentences. =P What I meant to say was: Does anybody know _why_ I am seeing these artifacts? Would my use of 16-bits depth be one of the contributions? Sorry if I cause any misunderstanding. =P Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
On May 6, 2005 10:06 am, Karsten Krispin wrote: > If you bank your plane the clouds will move in the opposite direction as > you turn > to - They move to the right or to the left depending whether you turn > left or right. (And I'am not talking about the movements through the > wind ;)). It is strange to discribe this - The easiest way would be you try > it your self :) - You'll immediatly recognize what I mean. - Just do some > hard and fast turns. Also it looks like if they get zoomed in or zoomed > out... I know what you mean. It seems you can never go inside the cloud. Perhaps visibility should be decreased to a few meters when one is inside the clouds? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Model: AC130-H
On May 10, 2005 03:59 am, Erik Hofman wrote: > To be clear, are you talking about a 3d model or about a flight dynamics > model (which describes how the aircraft should handle)? > > In case of the latter, there is already a (beta) C130 configuration file > for JSBSim available: > > http://cvs.sourceforge.net/viewcvs.py/jsbsim/JSBSim/aircraft/C130/ > > Erik Isn't Innis working on one as well? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Model: AC130-H
On May 10, 2005 01:48 pm, Harald JOHNSEN wrote: > I'd like to work on a plane too in my spare time (model, animation or > panel). > Do we know of some aircraft from cvs that need some work or is it better > to start a new one ? > > Harald. There are quite a few aircrafts in the cvs that need to be work on. I think it will be better if those planes get comleted first before having more semi-finished aircrafts. If your skill lies in programming, you might want to think about working on Nasal scripts for us modellers. I for one, will welcome that. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Model: AC130-H
On May 11, 2005 09:47 am, Ben Morrison wrote: > How long would you say it would take you to create this model, > just so I have an idea. It depends. How much data have you gathered? The more data you have, the less guess work you have to do, and the quicker you can get the model to look right. Experience also contributes, of course. My first model took me more than a month to get right. > I was also wondering if taking a plane close to > the size of a C130 and modifying it to look like a C130 is an option? Kitbashing? May be. But aircrafts rarely share parts. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Model: AC130-H
On May 11, 2005 01:35 pm, Ben Morrison wrote: > When you refer to data, are you referring to the dimensions of the > aircraft? Sort of, but "dimensions of parts on the aircraft" would be a better description. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] swap chase views
What kind of graphic cards do you have?! Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Web site problems?
> Just an information: Linux + Mozilla no problem Konqueror has no problem either. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On May 15, 2005 10:21 am, Melchior FRANZ wrote: > PS: TODO for 1.0: > - perfect weather (almost) done > - per-wheel gound reactions YASim: done; JSBSim: :-( UIUC: bah! > - help system (a bit unsophisticated, but) done > - a/c switchable at runtime hmm :-/ Let me add to this list. =) - The bottom of the clouds above a city at night should have a faint orange glow. The thicker the clouds, the brighter the glow should be. - Moonlight. - The global ambient should be blue. This should be most noticeable when at dawn and dust when the sun is not visible. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
> For those who are currious: > > http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-screen-016.jpg > > Erik It looks good, although usually there's only one bolt. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On May 17, 2005 01:54 pm, Paul Surgeon wrote: > Only 20% of strikes consist of one stroke (pulse along the same path) while > the other 80% are two or more strokes. > The mean stroke occurrence is five to six and the maximum has been measured > at twenty-five. > > Strikes can last up to 1 second in duration and I saw such a lighting storm > a couple of months ago. I see. Would scheduling one lighting bolt per frame for a duration of five frames make the effect more realistic? =P Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On May 18, 2005 06:25 am, Steve Hosgood wrote: > The original glider had no instruments of course. For this model, I've > pinched the instruments panel from the Schweizer 2-33 that was already > in Flightgear. I did this to give me some idea of airspeed, to > compensate for not having the wind in my face whilst flying! You can always use sound as an indication of speed. ;-) Record the sound of wind ripping across the microphone, and replay this with different volume when the glider is flying. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] MD-11 is slow (was FlightGear startup time)
On May 24, 2005 07:45 am, Melchior FRANZ wrote: > for (3): use as few textures as possible; You can: > - edit material.xml and let it share textures (only one wood > texture) or start fgfs in the desert :-) > - use aircraft with few and small textures (hint: avoid the MD-11 > :-) - scale down textures > But all that makes the scenery uglier and is probably not what you > want. The gain is probably not worth it, anyway. Sorry about that. =( I will do an update soon, which will include: * down sizing the textures * eliminating the LOD's * directories and files restructuring * landing gear animations * a more "complete" cockpit model. * possibility of a better 3D model for the aircraft But first, I will need to finish these monstrous scripts for the A380. Your help in speeding up this process will be most welcome though. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On May 26, 2005 04:32 pm, Andy Ross wrote: > > Would it be possible to have a compiled form stroed on disk, which > > is automatically regenerated on startup of FGFS based on rules > > similar to make. If the ASCII version is newer than the compiled > > version, rebuild the compiled version. > > Sorry, but that sounds dumb. Wouldn't it be a better idea to try to > figure out why it is slow in the first place before making all our > configuration files non-editable? How so? Python does it by compiling a new *.pyc everytime there is a change to the associated *.py file. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On May 26, 2005 01:43 pm, Ampere K. Hardraade wrote: > How so? Python does it by compiling a new *.pyc everytime there is a > change to the associated *.py file. > > > > Ampere Beside, you don't compile Flightgear everytime you run it. You compile Flightgear when there is a change in the source. Compiling scripts on a as-needed basis would be similar, if not the same. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .ac file format
On May 29, 2005 12:16 pm, Gerard ROBIN wrote: > If your whishes are: using GMAX > In windows environment (is valuable with linux + wine too) > It is possible to convert from .gmax to .ac If GMax native file can work in Flightgear directly, then there wouldn't be need for conversions. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Cannot put character with ascii code 0 into the property tree
I have been experimenting with Nasal lately. The focus of my experiment is to have one Nasal script communicate with another using the property tree. In an attempt of communication, a Nasal script of mine placed the following stream of characters to the property tree: 1, 80, 194, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 127, 0, 0, 6, 207, 128, 174, 239, 0, 0, 127, 0, 0, 6, 207, 128, 174, 239, 0, 0, 0, 0, 0, 20, 0, 2, 0, 15, 0, 0, 0, 0 Unfortunately, the property tree cuts off everything after the first character \0. My questions are: Why doesn't the property tree except the \0 character? Is there any chance that it can accept the \0 character? Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cannot put character with ascii code 0 into the property tree
> I don';t think the property tree cares much, I expect this is a string > handling "problem" in Nasal because it is written in C(++). Actually, it is the otherway around: Nasal doesn't care, while the property tree does. I hope Nasal stays that way. > Oh wait, Ampere is actually trying to put "\0" etc into a string (or > default) property? That can't be done. You could however define the > properties to be of type double or int and assign "property=0". Well, last evening I experimented with putting information one byte at a time to the property tree as opposed to putting a string, but I don't see this as a way out because it is not scalable. The running time can reach thousands, if not tens of thousands easily. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cannot put character with ascii code 0 into the property tree
On June 1, 2005 04:23 pm, Andy Ross wrote:
> My guess is that the property tree doesn't care either, and it's
> simply the output routine that is truncating the string due to the
> embedded null. Is there some sample code to exhibit the problem?
>
> Andy
Do you mean something like this?
# ** ** ** ** **
str = chr(01) ~ chr(80) ~ chr(194) ~ chr(0) ~ chr(0) ~ chr(0);
node = props.globals.getNode("/experiment", 1);
print ("Writing the following characters to the property tree:");
for (i = 0; i < size(str); i = i + 1){
print(strc(str, i));
}
node.setValue(str);
tmp = node.getValue();
print ("The following characters were retrieved from the property tree:");
for (j = 0; j < size(tmp); j = j + 1){
print(strc(tmp, j));
}
# ** ** ** ** **
Ampere
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cannot put character with ascii code 0 into the property tree
On June 1, 2005 07:02 pm, Andy Ross wrote: > This isn't fixable without relatively major surgery, so for now I > think you're stuck. Maybe Melchior's suggestion of storing your data > in Nasal space is the best one for the moment. Okay. I think I came up with something using Nasal. =) Objects in Nasal seems to get passed/assigned by reference. So I wrote myself a medium object, passed two I/O buffers to it, and have the buffers swap by the medium periodically by calling the function settimer(medium.update, 0). It seems to work, and seems to be better than using the property tree as well. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft models
On June 3, 2005 12:33 pm, Jon Berndt wrote: > I'm interested in tallying up the existing JSBSim aircraft flight models. > I'd be interested to know (either by posting here or sending me a personal > email) which aircraft you have modeled. It seems there are a lot of models > floating around that are not really known about (albeit in various states > of fidelity) - and perhaps not for release, but I'd still like to know > about them. Both the MD11 and the A380 use JSBSim. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airports Data + Zoom + SHIPs
Perhaps seperating land and water would be the next thing on the agenda? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] My thoughts regarding aircraft system or "hardware" simulations
A propsal regarding the generalization of aircraft systems Abstract: Currently, the electrical system seems to be the only system that can be configured by the user. Other systems are either fully hardcoded into Flightgear, or have yet to be modelled. Since dedication to code that simulates such thing as hydraulic or bleed air system isn't going to appear anytime soon, it is my opinion that it might be a good idea to modify the electrical system into a more abstract/generic form. The idea is to make the simulation of other aircraft systems easier. Of course, instead of being hardcoded into Flightgear, unique behaviours to individual system may have to make user-configurable somehow. Problems: Why should the electrical system be made generic? Take the electrical system, hydraulic system, and bleed air system as the examples. All these system are basically different forms of moving something from point A, through medium B, to point C. That battery on the electrical system is similar in function to the hydraulic fluid accumlator, or the air tank in the bleed air system. In fact, they can all be modelled using a Queue... or a Stack, storing a table of values. The electrical bus, hydraulic and bleed air lines are similar in functions, and its implementation can be as simple as *b = &a; (in C's terms). Because there are so many commonalities between these systems, it would be wise to combine them into one piece of code, and implements the behaviours of a specific system using extensions. Possible benfitis: By generalizing systems, a framework is created which will make life easier for other developers who wish to create new aircraft systems. I guess what I am trying to advocate here is OOP for aircraft systems. To make this approach more flexible and worthwhile, Nasal should be allowed to define the system's behaviour. This way, Nasal scripts can be served as templates in the creation of new aircraft systems for Flightgear, or allow non-programmers like me to create new aircraft system without having to use C++. Let's say I want to define a datalink system between avionics, all I would have to do is treat the Queues as the buffers and write strings into them. Possible issues: As with any other dependency, there is a danger that changes to the generic system may break all the aircraft systems. Therefore, should this proposal gets implemented, the generic system would need to be implmented in such a way to keep possible changes to the minimium. Also, having everything based on a single framework would create single point failure. Hence, the generic system would need to be very robust, or more than one implementation would be needed. Conclusion: My intention is to bring attention to the simulation of aircraft systems, and start some discussions among developers. I hope someone will take this proposal into consideration. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
On June 9, 2005 05:28 pm, Martin Spott wrote: > I'm curious if it is possible to 'simply' define the whole model as a > "contact point" and let the OpenGL subsystem detect terrain collision. > This would require some return channel from the OpenGL system back > to the application and I have no idea if this is achievable, > > Martin. If it is achievable, how will that work for aircrafts that use seperated models, such as the A380? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
hmm... flying undersea. Isn't that what submarines do? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
On June 11, 2005 06:07 pm, Oliver C. wrote: > I agree with the terrain. > But i think that airplanes need to be able to sink after they crash. :) > So the best way would be to make the terrain and watersurfaces independent > from each other. > This would also have some positive side effects because it would allow us > to animate waves of the sea and make the sea transparent, especially at the > coastlines. > For this, it would also be a good idea to display the ground under the sea > and merge the terrain with the ground under the sea instead of with the sea > level. > This would also allows us to include submarines, like someone above in this > thread said. > > > Best Regards, > Oliver C. I like that idea. It would be nice to fly along the coast of a tropical island, look down and be able to see the white sand under the water... or flying above a coral reef and see the corals on the sea floor. =) Seperating land and water will also allow tidal effects to be modelled. As for underwater exploration, I for one wouldn't mind taking the UFO down and see some underwater landmarks such as the Titanic. hehe. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New developer
On June 11, 2005 03:06 pm, [EMAIL PROTECTED] wrote: > Hi All! > > I would like to contribute to flightgear project... I'm interested in > converting italian scenery from MSFS (I already know that it is not > possible to distribute stuff that it isn't GPL compatible) and creating an > MD-82 model for flightgear... > > 1) Does someone is already working on that? I believe someone had been working on the Boeing 717/MD-82, but the author of that aircraft has some real life issues to take care of, and gave(?) the model to someone else to continue. There is no word regarding that particular aircraft ever since. As for scenery, we seem to be lacking developers in that area. ;-) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New developer
On June 13, 2005 12:42 am, Manuel Bessler wrote: > The stuff is still here: > 1. http://cockpit.varxec.de/fgfs/fgfs_717-200.tar.bz2 > 2. http://cockpit.varxec.de/fgfs/fgfs_717-200_71.blend.gz They are not there. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
Water isn't the only other material that should be modelled. There are also other materials such as grass and soil. Right now, I can take a short cut across the grass in any airport without concern, and these sort of behaviours should bring some consequences. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 3D model FDM reference point
On June 13, 2005 02:40 pm, Innis Cunningham wrote: > Hi Martin > > Martin Spott writes > > >Hello, just an informal note > >To my impression the A380 needs an offset vector for the FDM reference > >point in order to make it rotate around its CG. Could the author > >confirm ? > > This is correct I was going to move the whole 3D model in AC3D after > everything > was finished but that has not happened yet.If you want to provide offsets > for it > feel free > > >Cheers, > > Martin. > > Cheers > Innis If there is going to be changes to the A380-set.xml, please wait until Curt has uploaded my updates first, which should be anytime now... On the subject of finishing the A380, is there any kind soul who wouldn't mind helping me to come up with a few Nasal scripts? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On June 6, 2005 06:44 pm, Josh Babcock wrote: > Well, take a look at what I put in, no wires, though I could do that > with about zero trouble if people think it would add to the model. > Personally I don't think it would add much though. Also I think the bar > I put in there is pretty sensible. > Now who's going to do the castle :) > > Happy escapes! > > Josh Well, here's a map if it helps: http://en.wikipedia.org/wiki/Image:Colditzcampmap.jpg As to escapes, prisoners are "encouraged" to do so. If they get caught, they won't get shot. Read about the escape stories here: http://en.wikipedia.org/wiki/Colditz_Castle Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: "old" 3d clouds code
On June 15, 2005 04:05 am, Erik Hofman wrote: > There where a few reports that one would need at least 24/32 bit colors > to get it working (although it used to work with 16 bits in previous > versions). It used to work with 16 bits. After I upgraded from the latest CVS version, the 3D clouds don't work in 16 bits anymore. When I switched to 24/32 bits, I get this error messages: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 41 Current serial number in output stream: 42 =( Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: "old" 3d clouds code
On June 16, 2005 01:18 am, Mathias Fröhlich wrote: > Look into that. I believed that this was integrated somehow. That looks > phantastic and does things like that. > Watch the video on the bottom of that page. > >Greetings > > Mathias I have just finished watching the video. Yes, the clouds do interact with the airflow. I see the potential for it to be used not only for eye candy, but to simulate realistic weather effects. In my opinion, the code for the old 3D clouds should definately be kept in the CVS. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: "old" 3d clouds code
On June 16, 2005 01:24 am, Mathias Fröhlich wrote: > I tried with 24. > On a recent Mesa CVS r200 driver I get the same error message. > With the r200 driver from my distro it just crashes. > > I have short circuted that with an unconditional false return in line 461 > in RenderTexture.cpp. > The crash happens in the first call to glXCreateGLXPbufferSGIX a few lines > later. > > Greetings > > Mathias Is the error fixable? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: "old" 3d clouds code
On June 17, 2005 01:17 am, Mathias Fröhlich wrote: > On Donnerstag 16 Juni 2005 21:12, Ampere K. Hardraade wrote: > > > I have short circuted that with an unconditional false return in line > > > 461 in RenderTexture.cpp. > > > The crash happens in the first call to glXCreateGLXPbufferSGIX a few > > > lines later. > > > > Is the error fixable? > > I just started the debugger to see where it happens. > Dont' know so far. > > Are we sure that the pbuffer extension initialization/usage is entierly > correct? > > Greetings Mathias I am also seeing these errors when I am running FlightGear under 16 bits color: RenderTexture Error: Couldn't find a suitable pixel format. WARNING: ssgLoadAC: Failed to open '/usr/local/FlightGear/share/FlightGear/Aircraft/c172r/Models/c172-dpm.ac' for reading This is with the latest version of the CVS. Could the problems be related? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] getting the best perfo with FG
On June 17, 2005 03:17 am, BONNEVILLE David wrote: > Hi again people, > > problem solved ! :D > > I've just recompiled the latest cvs of plib, simgear and FlightGear, turned > on the threads flags, and now I have a FG running up to 60 fps (i have > forced the synchro with the vertical refresh). > > Cuold somebody explain me the way to tune FG options to get the best perfo > ? visibility, threads, dynamic terrain loading ... > > Thanks > > David Well, 30 fps isn't that bad in my opinion, considering I only have 15 fps if I am lucky. What other options did you use beside vertical synchronization? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] need help for convertion(importing) fron MSFS into Flightgear
On June 17, 2005 10:53 am, yue xianf wrote: > hi Gerard: > > Thanks lot, I found the hope to finish my project. > > Clifford What aircraft is it that you intent to port over? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On June 17, 2005 03:02 pm, Harald JOHNSEN wrote: > I have started to add some volumetric shadows in Flightgear. > It uses the standard stencil method to count shadow volume (let me know > if you want an implementation > without stencil, it can also be done with the alpha buffer). > A few days ago I thought that it would be overkill for the processor or > the graphic card to add this effect, but with > a few optimisations the impact on frame rate - while still noticeable - > is acceptable. > I can render the Concorde with a debug build so all is not lost if your > computer is not 10 years old. > Some screenshots here : > http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html > Let me know what you think of that. > > nb: only the AC is casting shadows atm, I still need to verify how are > handled other objects in the scene graph > (tile objects, AI objects, etc). > > Harald. Finally, there is shadow in FlightGear. =) Couple of questions: Do the authors of the aircrafts have to specify the objects that can cast shadow, or is it all done automatically? On aircrafts that have multiple level of details, such as the MD-11, majority of the objects are made invisible. If these invisible objects cast shadow as well, it might produce huge overhead. Is your code intelligent enough to leave these invisible objects out of the calculations? Unlike other aircrafts where everthing is put into a single mesh file, the A380 model is split into multiple files to allow meshes of different format to work together. Does shadow work on the A380? Finally, what is the minimal graphic card requirment to be able to see shadow? Thanks, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Forgive my annoyance, but here are a few more questions. =) First of all, I am seeing a potential problem when the sun is below the horizon (during dawn and dusk) and doesn't cast any shadow onto the ground. Does your code handle this special case at the moment? If so, how? Secondly, do objects with illumination (such as the flame from the f-16's exhaust) disrupt shadows? Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? Thanks, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Getting an airport fixed
If I found a lot of inaccuracies in an airport and want to get them fixed, who should I talk to? Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting an airport fixed
On June 19, 2005 04:10 pm, Gerard Robin wrote: > I have the same request LFPO is wrong: --> take off point beside the > runway > > Thanks > -- > Gerard For me, it is the LFBO. 14L/32R is a dirt runway, and there is no taxiway connected to the ends of 14R/32L. =/ I notice another airport around the area that also have a dirt runway. Seems like there are quite a few problems with airports in France. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Some opinions, detail analysis, and ideas related to FlightGear
Hello, This thread in the FlightGear section on Avsim is getting pretty informative. The thread started out as a form of feature request, but it eventually focus on the funding issue of FlightGear. Please check it out: http://forums.avsim.net/dcboard.php?az=show_topic&forum=198&topic_id=855&mode=full Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Le Bourget / Paris Air Show / Aero 2005
On June 19, 2005 06:22 pm, Frederic Bouvier wrote: > I had the chance to get a pass for Le Bourget 2005. Unfortunately, the > only day I could go was a rainy day. > > Nevertheless, I took pictures that you can see here > http://frbouvi.free.fr/photos/yappa-ng/index.php?album=Aviation%2FLeBourget >2005%2F . > > Some may interest aircraft designers. > > -Fred Airbus was providing live stream every day at 14:00 GMT+2. I woke up early to watch it on Thrusday morning (GMT -5 here). It was pretty impressive, not to mention that those jet fighters are LOUD! =) There is one video on Airbus' website that shows the A380's cockpit while the aircraft was performing. Those who are interested should check it out. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: carb-heat
On June 20, 2005 09:58 am, Curtis L. Olson wrote: > Melchior FRANZ wrote: > >fgfs developers aren't only pedantic, but also lazy. :-) > > > > Errr ... busy. :-) > > Curt. Or chaotic. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lights was: Shadows
On June 20, 2005 12:53 pm, Harald JOHNSEN wrote: > You are a genius, forget my previous reply. > We can't lighten pixels from the framebuffer because of the low > precision (8 bits) but we can of course darken them. > Algo (works better at full night) : > 1) render the scene and all non emissive geometry with a 'day' ambient term > 2) render all lights (or emissive geometry) and update the stencil > buffer ( stencil := 1) > 3) render a quad on screen to darken everything where stencil == 0 > > with 1 & 3 the scenery goes dark/black as usual > with 2 the scenery in light stay illuminated > Its quasi free, simple, support a million (fake) spot light ;) > > Harald. Nice! We will finally be able to see at night in FlightGear. =) On June 20, 2005 04:15 pm, Josh Babcock wrote: > I think the shadows are cool, but I think that being able to have > spotlights is just awesome. Perhaps we should start thinking about how > this will be implemented from the modeler's perspective. > ... > A really cool bit of eye candy would be to make a visible cone of light > that would change intensity based on how much moisture is in the air. > That can even produce blinding reflection in a heavy fog, which IMO > would be very cool to see. It would be great to see two beams stabbing > out in front of a landing jetliner! To increase flexibility, I think it would be a good idea to allow the modeller to specify the light volume. This way, the spot light can take the shape of a star if the modeller desires. So, to light the interior of a hangar, all there would need is a box that is as big as the hangar itself. For normal spot light, the modeller can specify a cone as the light volume. For a linear light source, the modeller can use a triangular prism to outline the space being lit. The modeller-specified object can also be served to control the parameters of the spot light. Obviously, the width of the beam would be proportional the the thickness of the object. In addition to using XML to control the brightness of the light source, the size of the object itself can be used to calculate the brightness factor. The color of the object would be a contributing factor to the color of the light source. The modeller-specified object should not be hidden by default, however. The modeller would have to make the object hidden manually by setting the object's opacity to zero. An object that is not totally transparent will be self illuminating. This way, places such as hangar interiors can be served as prop and acted as the light volume simultaneously. > I guess it would still be up to the modeler to provide Melchior style > billboards so that the actual light would be visible. I'm not sure how > one would deal with the directionality of the light though. One can > also add lights for the nav lights. Imagine being able to look out the > cockpit window and see your anti-collision lights reflecting off the ramp! Yes. The same idea occured to me while I was coming home on the bus. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Just for fun ...
On June 20, 2005 05:01 pm, Melchior FRANZ wrote: > http://members.aon.at/mfranz/fgfs_gui.jpg [80 kB] > > m. Oh boy! A bo105 with a cloaking device! =P How much chance do you think I have if I want to sneak up on some Romulans? hehe... Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Just for fun ...
On June 21, 2005 01:39 am, Melchior FRANZ wrote: > I like these title bars -- they combine two necessary elements (title, > exit button) -- and thus safe some vertical space. Hey, will the dialog shade if I double click on the title bar? =P Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] (OT) River Visual Rwy 19 DCA
On June 20, 2005 10:11 pm, Dave Culp wrote: > Here's some guy flying the River Visual to Runway 19 at DCA. This is a > 19MB avi file. I'll leave this up for a couple days, then remove > it to put the hangar back up. > > http://home.comcast.net/~davidculp2/dca_visual_19.AVI > > > Dave You can upload it to www.flightlevel350.net Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lights was: Shadows
On June 21, 2005 03:34 am, Roman Grigoriev wrote: > to Harald JOHNSEN: > spot lights in fgfs I had 3 years ago. they worked on vertex program and > registercombiners but everyone afraid of vertex programs and multitexturing > You can see some screens here http://fgfs.narod.ru In my opinion, if the code exists already, then it shouldn't be wasted. Just a couple of questions: What is the performance hit as a percentage of the highest framerate? What is the minimal graphic card requirment? Would you mind explaining how your code works? I understand that you have a framework for this. Would you mind explaining to me what this framework is and how it works? How flexible is this particular code? For example, can the inside of the hangar be lit? Can the light be cast on to other objects beside the ground? Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New aircraft ideas ?
On June 24, 2005 11:39 am, Arnt Karlsen wrote: > > Got an idea for a new aircraft (not airplane) you'd like to try ? > > http://www.dodsbir.net/Topics/Default.asp > > Topic: A05-208 > > ..concerns "semiballistic 40-105 mm munitions with enhanced lethality > capable of striking targets of opportunity along the modifiable > ballistic trajectory." > > ..I'd like to see such devices make full use of the 4 Geneva Conventions > to save lives and instead maximize combat damage to the enemy, as > wounded men are about 4 to 5 times more expensive to any military force > than dead men. A successful small arms femur shot takes a year to heal > back into combatworthy status. Agreed. If I have any new idea, I will certainly not submit it to any Department of Offense. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Turn Coordinator is out ==> c172r and others
On June 25, 2005 08:20 pm, Gerard Robin wrote: > Beware instrument failure ! > C172r and others aircraft have a turn coordinator out of order :=( > seems to be property: > /instrumentation/turn-indicator/indicated-turn-rate I notice it as well, but I thought my CVS version is outdated, so I didn't mention it. Beside the turn coordinator, everything on the radio stack seems to be out as well. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear got killed (seems like memory problem)
Hello, I uninstalled Xorg and went back to XFree today so I could do some testing with XFree and the latest FlightGear CVS. I got the following outputs from FlightGear: RenderTexture Error: Couldn't find a suitable pixel format. WARNING: ssgLoadAC: Failed to open '/usr/local/FlightGear/share/FlightGear/Aircraft/c172r/Models/c172-dpm.ac' for reading WARNING: ssgLoadAC: Failed to open '/usr/local/FlightGear/share/FlightGear/Aircraft/pa28-161/Models/pa28-161.ac' for reading Killed ^ From what I can tell, there seems to be some memory management problems. FlightGear first slows down at an exponential rate, then freeze, and finally got shut down by the Operating System. I am using Debian Linux. [EMAIL PROTECTED]:~$ uname -a Linux localhost 2.6.10 #1 Wed Jun 15 04:47:56 EDT 2005 i686 GNU/Linux ...with XFree86 4.3.0 Graphic card: ATI 9200SE (PCI version) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] About 3D Clouds
After removing Xorg and upgrading XFree to the latest CVS version, I am finally able to use FlightGear in 24-bits color. However, I am still not seeing any 3D clouds. I have an ATI Radeon 9200SE graphic card. I remember 3D Clouds was working fine when it (the code for the new 3D Clouds) was first added the code to the CVS. I haven't been able to get the 3D clouds to show up in subsequent updates. What am I missing? Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
On June 27, 2005 04:26 am, Erik Hofman wrote: > Harald at one point added a check to make sure the RenderTexture context > was actually available. It almost looks like this was a bit too drastic. > > Erik Interesting. I happen to keep getting an error regarding RenderTextuer context -- in both 16bits and 24bits color. IRQ's not enabled, falling back to usleeps: 11 1 169 Disabling HW TCL support WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. RenderTexture Error: Couldn't find a suitable pixel format. < WARNING: ssgLoadAC: Failed to open '/usr/local/FlightGear/share/FlightGear/Aircraft/c172r/Models/c172-dpm.ac' for reading WARNING: ssgLoadAC: Failed to open '/usr/local/FlightGear/share/FlightGear/Aircraft/pa28-161/Models/pa28-161.ac' for reading I have done "apt-get install --reinstall" for XFree and Mesa already, but the error still presists. I have begun doing searches on Google for this error, but I haven't find anything helpful so far. Do you guys know what cause this error? Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On June 25, 2005 01:49 pm, Harald JOHNSEN wrote: > Paul Kahler wrote: > >Oh does that sound like a bad hack. What happens to objects that have > >specular highlights? Would the illumination be as if the sun were > >shining rather than the spotlight? Lighting is important, but this > >doesn't seem like it's physically correct at all. OTOH, fake lighting is > >better than no lighting ;-) > > > >Paul > > > > > > You are right, this is totaly incorrect lighting. For correct lighting > and correct specular we should use an > Opengl light for each light source. The problem is that opengl is sill > slow for spot lights, and there can be > more than 100 light around an airport. Of course opengl can not handle > more than 8 lights in hardware > (and I am not sure that it is still realtime on lot of machines) so we > would have to switch ogl lights > depending on the position of objects or ground geometry... a bit > overkill I think. > Perhaps can we use a real ogl light for the aircraft landing light and > fake light for the airport lights, > and since the view is centered on the aircraft the hack could be good > enought. > > Harald. I am probably getting this wrong, but from my prespective, the purpose of specular reflection seems to give the object a waxy (and reflective) surface. Perhaps specular reflections for these fake spot lights can be done using enviromental or reflective maps? Then again, I don't see having no specular reflection for these fake lights will be much of a problem. In the air, there won't be any object that can give you specular reflections. On the ground, with the user's plane being the only aircrafts, and the lack of terminals for airports, the situation would be the same as in the air. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..multi-X trick ideas, was: FlightGear got killed (seems like memory problem)
On June 27, 2005 01:15 am, Arnt Karlsen wrote: > ..a tad drastic, for FG development, you could simply set up two > runlevels, say runlevel 2 to run xorg and runlevel 3 to run XFree, > these 2 runlevels could othervise be identical. > > ..to push this further, you could also use runlevel 4 to run both at the > same time, say xorg on /dev/tty7 as :0 and XFree on /dev/tty8 as :1, > hopping between them is then [ctrl]+[alt]+[F7] and [ctrl]+[alt]+[F8]. > Etc. Interesting. I didn't know one can use both XFree and Xorg at the sametime. In anycase, this is way out of my league. =P Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Regarding buildings (was Shadows)
On June 27, 2005 05:00 pm, Frederic Bouvier wrote: > In the first, an oracle building cast its shadow on another one > http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg > > If I go forward a bit, the shadow disappear : > http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg Would it make sense to give the building a base (such as a parking lot) for future models? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On June 27, 2005 05:40 pm, Curtis L. Olson wrote: > Yes, that's a tough one ... think about what happens when the sun is low > in the sky ... an object that casts a shadow on the current view could > be *way* outside the view frustum. I don't really understand how > shadows work, but you'd almost have to do a complete rerendering > (ssgCullandDraw) of the world from the sun's perspective to get this > right ... I'm guessing that may be a bit expensive??? > > Curt. May be a history of the shadows can be kept, so the object that casts the shadow is not drawn, the shadow will still stay for a while? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
