Precomputing Transparency Order in 3D | Hacker News Reader

Precomputing Transparency Order in 3D

jacobdoescode.com

14 pointsjacobp1003 comments

> Today, getting the correct order for translucent faces typically involves sorting the faces by their distance to the camera on the CPU, then sending the sorted faces to the GPU. This means every time the camera moves, you need to re-sort the translucent faces.

Don't most games and rendering engines these days use order-independent transparency if they care about these problems?

https://osor.io/OIT

How does the method in the OP article work if you're rendering meshes instead of planar objects? Sure, a mesh is just composed of planar triangles, but that's a _lot_ of triangles to sort, and with an O(n^2) algorithm, it's going to be painful.

A big problem with OIT techniques is that it presumes all see-trough surfaces use alpha blending. In reality other blending modes can be used, most notably additive blending. Additive blending is very useful because it ensures the surface will always be brighter than the background, which is important for things like fire, which look strange when the background is actually brighter than the blended surface, this is quite common.

Another issue is that OIT techniques usually have a breaking point where drawing too many layers will start showing artefacts.

So in order for OIT to work correctly you have to enforce all surfaces to be either opaque or use alpha blending and also avoid drawing too many layers. This is more limiting than sorting based approaches for the average usecase, even if it does end up fixing cases that aren't easily fixed via sorting. Besides that, people working in games and realtime rendering have simply gotten accustomed to designing around alpha blending issues.

What's the granularity of sorting, for most modern games? I'm guessing just sorting by an object or mesh center, instead of sorting each triangle, but are there are methods I'm unaware of?

Reply on news.ycombinator.com