On Wed, 2003-01-22 at 16:31, Curtis L. Olson wrote: > 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. Yes but there are techniques to sustain high poly count, none of which would be easy to integrate in flightgear. One great demo of high poly count terrain rendering with LOD is the chunked LOD demo from Thatcher Ulrich (http://sourceforge.net/projects/tu-testbed). This demo is optimized to death for NVIDIA cards though and is well worth checking if you have one. > > 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. > On my system using 512Mb RAM + 512Mb swap and putting fog very far it quickly filled the swap and finished by crashing flightgear. > 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. > I disabled it with --disable-clouds for the profiling > 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 _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
