Random Buildings

Autogen Scenery
Started in 11/2013
Description Improved autogen support for FlightGear using OSM data
Contributor(s) radi, vanosten, Soitanen, portreekid
Status Under active development as of 02/2016
Topic branches:
$FG_SRC https://gitlab.com/fg-radi/osm2city/
fgdata https://gitlab.com/fg-radi/osm2city-data/
Random Buildings

The old Urban Shader

The old urban effect, even at minimum quality level, does a lot of texture reading. It needs to iteratively compute the intersection point of your view line with the heightmap, and so needs to read the heightmap quite a lot (if I remember correctly, it might need to read it up to 20 times - most 'normal' shaders read perhaps 1-5 textures). Texture read operations are generically expensive, more so on less powerful hardware.

So the urban effect has quite different demands on the GPU than other effects, and there is no reason it should scale like other effects - it is quite possible that it simply doesn't run fast enough on your machine.

The new 'random buildings' gives a much more realistic look, from above *and* beside, and doesn't do a zillion texture lookups. It does eat some RAM but most people have more RAM than GPU fill-rate these days, when runing FlightGear. (Also you can tune the random buildings density)

The urban effect is really a visual hack anyway, we'd strongly suggest leaving it off and using the new 'random buildings' feature instead, as described below:

The new System

Cquote1.png We currently use instanced buildings to save memory. We've also added

deferred loading of models (including buildings) for the same purpose and
to separate loading of the tile itself from the objects within the tile.

However, instanced buildings have some limitations. In particular, the C++
placement code doesn't know the specific size of a building at a given
point, so has to assume it's the largest size from a set when ensuring that
it doesn't overlap with the triangle edge. With Scenery 2.0, that causes a
problem as the triangles are much smaller in urban areas due to the
increased road resolution, so you may see a decrease in building density.
This can be addressed by clipping against the polygon edge rather than the
triangle edge. I had some code to do this, but it increased load times due
to the increased computations and had some bugs as well.


— Stuart Buchanan (2014-05-14). Re: [Flightgear-devel] cities in FG & how to move forward.
(powered by Instant-Cquotes)
Cquote2.png

As of 05/2012, FlightGear supports a new "random buildings" feature, buildings are generated at runtime and placed in Urban and Town areas. In v2.8.0 these take up a lot of memory, but in subsequent releases this has been improved significantly.

Building generation is configurable through materials.xml, and documented in $FG_ROOT/Docs/README.materials. It is designed to be flexible enough that we can have different types of cities in Europe compared with the USA, or Africa. The current texture used for the buildings is a proof of concept, and we are looking for people with artistic abilities to contribute improved textures. If anyone is interested in creating a better texture, please get in touch with User:Stuart on the mailing list or forums.

At a functional level, there are three different size of buildings (small, medium, large), with slightly different constraints (small and medium buildings are never deeper than they are wide, small buildings may have pitched roofs). Various parameters can be set in the materials.xml file, such as the proportion of each building size, the texture file (which is shared across all buildings), and the range of sizes of each building. The actual buildings are then generated by FG itself directly as OSG primitives.

The buildings (including the texture to use) are defined in materials.xml, and you can assign different building sizes and distributions to different material types. You can already see that in the difference between Urban and Town/Suburban areas.

We already have the ability to select a terrain material based on a <condition> statement, which is evaluated when the tile is loaded, so it is a very easy job to create a new material definition for a given region using a condition statement that checks /position/latitude-deg and /position/longitude-deg

The new lightmap texture parameter is called <building-lightmap>) but the rest of the parameters are documented in $FG_ROOT/Docs/README.materials if you want to have a play.


For those interested, the technical background is as follows: - a Quadtree is used to ensure very fast culling of the buildings - based on the work that Tim Moore did for the forests. - a single 1024x1024 texture is used for all the buildings, minimizing the number of state changes on the GPU

There's also support for emissive lighting, at present, this only works with rembrandt and the skydome switched off.

You'll need generic shaders switched on.

You can switch the log on and grep it on Linux by running:

 fgfs --log-level=debug --log-class=terrain 2>&1 | grep "Total random buildings"


Related