Hacker News Reader

Comment by Animats | Hacker News Reader

He hasn't found the hard problem yet.

If you have two translucent objects, how do you combine the colors? This is hard to do with Z-buffer rendering. The obvious coloring operation is not commutative, and in a Z-buffer system, you don't know which face gets rendered first.

This is a huge pain. You can't just dump everything into the GPU and let it draw in parallel, which is what GPUs do fast. You usually have to depth-sort triangles, so the front triangle gets rendered last. This delays rendering while the CPU does the sort.

There's a GPU-based solution to this, but it involves some compromises in quality.[1]

[1] https://developer.nvidia.com/content/transparency-or-translu...

View on HN

Involving colors is much more complicated than that; in theory if you shine white light through stack a red filter on top of blue filter, I'd expect the intersecting area to be closer to black than purple. You can see that in for example this picture: https://www.walmart.com/ip/Sightmark-32mm-Filters/31197086

This is just the tip of the iceberg when it comes to the complexity of translucent objects. To get truly convincing results spectral rendering is needed, but of course that is prohibitively expensive for real-time use.

Yes its all very loosely approximated to real life anyway when avoiding the spectral level. Its not just the filter but also the quality of light being emitted/reflected from behind - A broad spectrum light like the sun will create more even effects while narrow spectrum lights like flourescent lamps or HPS street lamps can act variably.

Looking through a yellow filter at a yellow flourescent light - you could easily see almost all the original light (bright yellow) or none (black) depending on the spectral transmission of the filter.

You also need to simulate polarization (and maybe quantum mechanics) for sunglasses to work properly.

I don't know where the quantum nature of light would come in for sunglasses, but you are correct polarisation would definitely be needed.

It's claimed that polarization is due to quantum effects.

https://www.youtube.com/watch?v=zcqZHYo7ONs

…I think it actually isn't and the people explaining it have just forgotten it's supposed to be a metaphor though.

polarization is very much a quantum effect, however the specific experiment in the video does not prove the quantum wierdness because the setup does allow a hidden variable explanation.

Polarization of a single photon has to be treated in a QM framework , but there is no need for that with normal sources.

Also, polarization as a degree of freedom arises out of symmetry considerations, and that's what you learn in QFT.

Why is that any more difficult than calculating color reflection/absorption on a surface? Both presumably involve multiplication in spectrum space.

You don't have multiple of those stacked on top of each other. At least not as long as you don't dive deep into the global illumination rabbit hole. And then you've got bigger and more pressing problems to solve.

Yes, you are right that conceptually it is the same problem both with reflections and transmissions. The key difference is that in typical scenes indirect/bounce lighting tends to have comparatively subtle effect whereas translucency, especially when colored, can be easily quite apparent. Colored mirrors are pretty rare but colored transparent objects are very common.

The "right" solution with no quality compromises is per-pixel linked lists (PPLLs) that are then sorted afterward. This is straightforwardly implementable on GPU, but it remains to be seen whether the technique will take off, given the overhead.

Pixel Shader Interlock (or Raster Ordered Views in D3D12 terminology) is effectively the same thing but without a resolve step, but the overhead is massive and basically too slow in practice.

To be honest, the game developer way of solving this is to just not use transparency. Too many things rely on the G-buffer / depth buffer these days, and transparency is usually limited to a lower quality render anyway.

The (stochastic) order-independent transparency and k-buffer line of work is definitely cool for what it was. I get the sense that RTX will finally make it so that folks are going to end up just ray tracing the transparent volumes (even if you first did a rasterization pass of the "non transparent stuff").

The hard problem in 2D rendering (where objects are drawn in a user-determined order) isn't translucent blending of unsorted polygons, but conflation artifacts. If you have two adjacent squares where the first covers the left half of a pixel and the second covers the right half, and both are drawn with alpha blending, there will be background showing through which shouldn't exist, and too little influence from the first square's color. Similarly if you drawn two identical squares on top of each other, which both cover the left half of a pixel, the first square will have some influence over the background which shouldn't happen at all.

The lazy way to deal with this is to render at a high resolution and then scale down before displaying. Is there a better way?

Collect all polygons with influence over a pixel, then process the resulting lists pixel-parallel using exact math instead of trying to abuse a few planes of Z-buffered framebuffer to accumulate per-pixel state into a few numbers (while handling polygons virtually one-after-another, using some locking tactics of sorts to serialize their access to a single pixel's framebuffer values, if even that much concurrency-correctness is done).

> There’s a GPU-based solution to this, but it involves some compromises in quality.

There’s another GPU-based solution with RTX and other ray tracing solutions that is high quality. Might be compromising efficiency in some typical cases, unless a lot of geometry and/or instancing and/or samples are used, and then in that case it may be both an efficiency and quality win.

We really don't have the ray-budget for translucency with RTX. We basically only have the ray budget for a handful of rays per final screen pixel, and good translucency requires dozens for every interacting surface. There's a reason most engines using RTX only use it backed with a deferred style implementation.

If you’re talking about games, I agree, and there are multiple reasons, but generally speaking for viz or pure rendering or other cases, the budget might be bigger than you think. I’ve implemented real time transparency + path tracing in OptiX. Depends on your quality goals and denoiser options too, but several billion rays per second is a lot.

Is it actually not commutative? If you consider them to be filters in the same way you can with the article but on each RGB channel doesn't it still work out? Or is this assuming we're also dealing with reflection in addition to transmission? Or am I missing something entirely?

transparent red on top of blue means more red and less blue, transparent blue on top of red means the opposite

So we're assuming reflection as well as transmission?

If we're just talking transmission they would both be the same, ie transmitting all red photons and 50% of the green and blue ones while the other filter transmits all blue photons and 50% of the red/green ones. Either stack has 50% red values, 50% blue values and 25% green right?

Oh is sorting a bottleneck here?

Reply on news.ycombinator.com