Traffic Shader
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/ |
OpenStreetMap use in FlightGear |
---|
This article is a stub. You can help the wiki by expanding it. |
Background
We need uv-mapped roads for a traffic shader. Once you have that, it's easy to add (we could even manage cars which don't use both lanes...)[1]
The reason we're not using randomly distributed models for trees and instead use a shader-based instancing scheme is performance - instancing trees is much faster. The random tree scheme as it is doesn't allow to place trees at a given position, but Stuart at some point seemed to be of the opinion that the random building code should theoretically be able to be changed such as to support position list vectors, and the same would hold for the trees. Maybe this should be discussed? Likewise for cars perhaps?[2]
There is a parameter to choose how roads look like. See http://osm2city.readthedocs.io/en/latest/parameters.html#light-effects. I happen to have chosen not to enable the traffic shader for different reasons - and that default has been applied to the few sceneries generated so far and available through terrasync. Until someone comes up with a good solution working with ASL, no-ALS, Rembrant and what have you, only one choice is available at generation time (not runtime).[3]
Once we have an uv-mapped road in the scenery, we can start to write a shader for it [...] it's not technically complicated to do since it's just a 2d texture compositing problem.[4]
Once we have uv-mapped roads in the scenery, Thorsten plans on writing some of his own, but thinks that'll be some time off.[5]
Roads could be rendered using urban without a normal map but a lightmap (even moving cars could be done that way using a moving normal map...), and for the other areas with buildings, normal maps could or could not be created.[6]
if we have a main effect FGData side and specific effects via inheritance TS side, there could be parameters (like traffic density) passed to the road shader which could be part of the design-time OSMtoCity run. Traffic density is sort of the first thing that comes to my mind - but there may be other requirements /use cases for buildings as well.[7]
we can proceed as follows:
- create a shell road.eff which for the time being duplicates the model-combined-deferred we currently run.
- then reference that instead of model-combined-deferred directly
- we patch the TS server to do that for existing tiles
- any special road effect development can then be inserted into that shell and made switchable runtime under user control[8]
References
References
|