Traffic Shader

From FlightGear wiki
Revision as of 15:38, 26 February 2017 by Hooray (talk | contribs)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

Background

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/


a wish for a shader you suggested a while ago: red and white dots moving in opposite directions[1]


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.[2]

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.[3]

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)[4]

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)[5]

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[6]


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.

[7]


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.[8]


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...)[9]

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.[10]


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?[11]


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).[12]


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.[13] 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.[14]

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.[15]


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.[16]

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[17]

References

References
  1. radi  (Jun 9th, 2014).  Re: osm2city.py development .
  2. Hooray  (Mar 20th, 2015).  Re: AI .
  3. Hooray  (Nov 15th, 2014).  Re: How to creat moving traffic .
  4. Hooray  (Nov 15th, 2014).  Re: How to creat moving traffic .
  5. Thorsten  (Apr 1st, 2013).  What effects are we missing? .
  6. radi  (Oct 20th, 2014).  Re: osm2city.py development .
  7. Hooray  (Mar 18th, 2015).  Re: AI .
  8. psadro_gm  (Mar 20th, 2015).  Re: AI .
  9. Thorsten  (Sep 20th, 2016).  Re: Please help to find the next default airport .
  10. Thorsten  (Mar 20th, 2015).  Re: AI .
  11. Thorsten  (Oct 16th, 2015).  Re: Populate 3000 airports in one day .
  12. Rick Gruber-Riemer  (Feb 23rd, 2017).  Re: [Flightgear-devel] FlightGear 2017.1.1 released! .
  13. Thorsten Renk  (Feb 24th, 2017).  Re: [Flightgear-devel] FlightGear 2017.1.1 released! .
  14. Thorsten Renk  (Feb 23rd, 2017).  Re: [Flightgear-devel] FlightGear 2017.1.1 released! .
  15. Thorsten  (Aug 28th, 2013).  Re: Night time .
  16. Thorsten Renk  (Feb 25th, 2017).  Re: [Flightgear-devel] OSM Buildings Effects (was Re: FlightGear 2017.1.1 released!) .
  17. Thorsten Renk  (Feb 24th, 2017).  Re: [Flightgear-devel] FlightGear 2017.1.1 released! .