Re: [Flightgear-devel] Billboard animation
David Megginson wrote: Erik Hofman writes: Norm: which do you think would be more efficient for a forest of, say, 500 trees? I would say, billboarded spherical trees handled as particles. I don't understand 'particles'. Particles (in OpenGL) are a large number of polygons which have the same characteristics. By updating the particles in one shot you should be able to get the best perfomance out of the hardware. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Billboard animation
Erik Hofman writes: Particles (in OpenGL) are a large number of polygons which have the same characteristics. By updating the particles in one shot you should be able to get the best perfomance out of the hardware. Do you mean that all of the billboarded trees would be under the same transformation? That wouldn't work, because each tree has to turn to a slightly different angle to face the camera, and each has to rotate about its own centrepoint. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spinning propellers and framerates.
Simon, I haven't noticed any performance degradation (similar to what you describe) on nVidia hardware. It sounds like maybe the radeon driver does ok drawing alpha quads (or quads with an alpha component) from back to front, but perhaps there is an inefficiency in the pipeline when the alpha quads get obscured by something in front. That doesn't make a lot of sense to me because the driver it seems would have to do *less* work in the latter case. But, perhaps there is some subtle issue in the card/driver that is causing this? Curt. Simon Fowler writes: While playing around with different versions of the DRI Radeon drivers today, I noticed an odd thing: with the standard c172 model in the external view, if I look at the model from head on, I get 20-25 fps, whereas if I look from a perspective where part of the spinning propeller disk is obscured by the airframe, I get ~6 fps. I get the same 6 fps all the time when I run with the 3d model. I'm just curious whether this same effect is seen by anyone else, particularly people running NVidia hardware - if it's a driver issue, I'll take this to the DRI devel list. If it's something to do with FlightGear or plib, it'd be nice if there was some way to deal with this - being limited to around 6 fps makes the 3d models almost unusable by me, and I don't have the money to upgrade to faster hardware . . . For the record, I have a K7 550, a Radeon QD (32 MB), Linux 2.4.19-pre8, XFree86 4.2.0, and the latest DRI CVS tree, along with the latest CVS trees from FlightGear, SimGear and plib. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Realistic cloud rendering
At 09:47 PM 5/4/2002 -0500, you wrote: http://www.cs.unc.edu/~harrism/SkyWorks/ If any of our developers out there are looking for their next project to work on, this could be a really interesting one to look at. This will probably be a fairly good sized chunk to bite off, but if we can get this running in FlightGear it would be really cool. *Lot's* of geek points for who ever can pull this off. :-) Well... It's interesting: I started some initial cloud stuff a while ago, which still is the basis for our current cloud setup I believe. About six months ago, Erik Hofman sent the url for Mark Harris' paper to the list, and I found out that this Guy actually works at UNC and lives in Chapel Hill, while in the meantime, I moved to Duke and live in Durham, NC, which is about 12 miles Chapel Hill. Unfortunately, my time is still very limited, but I'll have a look at the source later today and see what it's like. It would be an interesting opportunity to work with the guy, especially because now that we're virtually living around the corner. Regards, Durk Durk Talsma, Center for Cognitive Neurosciences, Duke University, LSRC Bldg, Box 90999, Durham, NC 27708-0999 Why quote somebody else? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] windows binary
Marcio: I've been trying to compile the latest version, but I've encountered some problems linking against the opengl library. I'm trying to compile it in windows XP and using: gcc version 2.95.3-5. Opengl 1.1.0-6 SimGear 0.0.18 Plib-1.4.2 No problems compiling simgear and plib. Has anybody seen this error before ? I've checked the undefined references and they are in the libraries indeed. Thanks in advance Francisco Making all in Main make[2]: Entering directory `/cygdrive/d/fg/FlightGear-0.7.10/src/Main' c++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -enable-stdcall-fixup -L/usr/local/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o viewer.o viewmgr.o location.o ../../src/Air craft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FD M/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Time/libTime.a ../../src/WeatherCM/libWeatherCM.a ../../src/Input/libInput.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibnet -lplibssg -lplibsg -lmk4 -lz -lopengl32 -lpthread -lm -lglut32 -lglu32 -lglaux -lglui -lgluix -lplibsl -lplibsm -lwinmm -lplibul -lm /usr/local/lib/libsgscreen.a(screen-dump.o): In function `sg_glDumpWindow(char const *, int, int)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:84: undefined reference to `glFinish' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:86: undefined reference to `glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trEndTile(_TRctx *)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:404: undefined reference to`glFlush' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:418: undefined reference to`glReadPixels' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:437: undefined reference to`glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trRasterPos3f(_TRctx *, float,float, float)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:468: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:476: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:477: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:484: undefined reference to`gluProject' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:495: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:500: undefined reference to`glBitmap' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/cygdrive/d/fg/FlightGear-0.7.10/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/d/fg/FlightGear-0.7.10/src' make: *** [all-recursive] Error 1 -Original Message- From: Marcio Shimoda [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 05, 2002 12:08 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] windows binary Hi! Does anybody have the windows .exe of the current FlightGear CVS? All the best, Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] windows binary
It seems to be caused by a recent change in CygWin. Here is Norman's answer to the same question: Norman Vine wrote (on Tue, 23 Apr 2002): The opengl libs got moved to / lib / w32api / directory don't ask me why ? I just made a link to these in my '/ lib' dirrectory you could also just copy them there or add a -mwindows flag to the gcc link options IMHO None of the above are the right solution but I have quit pushing for what IMHO is the 'right' way of doing things in Open Source projects when one can easily change things in your local copy If-I-wanted-to-be-borg-I-wouldn't-need-a-compiler'ly yrs Norman [EMAIL PROTECTED] wrote: I've been trying to compile the latest version, but I've encountered some problems linking against the opengl library. ... Has anybody seen this error before ? ... /usr/local/lib/libsgscreen.a(screen-dump.o): In function `sg_glDumpWindow(char const *, int, int)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:84: undefined reference to `glFinish' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:86: undefined reference to `glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trEndTile(_TRctx *)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:404: undefined reference to`glFlush' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:418: undefined reference to`glReadPixels' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:437: undefined reference to`glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trRasterPos3f(_TRctx *, float,float, float)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:468: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:476: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:477: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:484: undefined reference to`gluProject' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:495: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:500: undefined reference to`glBitmap' collect2: ld returned 1 exit status ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] windows binary
I've tried both and I've got the same error. Has anyone been able to compile the latest version on win32/cygwin platform ? Francisco -Original Message- From: Julian Foad [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 2:28 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] windows binary It seems to be caused by a recent change in CygWin. Here is Norman's answer to the same question: Norman Vine wrote (on Tue, 23 Apr 2002): The opengl libs got moved to / lib / w32api / directory don't ask me why ? I just made a link to these in my '/ lib' dirrectory you could also just copy them there or add a -mwindows flag to the gcc link options IMHO None of the above are the right solution but I have quit pushing for what IMHO is the 'right' way of doing things in Open Source projects when one can easily change things in your local copy If-I-wanted-to-be-borg-I-wouldn't-need-a-compiler'ly yrs Norman [EMAIL PROTECTED] wrote: I've been trying to compile the latest version, but I've encountered some problems linking against the opengl library. .. Has anybody seen this error before ? .. /usr/local/lib/libsgscreen.a(screen-dump.o): In function `sg_glDumpWindow(char const *, int, int)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:84: undefined reference to `glFinish' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:86: undefined reference to `glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trEndTile(_TRctx *)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:404: undefined reference to`glFlush' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:418: undefined reference to`glReadPixels' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:437: undefined reference to`glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trRasterPos3f(_TRctx *, float,float, float)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:468: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:476: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:477: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:484: undefined reference to`gluProject' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:495: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:500: undefined reference to`glBitmap' collect2: ld returned 1 exit status ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] windows binary
[EMAIL PROTECTED] writes: I've tried both and I've got the same error. Has anyone been able to compile the latest version on win32/cygwin platform ? YES My guess is that you do not have the Cygwin OpenGL link libraries installed. Try reruning the Cygwin setup program and make sure that the OpenGL distribution is checked for installation ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Gusting winds
In real life, I've been having a hard time with my landings on the
circuit ('suck' might be the most appropriate term).
Practicing with FlightGear has helped a bit, but it didn't really feel
right. When I'm landing a real C172, there are almost always wind
gusts, turbulence, and other nasty things to screw up my nicely-set-up
approach -- the nose will suddenly shoot 5 degrees up or down, the
plane will roll 10 degrees for no reason, and a sudden gust will push
me far off the runway track at the worst times.
The FDMs are going to be handling turbulence, but we need to deal with
gusting in FlightGear itself. I've checked in a first attempt at gust
support, using the following properties to set it up:
/environment/params/base-wind-speed-kt
/environment/params/gust-wind-speed-kt
The gust function is simplistic, but at least it is unpredictable, and
I find that it messes up my landings just like to real thing. To get
winds from 270 @ 15kt gusting to 25kt, try
fgfs --wind=270@15 --prop:/environment/params/gust-wind-speed-kt=25
To use this, you'll need to configure --with-new-environment.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gusting winds
In real life, I've been having a hard time with my landings on the
circuit ('suck' might be the most appropriate term).
Minor suggestions ...
(1) Ask to have a night lesson. The air will be a lot smoother and
you can practice things like roundout and ground effect operations.
(2) Wait a second before correcting for a wind gust effect (if feasible)
because many smaller transients occur in equal and opposite pairs.
fgfs --wind=270@15 --prop:/environment/params/gust-wind-speed-kt=25
Great! I'll try it. Thanks.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gusting winds
David Megginson [EMAIL PROTECTED] said: The gust function is simplistic, but at least it is unpredictable, and I find that it messes up my landings just like to real thing. To get winds from 270 @ 15kt gusting to 25kt, try fgfs --wind=270@15 --prop:/environment/params/gust-wind-speed-kt=25 Very interesting. I'll try it out. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gusting winds
fgfs --wind=270@15 --prop:/environment/params/gust-wind-speed-kt=25 I can't try it right now; the 3D panel is broken for me and the 2D view environment sets the clip planes to be unusable for 16 bit depth buffering when I get close to ground effect. Disconcerting ... I'll try later again. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gusting winds
Alex Perry [EMAIL PROTECTED] said: fgfs --wind=270@15 --prop:/environment/params/gust-wind-speed-kt=25 I can't try it right now; the 3D panel is broken for me and the 2D view environment sets the clip planes to be unusable for 16 bit depth buffering when I get close to ground effect. Disconcerting ... I'll try later again. How old was your previous build? Is Base up to date? The near plane is set in preferences.xml now and should be the same as it has been in 2D view. I'm using a voodoo3 with a 16bit depth buffer, but haven't updated for a day or two. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Reset Problem part 2
Ooops! This just happen if you copy FlightGear\src\include\config.h.msvc6 to config.h - Original Message - From: Marcio Shimoda [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 02, 2002 7:37 PM Subject: Reset Problem part 2 Hey, the problem of the 2nd reset is back! I reset twice and FG crashes! Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RFC: New tile caching scheme and viewer/tilemgr changes
Currently I'm testing a new scheme for caching tiles. See the changes listed below for details on how it is different. The goal is to stabilize the new viewer code's interaction with the flightgear scenery code. As many have observed there are numerous problems that have come up since incorporating the configurable views, including significantly the tower views. The previous viewer code updated scenery parameters based on the position of view that was always tied directly to the position of the FDM (longitude/latitude/altitude). The problems arose because the new viewer is specifies alternate postions, for example the tower occupies a static (non-moving) position. The problems corrected with the change include: 1) Switching to tower view shows the proper tiles (rather than a plain blue screen) even if the aircraft has flown hundreds of miles away. 2) The skydome, clouds, etc now render correctly. 3) In CVS Ground lights sometimes jump momentarily when flying over a new tile. 4) The FDM maintains correct altitude (doesn't get screwed up by FlightGear code) even if the view is on the tower view. Note that this is achieved in current CVS by fudging the view position to the aircraft position for tower views (thus contributing to the cause of problem #1). The changes I'm making include the following: 1) Tile Entries are purged from cache based on age in milliseconds, rather than distance from a view position as previously done. This is necessary because the tower position(s) and aircraft position(s) are multiple rather than a single position that can be considered the center of cached tiles. Tiles are timestamped when created and when accessed (but not every time rendered of course). 2) If the FDM position and View position differ (as in Tower view) the tile manager is updated twice per frame. Generally this update is fairly lightweight and doesn't affect performance noticably. Note that when in tower view, the longitude/latitude/altitude of the view doesn't change, so this keeps the load light. 3) Removed fudged behavior in the viewer and fixed a couple bugs found in the viewer class. 4) A triggered event causes the view to refresh (update the timestamps) on its tiles once every 15 seconds. Again this is a pretty lightweight, updating this frequently prevents tile reloading from getting triggered. 5) Tile cache size is doubled over what it was in order to maintain smoothness in making frequent view switches. This will need to be re-evaluated and optimized when we go to multiple instances of FDM (so that we don't need to increase another 50% for a second FDM for example). On my system I'm seeing a 10-15% increase in memory footprint. So far (on my system 750mhz (100 Bus) and voodoo3) the frame rate seems to be about the same as it was before these changes. I'll need to do more testing to be sure and we'll have to get some feedback from others. In any case the changes seem to be necessary to ensure the integrity of the multiple views. This is requiring a lot of testing, both with threads and not, so it'll be another day or two before I'll be submitting patches. If anyone sees problems with this approach for what they are doing, let me know. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: New tile caching scheme and viewer/tilemgr changes
Jim Wilson writes: So far (on my system 750mhz (100 Bus) and voodoo3) the frame rate seems to be about the same as it was before these changes. FWIW A Voodoo3 is so 'fill bound' that I doubt if anything not putting pixels on the screen would would have 'much' affect on your frame rate. This is espescially true if you are either displaying a model and or any of the panel. I had a reawakening to the 'fill rate issue' when I ran the SIM at 800x600 on my geForce2 and suddenly the Panel was only a 10% instead of a 40% hit and toggling the sky textures made NO difference in frame rate !! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
