🔴 OPEN BUG: Contrail Rendering Order

[Krishty]

Contrails sometimes overdraw the cockpit.

image.png (436.47 KiB) Viewed 1018 times

Contrails are not rendered with depth buffering anyway (this won’t come before D3D11/Vulkan rendering), but nonetheless the tile rendering order should prevent this specific problem from happening.

[Krishty]

It seems like contrails are indeed rendered correct, but they are Z clipped against the plane instead of the cockpit. That makes sense, as TAW’s cockpit requires Z buffering off (it needs overdraw to function correctly). Very interesting problem.

Could be solved by leaving Z write on but Z comparison off for the cockpit.

Will look at it later.

[Krishty]

We have the same bug with craters and bullets.

image.png (217.95 KiB) Viewed 976 times

[Krishty]

Some insight.

So the problem is, I must disable depth buffering for the cockpit to render properly (because DID overlaps it with the F-22 base model and relies on the cockpit polygons painting over the base even though the latter are closer to the viewer).

But depth buffering fully disabled means that the cockpit will be overdrawn with whatever comes later – contrails, craters, other planes!

So what I need to do is setting depth buffering to write-only mode during cockpit rendering. We will not use the depth buffer to discard pixels (i.e. the cockpit fully overwrites the base model) but we do keep the depth values of those new cockpit pixels we write, even if they are farther away than the base model. After rendering the cockpit, we go back to normal depth buffering.

This had been a problem until I recently worked on the vehicle API, but now I can realize it.

And it works really well – contrails, bullets and planes are now occluded by the cockpit. But there is one problem:

image.png (191.88 KiB) Viewed 55 times

The HUD writes a depth value close to the viewer! That makes sense – GPUs don’t understand transparency well – but it means that the HUD is an opaque surface from the perspective of depth buffering. Contrails, bullets, and planes cannot overdraw it because they are farther away.

So I need to add yet another mode for HUD rendering, where depth buffering is fully disabled. Or maybe I need to draw the HUD as the very last thing (this means I need to introduce some kind of “memory” into the rendering process).

This will most likely go away with a new renderer because D3D10 and later offer ways to implement order-independent transparency.

[Krishty]

Aaand here is the next problem. The systems MFD is blacked out:

image.png (615.64 KiB) Viewed 52 times

This took me a while to understand …

So the plane is drawn first. It renders a black low-poly pit.

Then the cockpit is drawn. It is farther away from the viewer than the black low-poly pit. F22 did not use depth buffering, so this was no problem and everything was overdrawn fine. But we use depth buffering and we need to set it to write-only mode like explained above, so new pixels write their depth without being discarded if something is closer. After this, we have “real” depth values for the cockpit.

The current TFXplorer version then renders the screens without depth buffering, i.e. just plainly overdrawing the cockpit with the screens. This is visible through this error that we now have for a long, long time:

image.png (208.51 KiB) Viewed 52 times

The display overdraws the dials, even though the dials are closer to the viewer, because there is no depth buffering in rendering the cockpit. Same thing as with contrails, craters, etc.

But now with all the workarounds, we have “proper” depth values for the cockpit, so we can render the screens with actual depth buffering! This works:

image.png (115.65 KiB) Viewed 52 times

… except for the systems display. Why?

The TAW cockpit model has a hole where systems MFD is. All other MFDs are opaque black, but this one just is a hole.

So this place doesn’t overwrite the depth values of the base model with the black low-poly pit.

And the black low-poly pit is closer to the viewer than the screen. So this part of the screen is discarded during rendering.

tl:dr: Three geometries are overlapping in this place (base model, cockpit model, screens) and there is no way to have a depth order that fits them all.

[Krishty]

Will be “fixed” in the next version.

I’ll also throw in an optimization where I implemented two almost identical tile collection algorithms a few years apart, but needed only one of them.