Random Buildings: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Switch to {{readme file}}, {{simgear source}} and {{gitorious source}} to remove the out of date and broken Gitorious links.)
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
As of 05/2012, FlightGear has improved support for randomly placed buildings. This feature will be available in the upcoming 2.7.0 release.
{{OSM Navigation}}


[[File:Random-buildings.jpg|thumb|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 ==
{{FGCquote
  |We currently use instanced buildings to save memory.  We've also added<br/>
deferred loading of models (including buildings) for the same purpose and<br/>
to separate loading of the tile itself from the objects within the tile.<br/>
<br/>
However, instanced buildings have some limitations.  In particular, the C++<br/>
placement code doesn't know the specific size of a building at a given<br/>
point, so has to assume it's the largest size from a set when ensuring that<br/>
it doesn't overlap with the triangle edge.  With Scenery 2.0, that causes a<br/>
problem as the triangles are much smaller in urban areas due to the<br/>
increased road resolution, so you may see a decrease in building density.<br/>
This can be addressed by clipping against the polygon edge rather than the<br/>
triangle edge.  I had some code to do this, but it increased load times due<br/>
to the increased computations and had some bugs as well.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32337029/
    |title=<nowiki>Re: [Flightgear-devel] cities in FG & how to move forward</nowiki>
    |author=<nowiki>Stuart Buchanan</nowiki>
    |date=<nowiki>2014-05-14</nowiki>
  }}
}}


Please note that this wiki article may be outdated, the latest information on random buildings can be found in: [http://gitorious.org/fg/fgdata/blobs/master/Docs/README.materials $FG_ROOT/Docs/README.materials ].
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.


[[File:Random-buildings.jpg|thumb|Random Buildings]]
Building generation is configurable through materials.xml, and documented in {{readme file|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.


In an effort to improve the scenery in cities, towns and villages with minimal impact to framerate, Stuart has been working on automatically generated "random buildings". The idea is to have FG itself generate buildings with randomized size, shape and texture in a very efficient manner, and builds on the work that he and Tim Moore did on random vegetation a couple of years ago. This is now available in git.
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.


Building generation is configurable through materials.xml, and documented in 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 rather limited by Stuart's artistic abilities. If anyone is interested in creating a better texture, please get in touch with Stuart on the mailing list or forums.
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


At a functional level, there are three different size of buildings
The new lightmap texture parameter is called <building-lightmap>) but the rest of the parameters are documented in {{readme file|materials}} if you want to have a play.
(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.


Obviously, this would be pointless if frame-rates were hit to the same
extent as they are with a similar number of normal models. The good
news is that on my system there is _no_ fps drop from the random
buildings. I get the same frame-rate whether or not the random
buildings are generated or not. The same applies whether or not I'm
running with Rembrandt.


Of particular note - I get significantly better frame-rates with this
rather than the urban shader.


For those interested, the technical background is as follows:
For those interested, the technical background is as follows:
- a Quadtree is used to ensure very fast culling of the buildings -
- a Quadtree is used to ensure very fast culling of the buildings - based on the work that Tim Moore did for the forests.
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
- 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.
- all the buildings at the leaf of the quadtree are part of the same
 
geometry, so the GPU can churn through it very quickly without having
You'll need generic shaders switched on.
to change state.


There are still some bugs to be worked out before this can be pushed
You can switch the log on and grep it on Linux by running:
to git, but I'm hoping to get it checked in over the weekend.


If someone is interested in spending some time creating a better
  fgfs --log-level=debug --log-class=terrain 2>&1 | grep "Total random buildings"
default texture, please get in touch.




= Related =
= Related =
* http://flightgear.org/forums/viewtopic.php?f=5&t=16083
* http://forum.flightgear.org/viewtopic.php?f=5&t=16083
* http://forum.flightgear.org/viewtopic.php?f=5&t=17598&p=166686#p166686
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37003.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37003.html
* http://gitorious.org/fg/simgear/commit/f9bf403fc0026f461090fc55e1e37f28f8359cea
* {{simgear source|commit=f9bf403fc0026f461090fc55e1e37f28f8359cea|view=commit}}
* http://gitorious.org/fg/simgear/trees/next/simgear/scene/tgdb
* {{gitorious source|proj=fg|repo=fgdata|commit=30d0d6e1bd8a3019a67ee8a796d12eb4cf7d6469|view=commit}}
* http://gitorious.org/fg/fgdata/blobs/master/Docs/README.materials
* {{simgear source|path=simgear/scene/tgdb}}
* {{readme file|materials}}
* [[AutoGen Scenery for FlightGear]]
* http://www.mail-archive.com/search?l=flightgear-devel%40lists.sourceforge.net&q=random+buildings&submit.x=0&submit.y=0




[[Category: Core development projects]]
[[Category: Core development projects]]

Latest revision as of 22:26, 29 February 2016

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/osm2city/osm2city/
fgdata https://gitlab.com/osm2city/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