Transparency

[devdept]

Thanks a lot for your valuable opinions, I really appreciate.

Even BSP has is own drawbacks. You need to clean models from invalid triangles, do pre-processing each time the model changes, decide how many candidates to take to balance the pre-processing time vs. FPS.

After some years I always ask about transparency on this forum and the answer is always "it depends...", transparency has to be the most complex thing on earth to solve completely ;-)

@Dukey: regarding Dual depth peeling why you cannot give the user a level number option an leave him/her to decide how accurate the transparency will be?

Pitty most model formats aren't actually BSP trees

Why aren't you doing BSP at triangle level?

[ZbuffeR]

Transparency can not work with a depth buffer when order is important. So it is the same problems that existed with opaque geometry before depth buffer was widely available. Painter algorithm, precise BSP, pre-sort stuff, or more recently, emulate several depth buffers with more involved shaders and passes.

[Dark Photon]

After some years I always ask about transparency on this forum and the answer is always "it depends...", transparency has to be the most complex thing on earth to solve completely ;-)

It definitely exposes the limitations of the standard pipeline. Here's one perspective that explains why translucency is considerably more difficult than opaque, especially in the general case.

The standard pipeline is built around smashing the entire world onto the framebuffer, keeping what's closest, and approximate shading at each pixel (or sample) so all pixels can be processed independently. In ray tracing terms, this means looking only at primary rays -- that is rays propagating back from the eye to the first thing light "hits" (of course, this is the reverse direction light actually propagates).

For basic translucency, that's not enough. And for general transparency that's not near enough.

For translucency, you have to consider secondary rays, tertiary rays, etc. (2nd, 3rd, 4th, etc. level light interactions) away from the eye. That is, reflected or transmitted rays spawned off where the primary rays hit. And you may need a number of such rays to approximate the shading sufficiently at that primary ray hit point (to compute what you can see through that surface). The rasterization pipeline isn't optimized for this -- at all. Ray tracing renderers OTOH are.

There's lots of coherence in computing primary light rays with local shading (massive SIMD parallelism = perfect for GPU), but soon as you start transmitting and reflecting child rays around you quickly lose that coherence.

So of course in the uber-simple realtime translucency case, you may just ignore the possible change in ray direction/speed and ray splitting (reflected/refracted) that may come with light passing through a translucent surface boundary, and try to just model a color change due to absorption. But then you still have to smash everything on the screen in the proper order because the default pipeline doesn't keep track of but more than surface at each pixel (fragment). Though you can write your own pipeline to do that.

We all know what what translucency looks like in the general case, but just as a reminder so we don't lose track of reality talking about cheap real-time rendering hacks: