So 16 coefficients are stored for a rank 3 wavelet function.
With 16 DoF, can you handle more overlapping objects than a 16-long per-pixel list?
Without fully understanding it, this reminds me of spherical harmonics in the way that juggling around the channels is convenient but it's not magic, you can only do so much with X degrees of freedom. (SH is a really nice way to store a low-res cubemap, but you would never use SH for env maps on something shiny) In the case of SH there are also artifacts introduced. I wonder how the wavelets behave when pushed too hard?
Also, trying to be constructive - If there were still images with objects lined-up so we could compare the different techniques with a reference and see the difference, that would be easier to read than a lot of fast-moving randomly-colored objects.
This is the first real brick wall I met when learning computer graphics, interesting how seemingly simple things in computer graphics is actually non-trivial.
That's probably the one thing I love the most about computer science. Every simple problem ends up being surprisingly complicated once you dive deep into the exact details.
I remember when I was looking into this at one point in time. I was trying to figure out a good implementation that didn't require you to store multiple different positions. The most I really ever got was a reverse order transparency [1] which employs some stuff similar to the article.
My plan was basically render everything opaque first, then render transparency front to back till the layer became opaque (discard all pixels under an already opaque pixel), and of course exclude everything further away than the depth buffer of the opaque layer.
Might be interesting to actually go and finish the implementation to test it out, I just never had a good test scene with a lot of transparency (with an opaque layer since half my benefit comes from that.)
You probably want to render back to front. Also, that’s the first part of the problem. OIT solves the case where meshes and even triangles cross each other too.
Fantastic read. I did OIT a while back in my engine that does basically this, but with a much simpler transmittance function. Very cute idea to use wavelets to encode the transmittance.
I don't understand why raytracing is rejected out of hand. It never defines the target hardware range, but the 3080 is very fast at hardware ray tracing. Ray tracing pipeline objects also solve the coupling issue the article complains about because shading can be moved into the closest hit shaders, which the pipeline can have many of and they can be assigned per geometry in the TLAS.
I actually expect that a raytracing based implementation is more accurate with about the same performance as the shown implementation.
In the referenced paper https://arxiv.org/pdf/2201.00094 in section 2 they give a couple examples for why not ray tracing. Also FWIW they used an RTX3090 in the performance comparison section.
I need to run some more numbers, but the dismissal of raytracing on performance grounds seems inaccurate to me at first glance. Note that they inflate the number of ray intersections by including shadow tests. That number shrinks dramatically when you ignore shadowing and refraction as the final implementation does.
A lot of modern AAA games use dithering transparency. It doesn't suffer from ordering problems. Although it looks weird in low resolution, it looks fine in high resolution.
As I've been thinking about transparency and accountability within governments and organizations, I went into the article expecing something I had never pondered about those subjects.
This is (supposed to be) a tech forum, and when limited to tech there's not much else this could be about besides graphics, so I think the title is fine.
Oh, for sure. I also think that we're tinkerers or hackers... and we lean on tech to scratch an itch or solve a problem. Mostly because we thought it would be easy ;-)
What about the case of something fairly translucent in front of some particles that accumulate to an opaque surface (Say a balloon in front of very dark factory smoke). How would the shader "know" what the final color output was?
So 16 coefficients are stored for a rank 3 wavelet function.
With 16 DoF, can you handle more overlapping objects than a 16-long per-pixel list?
Without fully understanding it, this reminds me of spherical harmonics in the way that juggling around the channels is convenient but it's not magic, you can only do so much with X degrees of freedom. (SH is a really nice way to store a low-res cubemap, but you would never use SH for env maps on something shiny) In the case of SH there are also artifacts introduced. I wonder how the wavelets behave when pushed too hard?
Also, trying to be constructive - If there were still images with objects lined-up so we could compare the different techniques with a reference and see the difference, that would be easier to read than a lot of fast-moving randomly-colored objects.
+1 for either slower moving or static comparison images
This is the first real brick wall I met when learning computer graphics, interesting how seemingly simple things in computer graphics is actually non-trivial.
That's probably the one thing I love the most about computer science. Every simple problem ends up being surprisingly complicated once you dive deep into the exact details.
I remember when I was looking into this at one point in time. I was trying to figure out a good implementation that didn't require you to store multiple different positions. The most I really ever got was a reverse order transparency [1] which employs some stuff similar to the article.
My plan was basically render everything opaque first, then render transparency front to back till the layer became opaque (discard all pixels under an already opaque pixel), and of course exclude everything further away than the depth buffer of the opaque layer.
Might be interesting to actually go and finish the implementation to test it out, I just never had a good test scene with a lot of transparency (with an opaque layer since half my benefit comes from that.)
[1] https://www.shadertoy.com/view/msyGDR
You probably want to render back to front. Also, that’s the first part of the problem. OIT solves the case where meshes and even triangles cross each other too.
Fantastic read. I did OIT a while back in my engine that does basically this, but with a much simpler transmittance function. Very cute idea to use wavelets to encode the transmittance.
I don't understand why raytracing is rejected out of hand. It never defines the target hardware range, but the 3080 is very fast at hardware ray tracing. Ray tracing pipeline objects also solve the coupling issue the article complains about because shading can be moved into the closest hit shaders, which the pipeline can have many of and they can be assigned per geometry in the TLAS.
I actually expect that a raytracing based implementation is more accurate with about the same performance as the shown implementation.
In the referenced paper https://arxiv.org/pdf/2201.00094 in section 2 they give a couple examples for why not ray tracing. Also FWIW they used an RTX3090 in the performance comparison section.
I need to run some more numbers, but the dismissal of raytracing on performance grounds seems inaccurate to me at first glance. Note that they inflate the number of ray intersections by including shadow tests. That number shrinks dramatically when you ignore shadowing and refraction as the final implementation does.
it would be cool to see a more comprehensive comparison including methods with raytracing
they have MLAB in their performance comparison table, is that ray traced? from this blog i think it sounds like it there's a rasterized version and a way to use ray tracing https://interplayoflight.wordpress.com/2023/07/30/raytraced-...
Would be nice if there was a table that showed the performance benefit versus sorting the particles. Great article. Mind blowing actually.
A lot of modern AAA games use dithering transparency. It doesn't suffer from ordering problems. Although it looks weird in low resolution, it looks fine in high resolution.
The title could point out that this is about drawing of transparent objects in computer graphics
To me it was obvious that's what "Implementing Order-Independent Transparency" would be about. No other possible subject crossed my mind.
Out of curiosity, what did you think it would be about?
As I've been thinking about transparency and accountability within governments and organizations, I went into the article expecing something I had never pondered about those subjects.
This is (supposed to be) a tech forum, and when limited to tech there's not much else this could be about besides graphics, so I think the title is fine.
Oh, for sure. I also think that we're tinkerers or hackers... and we lean on tech to scratch an itch or solve a problem. Mostly because we thought it would be easy ;-)
For a moment I thought it was something cryptography related, like ZK proofs, etc.
I would have clicked even faster if the title had "with Wavelets"
Can this be used in something like graphical APIS like OpenGL, Vulkan, WebGPU, etc?
Yes
What about the case of something fairly translucent in front of some particles that accumulate to an opaque surface (Say a balloon in front of very dark factory smoke). How would the shader "know" what the final color output was?