1,746
edits
AI Traffic: Difference between revisions
Jump to navigation
Jump to search
Add info on the modern ground traffic rendering approach is, in case detailed ground traffic becomes a part of the base package in future years - i.e. what the modern way of rendering a lot of animated objects has been since 2010 and earlier. The context is recent discussion on scenery slowdown and animation on the mailing list.
m (FGAirports as tool of choice for groundnets building moving forward) |
(Add info on the modern ground traffic rendering approach is, in case detailed ground traffic becomes a part of the base package in future years - i.e. what the modern way of rendering a lot of animated objects has been since 2010 and earlier. The context is recent discussion on scenery slowdown and animation on the mailing list.) |
||
| Line 285: | Line 285: | ||
In essence, all the information you need can be compiled from multiple sources, including Wikipedia, airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative! | In essence, all the information you need can be compiled from multiple sources, including Wikipedia, airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative! | ||
== Ground traffic rendering == | |||
=== Performance === | |||
* CPU: Currently having a lot of nodes in the OSG scene-graph will rapidly make FlightGear CPU bound. A lot of separately animated ground traffic objects mean a lot of nodes. Static objects i.e. non-animated objects can be put into one mesh, hence one scnegraph node, with the current system | |||
* GPU: Having fewer draw calls is fast. Having fewer state changes is fast. | |||
* The fast path for both CPU and GPU is creating a way to combine multiple animated objects in one mesh - this is how modern 3d applications do lots of objects with animations fast. | |||
=== The fast way to do moving objects is to let the vertex shader look at information in buffers and position each object === | |||
* Have all the different path segments stored in one buffer that can be read by the vertex shader. This buffer can be generated at runtime for each airport, maybe using NASAL scripts, and not updated.It's also possible to store the 1st buffer in TerraSync. | |||
* Have a second buffer store the object ID (i.e. ground vehicle), any vehicle animation state, which path segment each object is on, the starting time, and a speed scaling factor. The second buffer is updated regularly by the CPU. | |||
* The object ID (an integer) can be | |||
** '''a).''' added to each vertex as an vertex attribute - every type of object is combined in one vertex buffer and rendered with the same shaders, texture atlas or array, material parameters that change between objects or within objects like specularity as as vertex attributes or textures, and a shader that can handle all object animations, The entire set of objects takes up one scene graph node. It's possible to do ground vehicles and aircraft as two meshes. | |||
** '''b).''' added to a per-instanced vertex attribute - each different type of object (different ground vehicle) is instanced and takes up one scene-graph node (this can allow different shaders and textures per object type), | |||
* The vertex shader can trivially look at the object ID, path segment, the starting time, speed scaling factor, and current time to position each object. If the current time is past the end of the path, | |||
* The buffers can be a Uniform Buffer Object (UBO), a Texture Buffer Object (TBO), or a texture looked up in a vertex shader. | |||
* Each path segment is x,y,z position at regular times - e.g. [10m, 20m, 0m elevation] at t = 1s. [20m, 25m, 0m] at t=2s . [30m, 30m, 0m] at t= 3s. 16 bit integers are enough. If a texture is used it can be 16bit RGB - R=x, G=y, B=z. 2 consecutive 8 bit values can also be read from a texture.16 bit integers can cover an ground traffic area of ~65km with a spacing of 1m. 16bits can give a ~13km ground traffic area with an accuracy of 20cm. The accuracy of the positions doesn't matter too much - the vertex shader can look at 2-3+ path positions and create a smooth interpolation (a smooth curve joining the points). The time steps can also be large. If a path has a slowly moving segment, it will take up more points. If a path segment takes a short amount of time, it can have a special xyz numner to indicate path has ended - otherwise the path start/end information can be stored as uniforms or in a UBO. Vehicles that move faster can have a hgiher speed scaling. | |||
* Both ground vehciles, and taxxing aircraft can be done this way. It's possible to replace a conventional AI aircraft model, with a fast ground traffic model once an aircraft starts taxiing. | |||
* If models use animations, they should ideally use a vertex shader that can handle all these animations - so having multiple draw calls per model and CPU-side animation is avoided. | |||
The way animation is handled (moving objects and parts of moving objects) in modern 3d application is to store the animation data in arrays/buffers on the GPU side and render multiple objects in one draw call. | |||
From a quick google search - a 2010 blog about whether UBOs or TBOs are more suited for different tasks: | |||
''"Personally I use them for instanced rendering by storing the model-view matrix and related information of each and every instance in a common uniform buffer and use the instance id as an index to this combined data structure. This usage performs very well on my system.'' | |||
''Also uniform buffers can be used to store the matrices of bones and use them for implementing skeletal animation, however, I personally prefer using normal 2D textures for this purpose to take advantage of the free interpolation thanks to the dedicated texture fetching units but that’s another story." - Rastergrid blog[https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/][https://web.archive.org/web/20211119134448/https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/]'' | |||
This is from a 2010 blog - this general approach has been the way to do lots of animated objects for a long time. | |||
== Warnings and Limitations == | == Warnings and Limitations == | ||