On 11 Mar 2013, at 20:37, Thomas Albrecht <ra...@web.de> wrote:

> I've been playing with populating my home airport's area with buildings 
> derived from OSM floorplan data. I think having many buildings in the correct 
> place greatly improves realism over the current random buildings/sparse 
> static models, especially when you know the area.
> However, now the buildings obviously don't match with ground textures or 
> random trees. Any bright ideas how to achieve this? I know I could follow the 
> photoscenery approach and pre-render special materials and masks for a couple 
> of cities, but that just doesn't scale.
> I wonder how x-plane 10 does this? Could we generate the texture on the fly? 
> Based on landclass and road data? I could see a number of 
> advantages/disadvantages here as compared to our current, generic textures:
> + much better autogen scenery possible: many textured streets/railroads 
> without additional scenery vertices
> + shared models with an individual piece of ground texture
> + get rid of sharp landclass borders
> + possibly improved resolution
> - eats much more video ram and CPU (but then I have 3 out of 4 idle cores ATM)
> - probably totally incompatible with the current terragear toolchain
> I know C/C++ and would be happy to start tinkering with this part at some 
> point. But I know next to nothing about OSG, OpenGL, and shaders. Graphics 
> gurus: is there any better way to do this?

Hi Tom (another Tom!)

A very interesting idea - so interesting I thought of it and discussed it with 
some people last year :) The summary answer is, it should be possible, it would 
have pretty much the benefits and drawbacks you mention (especially the VRAM 
consumption), and it would allow nice LoD and solve some other issues. 
Especially it avoid the nasty clipping issues we have with surface data in 
TerraGear, since you just paint into the texture, no need to clip all the 
linear data.

The big problem, I was told, is that this kind of texture generation (and 
regeneration, as the camera moves) is very unfriendly to OSG. Not to say it's 
impossible, since osgEarth does it, but as you noted, it's a very long way from 
our current scenery system in terms of technologies. If you were starting from 
clean, you'd probably do this using GLSL to render the textures, and 
potentially require OpenGL 3.

My suggestion is, if you want to pursue this (and I think it would be worth 
trying, for sure), do it as a fork / clone of 'fgviewer', which is our 
standalone viewer client. I.e copy how that program talks to the main FG 
process, and the replace whichever pieces of the render you need(like, all of 
it?), to make your approach work. Along the way you will have to learn quite 
about OpenGL, shaders,and OSG, but there are people here who can assist with 

There's a larger issue here, that 'soon' (likely during the summer) I want to 
start restructuring the codebase into multiple processes, so we can support 
different rendering architectures (and use multiple CPUs) better. That's 
Mathias Fröhlich's HLA/RTI work, and indeed he has done the recent work on 
extending fgviewer to test changes to the current terrain system. 

Oh, and if you can do IRC, I'm sure the guys in #fg_scenery would be delighted 
to discuss what you've done and a whole range of possibilities :)



Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
Flightgear-devel mailing list

Reply via email to