Re: [Flightgear-devel] Performance analysis
David Megginson wrote: Hoyt A. Fleming writes: > There was a discussion quite a while back about decreasing the > terrain level of detail (LOD) as the terrain distance increased so > that frame rates could be increased. Do you know if that LOD > concept looked promising for FG? Continuous LOD is probably a non-starter for us -- at least, the implementations I've read about assume a regular elevation grid with a simple texture mapped on top, and that doesn't describe the way we model scenery. If someone wants to try that, you'll probably want to write it from scratch and then we can try plumbing it into FlightGear. For static LOD, we could create multiple versions of each tile at different resolutions for different distances. In that case, as Curt has pointed out, the challenge is edge meshing. Let's say that we have four LOD versions for each tile, and that we have an algorithm that guarantees no more than a single-step resolution jump between tiles. Any given edge will still have to be able to mesh up with another tile of the same resolution, one higher, or one lower, so we'll have, probably, over a hundred versions of each tile. All the best, David Check out http://www.graphitx.com/demos/RecursMesh.zip on graphitx.com for a neat LOD demo (sorry, directx only...) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Performance analysis
> Yes I agree it would need to be done from scratch. I'm considering > giving it a go. Another aspect of LOD rendering is you can't use OpenGL > lighting since geometry is always changing, so lightmaps must be used > for lighting. Vertex morphing is required so the terrain looks not > changing. In case you are interested, there is all the pieces for a view-dependent LOD engine in the GTS library (http://gts.sf.net). It is not restricted to regular (e.g. quadtree) data but can deal with arbitary 3D triangulated surfaces (which would allow for the current approach for road/rivers etc... in flightgear). It would even be conceivable to include buildings etc... as part of the LOD terrain (i.e. the same engine would deal with the LOD for both terrains and buildings). I don't think it would be too difficult to integrate this into flightgear for a first stage demo which would only display a limited area (an area which would fit in main memory). Tha main issue to be solved is the paging/caching mechanism for larger (global) data sets. There is litterature on this however and I could give you references if you are interested. I don't have personally much time to invest on this but I would be happy to help on the GTS side of things. Stephane ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Performance analysis
Falcon4 is a good example of a sim that uses a combination of progressive meshing and LOD. Mike > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Megginson > Sent: January 23, 2003 8:21 AM > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] Performance analysis > > > Per Liedman writes: > > > Not saying it's easy, not saying it's the right way to go, and > > *absolutely* not volunteering to code one for FGFS, but MSFS2002 > > definitely has CLOD which works for the whole globe, and yes - > MSFS2002 > > *is* a flight sim ;-) It has some quite visible "pops" and isn't > > perfect, but they achieve high frame rates and there are no real > > problems pushing the far clip plane way out. Just proof that it *is* > > possible, given a huge amount of well paid programmers! :-) > > If it has pops, how is it CLOD? There must be some discrete steps in > there somewhere. > > > 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Michael Basler writes: > > > > My take is MS just screwed up something in the calculation/conversion of > European scenery. Neither a problem with raw data nor with the general > procedure. Just my guess. Note that for both GLOBE and VMAP0 the data for each country was provided by the national authority concerned. So the data *may* be 'intentionally' off by 200 meters between the 2 data sets yet still be within the 'precision' of the data set. Another possibility is that when rasterized the vmap0 data is referenced differently then vmap0 for Germany then if a different point within the pixel is used as the location value compared to what is used in the GLOBE data set this would explain a 'systematic' error. for example in one possible scenario since cos(50*) < rough latitude of germany > = ~ .6, the actual east west coverage of a pixel of GLOBE is ~600 meters and if developers of the Scenery use the center of the pixel instead of the lowerleft corner of the pixel as the location of that data set then everything will be shifted ~300 meters The above is just for illustration and may not be actual fact but illustrates how easy it is to get a systematic error of ~250 meters when dealing with data that only has 'precision' of 1:1,000,000 or 1 km per pixel also note that 250m is well within the 'noise' of the data and no amount of overzooming will ever make it more 'precise' Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Performance analysis
David, > If everything in MSFS is off by the same amount, then it may be a > problem with Microsoft's spheroid code (or lack thereof). I know that > Norm did a lot of work to get the WGS84 stuff right in FlightGear, and > I'm amazed by how often roads and rivers *do* end up at the bottoms of > valleys and canyons, given the different resolutions of the data. > > If everything in MSFS is off by different amounts (i.e. sometimes a > road is in the right place, sometimes it's 200m to the north, etc.) > then we're probably dealing with a resolution problem in the data. I > think that vmap0 is nominally World Aeronautical Chart (WAC) > resolution, 1:1,000,000; things will be off by a couple of hundred > meters sometimes. I think, neither nor. I didn't make a close investigation, but I US/Canadian data seem to be (all?) correct (within a reasonable precision). The surrounding of Vancouver has all canyons right (within a certain presision) even after adding a better mesh. I know, too, that all (as far as I know) German river/road data plus those of at least some other European countries are off by around 200 m. All by the same amount. There's even an excellent commercial add-on Scenery for Southern Germany available including a high resolution mesh from a famous third-party developer since a few weeks. Even they were not able to correct rivers and roads now but refer to a patch to be released "sometime later". Some German airports are misplaced a bit, too, btw. Makes for funny effects where add-on developers use the correct data. My take is MS just screwed up something in the calculation/conversion of European scenery. Neither a problem with raw data nor with the general procedure. Just my guess. Beta testing is mostly done in the US. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Performance analysis
Michael Basler writes: > That's well possible. That artifact is obviously not present in the original > data. It's just that all the stuff like rivers, roads etc. is systematically > shifted by 200 m or so. Quite annoying in narrow canyons. BTW, the Grand > Canyon and otehr US canyons do not suffer from this but, as I said, several > German valleys do. If everything in MSFS is off by the same amount, then it may be a problem with Microsoft's spheroid code (or lack thereof). I know that Norm did a lot of work to get the WGS84 stuff right in FlightGear, and I'm amazed by how often roads and rivers *do* end up at the bottoms of valleys and canyons, given the different resolutions of the data. If everything in MSFS is off by different amounts (i.e. sometimes a road is in the right place, sometimes it's 200m to the north, etc.) then we're probably dealing with a resolution problem in the data. I think that vmap0 is nominally World Aeronautical Chart (WAC) resolution, 1:1,000,000; things will be off by a couple of hundred meters sometimes. 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] Performance analysis
David Luff writes: > I haven't done any rigorous back to back viewing, but taking off > from Nottingham the roads, rivers and urban areas look uncannily > identical in layout to Flightgear's (the Riley scenery). I > wouldn't be at all surprised to here they'd used the same data, at > least for this area. vmap0 is both low-res and free, an unbeatable combination for default world-wide coverage. 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] Performance analysis
Dave > Hmm, maybe they've got their co-ordinate systems mixed up? From memory > (which I'm not trusting any more!), I seem to recall that a typical > difference between OSGB36 lat & lon and WGS84 lat & lon is in the order of > 200m. Perhaps something along those lines has happened with their data > somewhere. The road, stream, lake and coastline data are Digital Chart of the World/VMap0 with very few exceptions, and the mesh data appears to be based on GLOBE. I don't think there's been any confusion of co-ordinate systems - they've not used any local data other than in the immediate vicinity of Heathrow in the UK, and presumably at similar 'feature' locations elsewhere in the product. There are two main LOD schemes in operation. One is the ability to use MIP-Mapped textures in scenery and objects, and the other is the mesh. Meshes are compiled with a given LOD, but if more than one is available for the same area, FS2002 will use the most appropriate one for the viewing distance. It also seems to have the capability to recalculate a lower LOD mesh from a higher one by downsampling if necessary. There's noticable popping not just of textures (especially with scenery), but also of the mesh, which I personally find more disturbing. Mally --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.445 / Virus Database: 250 - Release Date: 21/01/03 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Performance analysis
On 1/23/03 at 4:10 PM [EMAIL PROTECTED] wrote: >Dave, > >> >are available) rivers will flow downhill etc. > >Sorry. Uphill. You guessed it ;-) Sorry - couldn't resist :-) >That's well possible. That artifact is obviously not present in the >original >data. It's just that all the stuff like rivers, roads etc. is >systematically >shifted by 200 m or so. Quite annoying in narrow canyons. BTW, the Grand >Canyon and otehr US canyons do not suffer from this but, as I said, several >German valleys do. Hmm, maybe they've got their co-ordinate systems mixed up? From memory (which I'm not trusting any more!), I seem to recall that a typical difference between OSGB36 lat & lon and WGS84 lat & lon is in the order of 200m. Perhaps something along those lines has happened with their data somewhere. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Performance analysis
Dave, > >are available) rivers will flow downhill etc. Sorry. Uphill. You guessed it ;-) > I haven't done any rigorous back to back viewing, but taking off from > Nottingham the roads, rivers and urban areas look uncannily identical in > layout to Flightgear's (the Riley scenery). I wouldn't be at all > surprised > to here they'd used the same data, at least for this area. That's well possible. That artifact is obviously not present in the original data. It's just that all the stuff like rivers, roads etc. is systematically shifted by 200 m or so. Quite annoying in narrow canyons. BTW, the Grand Canyon and otehr US canyons do not suffer from this but, as I said, several German valleys do. Unfortunately all the roads/rivers stuff is poorly documented in FS2002 (contrary to some other stuff), and it seems to be hard to correct. Sincerely, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
David Megginson wrote: > Per Liedman writes: > > > Not saying it's easy, not saying it's the right way to go, and > > *absolutely* not volunteering to code one for FGFS, but MSFS2002 > > definitely has CLOD which works for the whole globe, and yes - MSFS2002 > > *is* a flight sim ;-) It has some quite visible "pops" and isn't > > perfect, but they achieve high frame rates and there are no real > > problems pushing the far clip plane way out. Just proof that it *is* > > possible, given a huge amount of well paid programmers! :-) > > If it has pops, how is it CLOD? There must be some discrete steps in > there somewhere. You can set the level of detail you want it to generate through a slider, so it's definitely not precalculated stuff. However, I guess they recalculate the mesh only once in a while, so you can see quite clearly when it regenerates the data and create finer detail, remove detail, etc. I don't know what the exact definition of CLOD is, but in my mind it's a LOD mechanism which doesn't do its calculations off-line, and in that case MSFS2002 qualifies. BTW I'm quite sure I've seen "pops" in CLOD demos too - or have I just misunderstood the term "pop"? What I mean is that you can see when the algo adds or removes detail. Most demos I've seen are quite good and it isn't always that obvious, in MSFS' case, it's very obvious. Regards, Per Liedman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Performance analysis
On 1/23/03 at 3:01 PM [EMAIL PROTECTED] wrote: >BTW, there are certains areas (i.e. in Germay) where streets/rivers >obviously are misplaced. This means if you buy a better high res mesh >(whcih >are available) rivers will flow downhill etc. And your problem is? ;-)) I haven't done any rigorous back to back viewing, but taking off from Nottingham the roads, rivers and urban areas look uncannily identical in layout to Flightgear's (the Riley scenery). I wouldn't be at all surprised to here they'd used the same data, at least for this area. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Per Liedman writes: > Not saying it's easy, not saying it's the right way to go, and > *absolutely* not volunteering to code one for FGFS, but MSFS2002 > definitely has CLOD which works for the whole globe, and yes - MSFS2002 > *is* a flight sim ;-) It has some quite visible "pops" and isn't > perfect, but they achieve high frame rates and there are no real > problems pushing the far clip plane way out. Just proof that it *is* > possible, given a huge amount of well paid programmers! :-) If it has pops, how is it CLOD? There must be some discrete steps in there somewhere. 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] Performance analysis
Curt, > Does FS2002 ship with the entire world or do you need to download > portions as add ons as various 3rd party groups make them? FS200 comes with the whole World in the box. This includes all the main rivers, lakes, streets (in Germany all Federal streets), coast lines, all cities (down to perhaps 1000 inhabitants) and a basic mesh (differs I guess, there are low res areas and high res areas). Resolution of low resolution mesh may be 300 m (just an estimate, experts may correct me). It comes with basic land use data which are quite rough but nonetheless give a quite decent view as borders between tiles are invisible and there are no noticeable repetitions. You can buy/download add-on land use data, which are small (based on default textures, they just tell forest is here and fields are there.) The default textures provided with FS2002 are not photo-real but synthetic (but very decent IMHO). BTW, there are certains areas (i.e. in Germay) where streets/rivers obviously are misplaced. This means if you buy a better high res mesh (whcih are available) rivers will flow downhill etc. This is a well-known flaw. Quite funny. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
> Per Liedman writes: > > Curtis L. Olson wrote: > > > The CLOD techniques are really slick, and I've seen some cool demos. > > > However, I personally so far (and maybe something exists, I dunno) > > > have not seen anyone pull all the pieces of this together and handle > > > all the issues/needs required by a flight sim. > > > > Not saying it's easy, not saying it's the right way to go, and > > *absolutely* not volunteering to code one for FGFS, but MSFS2002 > > definitely has CLOD which works for the whole globe, and yes - MSFS2002 > > *is* a flight sim ;-) It has some quite visible "pops" and isn't > > perfect, but they achieve high frame rates and there are no real > > problems pushing the far clip plane way out. Just proof that it *is* > > possible, given a huge amount of well paid programmers! :-) > > Does FS2002 ship with the entire world or do you need to download > portions as add ons as various 3rd party groups make them? It has default scenery for the whole world, quality ranging from ok to very good, but you can also download add-on scenery from 3rd party groups - I haven't tried that a lot, though. It should also be noted that I haven't stress tested MSFS2002, things like flying over the poles and so on. Over all though, I must say that MSFS2002 appears quite solid, even though it hurts to say such a thing about something that came out of Redmond :-) Regards, Per Liedman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Per Liedman writes: > Curtis L. Olson wrote: > > The CLOD techniques are really slick, and I've seen some cool demos. > > However, I personally so far (and maybe something exists, I dunno) > > have not seen anyone pull all the pieces of this together and handle > > all the issues/needs required by a flight sim. > > Not saying it's easy, not saying it's the right way to go, and > *absolutely* not volunteering to code one for FGFS, but MSFS2002 > definitely has CLOD which works for the whole globe, and yes - MSFS2002 > *is* a flight sim ;-) It has some quite visible "pops" and isn't > perfect, but they achieve high frame rates and there are no real > problems pushing the far clip plane way out. Just proof that it *is* > possible, given a huge amount of well paid programmers! :-) Does FS2002 ship with the entire world or do you need to download portions as add ons as various 3rd party groups make them? Curt. -- 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] Performance analysis
Curtis L. Olson wrote: The CLOD techniques are really slick, and I've seen some cool demos. However, I personally so far (and maybe something exists, I dunno) have not seen anyone pull all the pieces of this together and handle all the issues/needs required by a flight sim. Not saying it's easy, not saying it's the right way to go, and *absolutely* not volunteering to code one for FGFS, but MSFS2002 definitely has CLOD which works for the whole globe, and yes - MSFS2002 *is* a flight sim ;-) It has some quite visible "pops" and isn't perfect, but they achieve high frame rates and there are no real problems pushing the far clip plane way out. Just proof that it *is* possible, given a huge amount of well paid programmers! :-) Best regards, Per Liedman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
David Luff writes: > Its 10 meter per pixel. Ouch -- no wonder all the screenshots are at high altitude. 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] Performance analysis
Jon Berndt writes: > > > From: Norman Vine > > > > FWIW - for comparison purposes here is a non-overzoomed > > 10m pixel image of an area I am quite familiar with :-) > > Very nice. I zoomed way in. > > BTW, you have a thread hanging off your collar in the back. Nice shirt. You have some powerful glasses :-) To see the laundry flapping on the line you need to use this interface http://maps.massgis.state.ma.us/MassGISColorOrthos/viewer.htm note this is *free* 0.5m pixel color imagery http://www.state.ma.us/mgis/colororthos2001.htm Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
On 1/22/03 at 10:09 PM Norman Vine wrote: >David Luff writes: >> >Hard to tell but it looks like their scenery is cutoff at ~15 miles >> >and you can't really tell from jpegs and don't know what LOD >> >is being shown in the 'snaps' but I would guess that this is >> >several < 2 - 4 > meter per pixel imagery >> > >> >> Its 10 meter per pixel. > >OK - > >it looked a litle better then that but I guess it is over zoomed Whoops, your judgement was right and my memory was wrong! I emailed the author some time ago asking and I've found my archived reply: "It's very approximately 4.7m/pixel" I was wrong about the website as well - that's jpegs at 2m per pixel, it's a magazine cover DVD with the whole country on that's at 4m per pixel (jpegs). Ack - must make mental note not to assume my memory works anymore :-( Nice area BTW - do you live in the displayed area? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Performance analysis
> From: Norman Vine > > FWIW - for comparison purposes here is a non-overzoomed > 10m pixel image of an area I am quite familiar with :-) Very nice. I zoomed way in. BTW, you have a thread hanging off your collar in the back. Nice shirt. ;-) smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Performance analysis
David Luff writes: > On 1/22/03 at 9:20 PM Norman Vine wrote: > > Yes, it appears to have created quite a stir among the MSFS users here in > England. I'll almost certainly buy a copy myself once Northern England > comes out. > > > > >Hard to tell but it looks like their scenery is cutoff at ~15 miles > >and you can't really tell from jpegs and don't know what LOD > >is being shown in the 'snaps' but I would guess that this is > >several < 2 - 4 > meter per pixel imagery > > > > Its 10 meter per pixel. OK - it looked a litle better then that but I guess it is over zoomed FWIW - for comparison purposes here is a non-overzoomed 10m pixel image of an area I am quite familiar with :-) http://coast.mit.edu/draw-ortho.cgi?action=zoom10&layer=ortho&dwidth=500&dheight=500&image=273806&layer=ortho&zoom=5&old_zoom=5&widt h=500&height=500&middlex=266&middley=312 Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
On 1/22/03 at 9:20 PM Norman Vine wrote: >Very nice :-) Yes, it appears to have created quite a stir among the MSFS users here in England. I'll almost certainly buy a copy myself once Northern England comes out. > >Hard to tell but it looks like their scenery is cutoff at ~15 miles >and you can't really tell from jpegs and don't know what LOD >is being shown in the 'snaps' but I would guess that this is >several < 2 - 4 > meter per pixel imagery > Its 10 meter per pixel. The photo's for the whole of England are on the web at http://www.getmapping.com at 4m per pixel jpegs, although the jpeg quality is pretty low. The images can be bought as bitmaps at 25cm per pixel for those who want a *real* data storage and management headache, although you'd probably need to be a real millionare to afford a decent area at that resolution. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Jon Stockill writes: > > Take a look at this: > > http://www.visualflight.co.uk/photoscenery/intro.htm > > It appears a company has decided to tackle the whole of the UK in FS2002. > > Just to give you some idea of the data involved - the first volume they > released, which is just the east and southeast takes up 1.7GB > > Looking at the screenshots though, it is *very* impressive. Very nice :-) Hard to tell but it looks like their scenery is cutoff at ~15 miles and you can't really tell from jpegs and don't know what LOD is being shown in the 'snaps' but I would guess that this is several < 2 - 4 > meter per pixel imagery Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
- Original Message - From: "Jon Stockill" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 23, 2003 1:22 AM Subject: Re: [Flightgear-devel] Performance analysis > On Wed, 22 Jan 2003, Norman Vine wrote: > > > FWIW It has always seemed pretty big to me and I definately am not > > ready to implement 'photo texture' for the planet, except for selected > > inserts which btw I am doing with the above data set as a base :-) > > < this is not publically available yet however > > > Take a look at this: > > http://www.visualflight.co.uk/photoscenery/intro.htm > > It appears a company has decided to tackle the whole of the UK in FS2002. > > Just to give you some idea of the data involved - the first volume they > released, which is just the east and southeast takes up 1.7GB Most of which are texture I believe > > Looking at the screenshots though, it is *very* impressive. > agreed ! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
On Wed, 22 Jan 2003, Norman Vine wrote: > FWIW It has always seemed pretty big to me and I definately am not > ready to implement 'photo texture' for the planet, except for selected > inserts which btw I am doing with the above data set as a base :-) > < this is not publically available yet however > Take a look at this: http://www.visualflight.co.uk/photoscenery/intro.htm It appears a company has decided to tackle the whole of the UK in FS2002. Just to give you some idea of the data involved - the first volume they released, which is just the east and southeast takes up 1.7GB Looking at the screenshots though, it is *very* impressive. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Curtis L. Olson writes: > > Norman Vine writes: > > Here is some *excellent* global data for a start on this > > http://earthobservatory.nasa.gov/Newsroom/BlueMarble/ > > > > WARNING THE COMPLETE SET OF DATA FILES IS HUGE > > and will require an additional download of approx 70 MB > > for the minimal installation and approx 300 meg for the > > full data set, which uncompresses to ~2.0 GB > > > > Note this data is the same resolution as the gtopo30 DEM, 1 km pixels > > at 'best' LOD, and as distributed has 5 levels of texture LOD which is > > texture mapped onto an unperturbed sphere, this is suitable for distances > > of >50 miles or so > > > That does look cool. So 1km resolution of the earth is about 2.0 GB > uncompressed, which means if we wanted 1m resolution of the earth we'd > be looking at about 2000 TB, or 2 of whatever the next unit up is. Yes the data requirments are staggering and prohibitive with todays machines but ... I think we could get away with substantially less then 1 meter data for the *vast* majority of the earth. for starters over 50% of the earth is water so we could easily substitute a couple of textures and are data requirements are cut in half Then we really only need 1 meter data where you are allowed to be close enough to the ground to see 1 meter i.e. the immediate airport vicinity so lets cut the data requirement in half again. This is still a staggering amount of data though > And you still wouldn't have nearly the resolution you'd need to do > runway markings and taxiway lines and that sort of thing. Runways and such could be inserts > Our planet still seems pretty big sometimes. :-) FWIW It has always seemed pretty big to me and I definately am not ready to implement 'photo texture' for the planet, except for selected inserts which btw I am doing with the above data set as a base :-) < this is not publically available yet however > Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Norman Vine writes: > Here is some *excellent* global data for a start on this > http://earthobservatory.nasa.gov/Newsroom/BlueMarble/ > > Here is the home page of a viewer > http://www.andesengineering.com/BlueMarbleViewer/ > > an *unsupported* beta native Win32 port lives at > http://rockfish.net/~nhv/osg/bmv_mingw.tgz > > WARNING THE COMPLETE SET OF DATA FILES IS HUGE > and will require an additional download of approx 70 MB > for the minimal installation and approx 300 meg for the > full data set, which uncompresses to ~2.0 GB > > Note this data is the same resolution as the gtopo30 DEM, 1 km pixels > at 'best' LOD, and as distributed has 5 levels of texture LOD which is > texture mapped onto an unperturbed sphere, this is suitable for distances > of >50 miles or so > > IMHO If you have got the bandwidth > and want a truly *awsome* virtual globe > This is a *must* have That does look cool. So 1km resolution of the earth is about 2.0 GB uncompressed, which means if we wanted 1m resolution of the earth we'd be looking at about 2000 TB, or 2 of whatever the next unit up is. Assuming you can get a 120GB IDE HD for $120, you'd need to buy about 17,000 of these units to store the whole thing. And that's not taking into consideration the hardware that these drives plug into. Assuming you could plug 4 of these drives into a single PC, you'd need to also purchase about 4200 PC's. Then you'd have to network and power all of this. You'd also need to find enough space, and most importantly, you'd have to have a massive cooling system to keep everything from burning up. And you still wouldn't have nearly the resolution you'd need to do runway markings and taxiway lines and that sort of thing. Our planet still seems pretty big sometimes. :-) Curt. -- 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] Performance analysis
Curtis L. Olson > > One idea would be to generate the entire earth in different levels of > detail and switch based on altitude. At higher altitudes, all your > tiles will likely cover more area and contain less information, so you > could make a scheme like that potentially work. However, then you'd > have to think about how you might hide the transition from one global > LOD to the next ... or maybe just live with a big pop at 10k, 50k, > 100k, etc.??? FWIW Here is some *excellent* global data for a start on this http://earthobservatory.nasa.gov/Newsroom/BlueMarble/ Here is the home page of a viewer http://www.andesengineering.com/BlueMarbleViewer/ an *unsupported* beta native Win32 port lives at http://rockfish.net/~nhv/osg/bmv_mingw.tgz WARNING THE COMPLETE SET OF DATA FILES IS HUGE and will require an additional download of approx 70 MB for the minimal installation and approx 300 meg for the full data set, which uncompresses to ~2.0 GB Note this data is the same resolution as the gtopo30 DEM, 1 km pixels at 'best' LOD, and as distributed has 5 levels of texture LOD which is texture mapped onto an unperturbed sphere, this is suitable for distances of >50 miles or so IMHO If you have got the bandwidth and want a truly *awsome* virtual globe This is a *must* have Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Performance analysis
Michael Pujos writes: > You're absolutely right and IMHO it should be a long term goal to have a > terrain renderer (in a terrain interface architecture why not) that > supports long viewing distance and very detailed terrain with good > performance at high flying speeds and altitude (for example for military > aircrafts). But I agree it's no easy task at all and the current > renderer works great for 95% of uses. Just for fun, let's say you wanted to render a scene at high speed with 200 nm visibility. Let's say we have all the LOD terrain issues worked out and we have chosen to drape textures over the top of the terrain (i.e. photo-real satellite imagery type stuff.) area of a circle = pi*r^2 So this means you have 200*200*pi square miles of potentially viewable stuff. That's about 125,000 square miles. That's about 321,689,600,000 square meters. Let's say we are shooting for 1 pixel per meter resolution on our imagery and it takes 3 bytes to represent a pixel in RGB color space. That's about 900Gb of imagery data we'd need to have loaded just to render the scene. You could probably get by with a lot less memory if you use lower mipmap levels out in the distance; well you'd have to unless someone starts marketing a video card with 1Tb of video ram on it, which I don't see on the immediate horizon. That's just to render the static scene. Actually to be fair, you would be insane if you loaded more than the lowest level mipmaps for the distant areas, but now we've racheted up the complexity of our scenery renderer/pager by a couple notches to include all the texture management. Now, let's say you are flying at 600mph and we are cutting a 400mile swath across the world (in terms of visiblity, 200miles each direction.) That means 400*600 = 240,000 square miles of data need to be loaded every hour as you fly. This is about 6144 square meters which means 1,843,200,000,000 bytes/hour of pixel data. That's 512,000,000 bytes per second, or about 488Mb of data per second you'd have to load off your drive. Again, you'd get a lot of savings from using the lower level mipmaps. Let's say you got a 32x savings overall by using lower level mipmaps as appropriate. Now you are down to only 15Mb per second you'd have to load off your hard drive and page into memory ... that's 15Mb of HD activity for every second you fly with 200miles visibility at 600mph ground speed. Now, assuming your computer and your IDE drive could keep up with all of that, how much CPU is going to be left for actual flight simulation? Even though you wouldn't load the the highest level mipmaps for the entire visible area, you could potentially fly to any where in that area, so you'd need the highest res data available on your drive. At 1 pixel per meter resolution, you'd need 900Gb just to cover a 200 mile radius area. That's not counting any of the terrain data, only the imagery we are laying on top. Even if I screwed up and missed a decimal someplace, it's still not good news. :-) I guess my point (if I have one) is that when people talk about 200 miles visibility as a design goal, they need to consider what goes into that and how much area/data that area actually contains. If you also add support for high speed flight on top of that, you have to consider how much data is going to need to be paged in as you fly. I'm making a lot of assumptions and picking on CLOD in this example... but the amount of data increases with the square of the radius of visibility so this will catch up quickly with just about any scheme you pick. One idea would be to generate the entire earth in different levels of detail and switch based on altitude. At higher altitudes, all your tiles will likely cover more area and contain less information, so you could make a scheme like that potentially work. However, then you'd have to think about how you might hide the transition from one global LOD to the next ... or maybe just live with a big pop at 10k, 50k, 100k, etc.??? If anyone wants to go away for a while and work on a different terrain modeling and rendering approach, please be my guest. Just do it in a way that doesn't disrupt the current scheme and I'll be happy. :-) Regards, Curt. -- 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] Performance analysis
On Wed, 2003-01-22 at 18:56, Curtis L. Olson wrote: > David Megginson writes: > > Continuous LOD is probably a non-starter for us -- at least, the > > implementations I've read about assume a regular elevation grid with a > > simple texture mapped on top, and that doesn't describe the way we > > model scenery. If someone wants to try that, you'll probably want to > > write it from scratch and then we can try plumbing it into > > FlightGear. > > There are many issues with making CLOD work. Many/most of them are > solvable with a lot of effort. > > > For static LOD, we could create multiple versions of each tile at > > different resolutions for different distances. In that case, as Curt > > has pointed out, the challenge is edge meshing. Let's say that we > > have four LOD versions for each tile, and that we have an algorithm > > that guarantees no more than a single-step resolution jump between > > tiles. Any given edge will still have to be able to mesh up with > > another tile of the same resolution, one higher, or one lower, so > > we'll have, probably, over a hundred versions of each tile. > > It would be interesting to abstract out the scenery > rendering/management system so that we could drop in additional > schemes (maybe similar to the FDM's). > > There are a zillion different schemes to handle terrain LOD, most of > which have been tried at one point or another, all of which have > significant short comings, but many of which have significant > strengths as well. > > In the end (for me) it came down to picking the approach that seemed > to have the fewest short comings and then making it work as best as we > can. > > No, we can't push out the visibility to obscene values, but consider > that a reasonable visibility is 10 miles which we handle quite easily > on average hardware. Sure there are places in the world where the > visibility is much higher, and as you gain alitude visibility > increases. But ... in my mind, if that's the only issue, I'm not too > upset. > > I do like the idea of abstracting out the scenery subsystem. This > would allow someone else to gain a better understanding of the > complexities of building a terrain renderer that works in a flight > sim. You'll need to consider things like: > > - continuous world wide coverage > - disk space usage > - data availability > - edge matching if you use a tiling scheme > - ability to query for a terrain elevation at an arbitrary point > - ability to insert airports into the larger scheme (and do all the >appropriate edge matching) > - roads, rivers? > - random ground cover objects? > > The CLOD techniques are really slick, and I've seen some cool demos. > However, I personally so far (and maybe something exists, I dunno) > have not seen anyone pull all the pieces of this together and handle > all the issues/needs required by a flight sim. > > That doesn't mean there couldn't be something out there I'm not aware > of (likely there is) but I haven't seen it. > > Oh, I almost forgot, you also have to consider what you are going to > do about creating the necessary tools to generate the earth in the > appropriate format required by your scheme. This is no small task. > There's a good chance that in the end, you'll have more lines of code > into your offline scenery building tools than we'll have in all of > FlightGear. > > I don't want to scare anyone off here, but there are some harsh > realities here that need to be considered as part of this discussion. > You're absolutely right and IMHO it should be a long term goal to have a terrain renderer (in a terrain interface architecture why not) that supports long viewing distance and very detailed terrain with good performance at high flying speeds and altitude (for example for military aircrafts). But I agree it's no easy task at all and the current renderer works great for 95% of uses. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Michael Pujos wrote: > 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. Woo hoo! The LOD war is back. :) My feelings: Static geometry is good enough for almost everything these days, including flight sims. The only exception is getting the "all the way to the horizon" rendering correct for high altitudes, where visibility can be infinite and mountains 200nm away should be visible. Continuous LOD schemes are the only ones that make sense. "Chunked" LOD is optimizing the wrong thing -- Thatcher gets very high polygon throughput, which admittedly make for good flame bait. But real users can't count polygons on modern hardware, and only care that the screen looks right and the animation is smooth. For a LOD scheme the only correct metrics are (1) screen space error and (2) lack of visible "pops" or geometry discontinuities. Chunked LOD does no better than ROAM variants in error (despite using far more polygons to acheive that error), and shows significantly worse discontinuity behavior (whole chunks go in and out at once). Split-only ROAM is my choice, FWIW. You can push the per-triangle CPU overhead down to 2-300 cycles, which on modern processors is easily sufficient for tens of thousands of triangles per scenery tesselation. For real-world terrain, that's less than a pixel of screen space error. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Performance analysis
David Megginson writes: > Continuous LOD is probably a non-starter for us -- at least, the > implementations I've read about assume a regular elevation grid with a > simple texture mapped on top, and that doesn't describe the way we > model scenery. If someone wants to try that, you'll probably want to > write it from scratch and then we can try plumbing it into > FlightGear. There are many issues with making CLOD work. Many/most of them are solvable with a lot of effort. > For static LOD, we could create multiple versions of each tile at > different resolutions for different distances. In that case, as Curt > has pointed out, the challenge is edge meshing. Let's say that we > have four LOD versions for each tile, and that we have an algorithm > that guarantees no more than a single-step resolution jump between > tiles. Any given edge will still have to be able to mesh up with > another tile of the same resolution, one higher, or one lower, so > we'll have, probably, over a hundred versions of each tile. It would be interesting to abstract out the scenery rendering/management system so that we could drop in additional schemes (maybe similar to the FDM's). There are a zillion different schemes to handle terrain LOD, most of which have been tried at one point or another, all of which have significant short comings, but many of which have significant strengths as well. In the end (for me) it came down to picking the approach that seemed to have the fewest short comings and then making it work as best as we can. No, we can't push out the visibility to obscene values, but consider that a reasonable visibility is 10 miles which we handle quite easily on average hardware. Sure there are places in the world where the visibility is much higher, and as you gain alitude visibility increases. But ... in my mind, if that's the only issue, I'm not too upset. I do like the idea of abstracting out the scenery subsystem. This would allow someone else to gain a better understanding of the complexities of building a terrain renderer that works in a flight sim. You'll need to consider things like: - continuous world wide coverage - disk space usage - data availability - edge matching if you use a tiling scheme - ability to query for a terrain elevation at an arbitrary point - ability to insert airports into the larger scheme (and do all the appropriate edge matching) - roads, rivers? - random ground cover objects? The CLOD techniques are really slick, and I've seen some cool demos. However, I personally so far (and maybe something exists, I dunno) have not seen anyone pull all the pieces of this together and handle all the issues/needs required by a flight sim. That doesn't mean there couldn't be something out there I'm not aware of (likely there is) but I haven't seen it. Oh, I almost forgot, you also have to consider what you are going to do about creating the necessary tools to generate the earth in the appropriate format required by your scheme. This is no small task. There's a good chance that in the end, you'll have more lines of code into your offline scenery building tools than we'll have in all of FlightGear. I don't want to scare anyone off here, but there are some harsh realities here that need to be considered as part of this discussion. Regards, Curt. -- 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] Performance analysis
Michael Pujos writes: > Yes I agree it would need to be done from scratch. I'm considering > giving it a go. Another aspect of LOD rendering is you can't use OpenGL > lighting since geometry is always changing, so lightmaps must be used > for lighting. Vertex morphing is required so the terrain looks not > changing. The other problem is that we don't just make a grid and drop a texture on it; instead, we use actual geometry to model different land uses. That pretty-much destroys most CLOD algorithms. > Is it already possible with TerraGear to generate a regular grid which > would mirror the original source DEM ? I don't think I'd bother with most of the TerraGear tools at all if you're trying CLOD -- just make sure that your loader and rendering engine works with plib. 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
[Flightgear-devel] Performance analysis
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 - 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). Flat profile: % the percentage of the total running time of the time program used by this function. cumulative a running sum of the number of seconds accounted seconds for by this function and those listed above it. self the number of seconds accounted for by this secondsfunction alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. self the average number of milliseconds spent in this ms/callfunction per call, if this function is profiled, else blank. total the average number of milliseconds spent in this ms/callfunction and its descendents per call, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. The index shows the location of the function in the gprof listing. If the index is in parenthesis it shows where it would appear in the gprof listing if it were to be printed. Each sample counts as 0.001 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 7.05 5.84 5.84 26372747 0.00 0.00 sgFrustum::contains(sgSphere const *) const 5.02 10.00 4.16 2996413 0.00 0.01 ssgBranch::cull(sgFrustum *, float (*)[3], int) 3.87 13.20 3.20 69787344 0.00 0.00 ssgEntity::isDirtyBSphere(void) 3.68 16.25 3.05 67381320 0.00 0.00 ssgList::getEntity(unsigned int) 3.21 18.91 2.66 5662019 0.00 0.00 sgMultMat4(float (*)[3], float const (*)[3], float const (*)[3]) 3.05 21.44 2.53 33844511 0.00 0.00 ssgEntity::getTraversalMask(void) 2.95 23.88 2.44 154571808 0.00 0.00 sgSphere::getRadius(void) const 2.69 26.11 2.23 6292 0.35 2.51 FGHitList::IntersectBranch(ssgBranch *, double (*)[3], double *, double *) 2.62 28.28 2.17 83039779 0.00 0.00 sgScalarProductVec3(float const *, float const *) 2.61 30.44 2.16 35003350 0.00 0.00 ssgEntity::cull_test(sgFrustum *, float (*
re: [Flightgear-devel] Performance analysis
On Wed, 2003-01-22 at 17:14, David Megginson wrote: > Hoyt A. Fleming writes: > > > There was a discussion quite a while back about decreasing the > > terrain level of detail (LOD) as the terrain distance increased so > > that frame rates could be increased. Do you know if that LOD > > concept looked promising for FG? > > Continuous LOD is probably a non-starter for us -- at least, the > implementations I've read about assume a regular elevation grid with a > simple texture mapped on top, and that doesn't describe the way we > model scenery. If someone wants to try that, you'll probably want to > write it from scratch and then we can try plumbing it into FlightGear. Yes I agree it would need to be done from scratch. I'm considering giving it a go. Another aspect of LOD rendering is you can't use OpenGL lighting since geometry is always changing, so lightmaps must be used for lighting. Vertex morphing is required so the terrain looks not changing. Is it already possible with TerraGear to generate a regular grid which would mirror the original source DEM ? Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Performance analysis
Hoyt A. Fleming writes: > There was a discussion quite a while back about decreasing the > terrain level of detail (LOD) as the terrain distance increased so > that frame rates could be increased. Do you know if that LOD > concept looked promising for FG? Continuous LOD is probably a non-starter for us -- at least, the implementations I've read about assume a regular elevation grid with a simple texture mapped on top, and that doesn't describe the way we model scenery. If someone wants to try that, you'll probably want to write it from scratch and then we can try plumbing it into FlightGear. For static LOD, we could create multiple versions of each tile at different resolutions for different distances. In that case, as Curt has pointed out, the challenge is edge meshing. Let's say that we have four LOD versions for each tile, and that we have an algorithm that guarantees no more than a single-step resolution jump between tiles. Any given edge will still have to be able to mesh up with another tile of the same resolution, one higher, or one lower, so we'll have, probably, over a hundred versions of each tile. 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] Performance analysis
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
[Flightgear-devel] Performance analysis
Michael, I am very glad to see that you are willing to tackle increasing the efficiency of the scenery system. I for one, would like to increase the visibility to "see where I am flying." (Perhaps, that is why I fly in the North West.) There was a discussion quite a while back about decreasing the terrain level of detail (LOD) as the terrain distance increased so that frame rates could be increased. Do you know if that LOD concept looked promising for FG? Hoyt Fleming ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
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
[Flightgear-devel] Performance analysis
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). prof.txt.gz Description: GNU Zip compressed data
