I would like to suggest implementing reverse Z depth to mitigate z-fighting visual artifacts that can be observed in the game.
For the non-technical people reading this, this simply means less flickering of geometry that is very close to other geometry: concrete objects in custom layouts, lines and arrows on the ground (which seem to be placed about 1mm over the ground) and other such graphical issues.
To give a few actual examples:
There exists an efficient method to fight this, called reverse Z depth, which I believe is not currently used. Here are a couple links to articles talking about it and its implementation: NVIDIA article, example and additional links
This technique should have little to no performance impact, but should greatly improve the z-depth sorting, which would reduce graphical glitches and maybe even allow for less geometry offset.
For the non-technical people reading this, this simply means less flickering of geometry that is very close to other geometry: concrete objects in custom layouts, lines and arrows on the ground (which seem to be placed about 1mm over the ground) and other such graphical issues.
To give a few actual examples:
- South City, behind the grand stands across the main pitlane at /cp 20174427 4722383 9957501 19884 15474 0.0 60.0 - any time you move the camera, you can see the arrows flicker.
- Concrete parts: place a few concrete slabs next to each other, with some intersections, and you will also have severe flickering.
- In the Laurent Coil Cup mod I'm working on, I chose to have the sunshield as separate geometry above the windshield, because I need some of the windshield's geometry to be double-sided (the black part on the edges), and I also want to use the same windshield for the non-cup version, which doesn't have the sunshield; I need to separate the geometry by over 4mm to stop z-fighting from being visible in long-range shots, but in closeup shots you can actually see that offset.
There exists an efficient method to fight this, called reverse Z depth, which I believe is not currently used. Here are a couple links to articles talking about it and its implementation: NVIDIA article, example and additional links
This technique should have little to no performance impact, but should greatly improve the z-depth sorting, which would reduce graphical glitches and maybe even allow for less geometry offset.