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
Current scenery roads are not very 'connected'. We use raw OSM ways and just plop each one down as a polygon. I am currently working on better algorithms to create more of a network for line data. Right now, I only have this for airport taxiway lines, but will get it into roads as well. This started as a request for better handling of textured lines, as intersecting lines look awful, even with proper uv coordinates. one line is always 'on top' of the other. They don't really look like they intersect. If we want to be able to create a shader for adding moving traffic / lights, then a continuous network is a must.[1]
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...)[2]
you need to align the uv-mapping of the road with its direction, a feature that we don't need for any terrain. Which is why this needs some extra action.[3]
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?[4]
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).[5]
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.[6]
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.[7]
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.[8]
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.[9]
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[10]
References
References
|