Re: [Flightgear-devel] Performance

2012-12-16 Thread Stuart Buchanan
Hi All, While I hesitate to claim performance improvements I've not seen myself, it may be that this was caused by this commit: 266b362238d0cef5a1c4df81bacbe941ee4c59ef which discards transparent fragments. I'd be very interested if you could revert the changes in that commit and let me know if

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Adrian Musceac
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote: Hi Mathias, > Ok, for that, I can see a lot of solutions. > > Having one that is may be close: > Use the BVH tree that is used in fgelev or fgai. The fgelev one is > parametrized like you probably need today. There is one hacky switc

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
Hi, On Sunday, December 16, 2012 22:32:48 Adrian Musceac wrote: > My main interest with terrain was a) having longer distances available, and > b) having separate traversal masks only for surface. All for use in my > infamous now radio code. This lead to what I have now, an improvement in > memor

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Adrian Musceac
On Sunday, December 16, 2012 22:38:41 Mathias Fröhlich wrote: > Hi, > > On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote: > > I am aware there are better systems out there, I'm just doing what I can > > within the restrictions of the BTG format. I'd be more than happy to have > > a real

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
Hi, On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote: > I am aware there are better systems out there, I'm just doing what I can > within the restrictions of the BTG format. I'd be more than happy to have a > real terrain LOD, but right now that means lots of changes in Terragear and >

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Adrian Musceac
On Sunday, December 16, 2012 21:18:10 Stuart Buchanan wrote: > On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote: > > It' basically very simple. Far tiles no longer compute anything other > > than it's own geometry, and also use a very low resolution texture set, > > obtained by running a batc

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Emilian Huminiuc
On Sunday, December 16, 2012 19:37:37 James Turner wrote: > On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: > > I'm surprised there's any benefit to using a very low resolution texture > > set. Surely the normal textures are already loaded by OSG and it's > > cheaper just to refer > > to those rat

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Adrian Musceac
On Sunday, December 16, 2012 21:37:37 James Turner wrote: > On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: > > I'm surprised there's any benefit to using a very low resolution texture > > set. Surely the normal textures are already loaded by OSG and it's > > cheaper just to refer > > to those rat

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread James Turner
On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: > I'm surprised there's any benefit to using a very low resolution texture set. > Surely the normal textures are already loaded by OSG and it's cheaper > just to refer > to those rather than loading some more textures? Or are we not > sharing our

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Stuart Buchanan
On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote: > It' basically very simple. Far tiles no longer compute anything other than > it's own geometry, and also use a very low resolution texture set, obtained by > running a batch resize on the regular texture set. OK. So you don't load anything

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
Hi, On Sunday, December 16, 2012 20:24:48 Adrian Musceac wrote: > It's actually nothing really special about it, I'm just modifying a little > the tile manager to define "inner tiles" and "outer tiles". The elevation > data is inside the same old BTG files, which are actually lists of polygons >

[Flightgear-devel] Performance

2012-12-16 Thread Torsten Dreyer
Hi everybody, I just had the chance to compile a recent git-pull on my old and battered linux-notebook workhorse and with great delight, I noticed that I can run FlightGear again with 26fps at KSFO. I had to strip down most eye candy shaders for the GeForce Go 7400 but 3D clouds render fine wi

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Adrian Musceac
On Sunday, December 16, 2012 18:39:47 Mathias Fröhlich wrote: > Hi Adrian, > > The same idea is behind the osg lod based whole world model. > Where do you store the elevation data? > > Greetings > > Mathias > Hi Mathias, It's actually nothing really special about it, I'm just modifying a littl

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Curtis Olson
There are many issues and tradeoffs with mesh simplification. There are many algorithms and approaches, each with their own unique strengths and weaknesses. Challenges include finding a strategy to hide the cracks between adjacent tiles draw with different levels of details (and possibly more or

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
Hi Adrian, The same idea is behind the osg lod based whole world model. Where do you store the elevation data? Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access P

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Adrian Musceac
On Sunday, December 16, 2012 12:35:20 Stuart Buchanan wrote: > Hi Adrian, > > On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote: > > I am presenting an experimental (WIP) method to reduce memory consumption > > by scenery with 30%, while increasing the visibility distance 4 times. > > This met

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Stuart Buchanan
Hi Adrian, On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote: > I am presenting an experimental (WIP) method to reduce memory consumption by > scenery with 30%, while increasing the visibility distance 4 times. > This method relies on some kind of LOD system, without mesh simplification. > Peo