Indirect sorting order problem

[Novum]

@temx I saw at least one problem in ad_sepulcher if noclipping to the SOCK logo: The transparency order isn't stable.

[temx]

Oh! I was hoping levels wouldn't overlap transparent water world polys since there's no control over what the BSP compiler does. Ironwail has the same problem (with r_oit 0), I never noticed.

Options are:

• ignore it
• draw transparent water in direct mode, using a list of potentially transparent surfs built at load time. This shouldn't hurt performance too much as long as there aren't too many water surfs, but it's another special case.
• serialize IB construction for water (impractical?) or sort the indices (difficult, will cost GPU time)
• implement OIT

I can do the 2nd one if you think this should be fixed.

[Novum]

What OIT does Ironwail use? Linked lists per fragment? That's very slow as far as I know. I think just drawing water through the CPU path is the easiest way to fix this and shouldn't hurt perf much.

[temx]

5f2a4ee should take care of this, now anything transparent should be drawn in the same order as before (no exception for opaque water, sadly).

What OIT does Ironwail use? Linked lists per fragment?

No, it's weighted blending. It uses a single R16G16B16A16 buffer with ADD blending mode which contains the sum of all transparent fragments (weighted by a function of the alpha value itself and the distance), resolve is dividing by alpha (which contains the sum of weights). Another R8 buffer contains the total "revealage" to blend with the opaque pass. It does look a bit strange at times (off, on; off, on; off, on). I think it's based on https://jcgt.org/published/0002/02/09/ It's a recent addition, it's not in 0.6.0.

[Novum]

Thanks for the fix!