Re: [Flightgear-devel] Generating ground textures on the fly?

[James T. <zak...@ma...>]

On 11 Mar 2013, at 20:37, Thomas Albrecht <ra...@we...> 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 that.

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 :)

Regards,

James