Traffic Shader
| This article is a stub. You can help the wiki by expanding it. |
Status
Thorsten has an experimental ALS traffic shader running http://www.science-and-fiction.org/FG/pics/cars_als.jpg[2]
Thorsten prototyped a road shader [3] [4] which generates traffic ready to the stage that he'd like to gather feedback from people who see it running - for that purpose it'd be easiest if we had a small patch of road folder available on TS where the child effect refers to the new work.[5]
(the code is pushed but not active) - after some reflection, I'd like to do road lights and cars procedurally rather than by lightmap. The advantages are numerous - car spacing can be varied with a daytime-dependent parameters at no extra cost, car spacings are naturally randomiable (no 1-dim tiling, no repetitive structures,...), cars can be 'stopped' in places for some time, car headlight color can vary easily,... Also lamps effect can be configured by simple parameters. To avoid passing parameters which don't have to be passed, the encoding of road types have to be discussed - potentially the location of the texture lookup space can be used for the purpose if it's reasonably stable.[6]
For those of you that haven't had the chance to see the osm2city traffic shader in action. Here are a couple sample videos of the Boston area. The resolution of the video is not the best, nor the composition, but gives you an idea of what to expect.[7]
Background
| 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 |
|---|
Feeding external ground traffic ("moving cars") into FG would not necessarily be very difficult - but it would almost certainly never match "roads" shown in FlightGear, and even if elevations would be patched up, there would remain quite a bit of work to be done.[8]
The hard-coded AI traffic system isn't yet sufficiently flexible for this kind of ground traffic - also, the underlying vector data for road networks must be available, too.[9]
A more promising/better-performing approach would involve using shaders, as per a number of "traffic shader" discussions we've had (especially affected by OSM2City)[10]
For instance, red and white dots moving in opposite directions[11]
If we have linear features like roads mapped in the proper direction and classified into left and right lanes, we could add overlay textures and normalmaps with the shader (think urban effect) and translate them with time, creating the semblance of traffic (like the urban effect, this would break at low altitude, but from reasonably high up might look credible)[12]
Note that there are two road effects, and fgdata/Effects/road*eff is Emilian's traffic shader. Though the correct way of using it would be to set TRAFFIC_SHADER_ENABLE = True and then run roads.py[13]
you'd need vector data for the corresponding road networks - next, you'd use those to come up with heuristics for creating and controlling "traffic". Usually (at high altitudes), those will just be colored spots moving along your roads - at lower altitudes (take/approach), you'd want to use some kind of LOD mechanism to use animated AI traffic nodes, at least within the visible FOV.
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.[15]
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...)[16]
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.[17]
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?[18]
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).[19]
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.[20]
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.[21]
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.[22]
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.[23]
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[24]
Testing the Shader
it comes with the normal install. You need to install the OSM structures to which it is applied.[25]
set F10->View->Rendering Options->Detailed Roads and Railways to enabled and use terrasync or another terrain updater to ensure that you have the OSM objects downloaded... then you need to be in an area that has the OSM roads applied... KBOS is one of those areas... go there in the UFO; parking space Gate_C42... use the [HOME] key to hover up to 1500 or so and look at the roads around the airport... use the up arrow to tip the UFO's nose down to about 45 degrees and look at the vehicles on the roads... at dusk and during the dark, they even have headlights...[26]
To see the traffic shader
- in Roads/ there's roads.eff in each subfolder (for the Bergen demo, I had just one of them... in general you need to change this in your script)
- this contains a line like <inherits-from>Effects/model-combined-deferred</inherits-from> -> change this to <inherits-from>Effects/road</inherits-from> (this itself inherits from model-combined-deferred and will not change the current behavior for classic or Rembrandt)
- switch ALS on, you may have to switch the model shader quality a bit higher than minimal To use the lightmap switch, just delete lightmap-switch.xml which contains a Nasal snippet and make the effects use /environment/lightmap-factor in the parameter section instead the property that the Nasal script wrote, it does the same thing and is always present. [27]
Previous work
looking into supressing head/tail lights on the traffic shader. One way you can check that is by checking the angle between the view vector and the tangent or the binromal (depending on the UV layout) Anyway, here's a link to my PoC traffic shader from some years ago, hope it helps (I've also added the car/lightmap texture I've come up with while doing it) : http://s.go.ro/qwd1eloh[28]
It's not obsolete, but I haven't developed it further as that aproach stalled with the work on the scenery generation, and there was no scenery released that had the feature enabled. I'm not sure how well it works with the OSM roads as generated now, since its UV mapping assumptions are based on the UV layout of the roads as it was generated by terragear as part of the tile ( U being 0..1 across the whole width of the road and V legthwise, it also requires continous V values across long stretches of road, otherways it causes some weird "pulsating" appearance). I assume some tweaking/adjustments are necessary to make it work, and unfortunately I can't test/work on it right now, as currently flighgear refuses to load any terrain here (it's simply dropping me in the ocean wherever I start, and I didn't get around to finding out why)[29]