1,746
edits
AI Traffic: Difference between revisions
Jump to navigation
Jump to search
m
→Ground traffic rendering: cleanup
m (Cleanup) |
m (→Ground traffic rendering: cleanup) |
||
| Line 303: | Line 303: | ||
** '''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), | ** '''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 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. | * The buffers can be a uniform array (minimum of points in each path segment and more smoothing), Uniform Buffer Object (UBO - not available until Vulkan due to Macs not supporting it), a Texture Buffer Object (TBO - Mac support unknown), or a texture looked up in a vertex shader (maybe slower). | ||
* 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. | * Data format: Each path segment is x,y,z position at regular times - a time-series of positions - 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, but 32 but floats can also be used at the cost of 2x the occupancy. 16 bit implementation: 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 time information can be stored as uniforms or in a UBO. Vehicles that move faster can have a higher speed scaling. There can be different path segment variations, for example if vehicles have a different acceleration pattern - e.g. speeding up and braking hard, or sharper turns, in an emergency. | |||
* Both ground vehicles, and taxiing 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. | * Both ground vehicles, and taxiing 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. | * 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. | ||