There are a couple things to bear in mind. The further you push out the visibility, the more tiles you have to load into memory to cover the expanded visible area. These tiles consume memory.
The more area you are drawing, the more polygons you are rendering. This puts a bigger load on your cpu and graphics card per frame which will typically cause your fps to drop. FlightGear has an internal tile cache which is larger than the size of visible tiles. So as you fly, memory usage will grow until the internal tile cache fills up. It's typically with this type of simulation/game application for the graphical scene rendering to be 90-95% of the overall application work load. Try turning off the cloud layers and see if that reduces the amount of time spent drawing the sky ... cloud layers are expensive becuase they cover a lot of screen reale state and because they are blended into the background they burn heavily into your pixel fill budget. Regards, Curt. Michael Pujos writes: > I did some profiling of flightgear because I'd like to > optimize performance of the terrain culling + rendering which is bad > when terrain fog is far, that mean when there is a lot to render and > cull in the scene graph. > Performance is fine with the default fog distance though but it gets > very bad when you put it farther with keys Z/z. > When fog is very far or disabled it can go below 20fps and become very > jerky. > Something I noticed also is that flightgear mem usage keep growing and > growing over time and it is much more apparent and quick when loading a > lot of tiles when fog is far. I had it to the point it filled quickly > the swap and flightgear was killed by the kernel. > I think most of the bad performance with lots of polygon implied by > far fog comes from the scene graph from ssg. Another case of bad > performance is terrain generated from 3 arcsec DEM with good resolution > when the terrain is moutains or hills like Hell's Canyon > (ftp://ftp.flightgear.org/pub/fgfs/Scenery/w120n40.tar.gz). > > > > Test system: > > Athlon 1900+ XP > 512Mb RAM > Geforce 4 TI 4200 > latest NVIDIA binary drivers 41.91 > > FlightGear compiled with: > > - gcc 2.95.3 > - FlightGear CVS > - SimGear CVS > - plib 1.6.0 > - FlighGear and libs compiled with -g -pg > - no threaded tile loader support and no optimizations (-02) > > Test run with options: > > --disable-sound > --enable-auto-coordination > --aircraft=ufo > --start-date-lat=2002:01:10:11:00:00 > --disable-clouds > > 800x600x32 windowed > ufo at max speed during 83 seconds running time. > > > all percentages are in % of total execution time > > (part of the profile is in the attached file) > > - 67.8% in fgRenderFrame() [2] > > - 64.4% is from ssgCullAndDraw() [3] divided in: > > - 12.9% : ssgCullAndDraw() called by SGSky::preDraw() that is > only used when skyblend is enabled (--enable-skyblend). It > is enabled by default > - 51.5% : ssgCullAndDraw() of the whole scene graph (terrain > + objects) > > or > > - 53.3% culling > - 9.1 % drawing at the leaves of the scene graph > (ssgVtxTable::draw(void) [18]) > > > > > - 20.7% in FGTileMgr::update() [8] most of which is due to > FGHitList::IntersectBranch(ssgBranch *, double (*)[3], double *, > double *) [13] > > > Some observations: > > - most of the time is spent in ssg and sg functions > - I'm not sure the culling take 53.3% of total time because the > profile data is quite hard sometimes to understand because of cycles > but culling still takes a lot of time. > - drawing the blended sky shouldn't be taking 12.9% of total time i'll > see if I can fix that > - A fair amount of total time (14.1%) is passed in > sgFrustum::contains(sgSphere const *) const [15] the half of which > (7.05 %) is in the function itself and not its children (it might be > inlined function though). > > > -- 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
