[HN Gopher] Implementing Order-Independent Transparency
___________________________________________________________________
Implementing Order-Independent Transparency
Author : ibobev
Score : 53 points
Date : 2024-11-11 11:48 UTC (11 hours ago)
(HTM) web link (osor.io)
(TXT) w3m dump (osor.io)
| eska wrote:
| The title could point out that this is about drawing of
| transparent objects in computer graphics
| VyseofArcadia wrote:
| 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?
| PhilipRoman wrote:
| For a moment I thought it was something cryptography related,
| like ZK proofs, etc.
| rolandog wrote:
| 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.
| dsp_person wrote:
| I would have clicked even faster if the title had "with
| Wavelets"
| slmjkdbtl wrote:
| 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.
| delusional wrote:
| 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.
| gmueckl wrote:
| 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.
| dsp_person wrote:
| 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.
| gmueckl wrote:
| 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.
| dsp_person wrote:
| 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 h
| ttps://interplayoflight.wordpress.com/2023/07/30/raytraced-
| ...
| Cieric wrote:
| 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
| msk-lywenn wrote:
| 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.
| figomore wrote:
| Can this be used in something like graphical APIS like OpenGL,
| Vulkan, WebGPU, etc?
| msk-lywenn wrote:
| Yes
| ImHereToVote wrote:
| Would be nice if there was a table that showed the performance
| benefit versus sorting the particles. Great article. Mind blowing
| actually.
| 01HNNWZ0MV43FF wrote:
| 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.
| jesse__ wrote:
| +1 for either slower moving or static comparison images
| jesse__ wrote:
| 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.
___________________________________________________________________
(page generated 2024-11-11 23:01 UTC)