We currently do accurate transparency using BSP. Is there any more simple way to do it with shaders?
Thanks,
Alberto
We currently do accurate transparency using BSP. Is there any more simple way to do it with shaders?
Thanks,
Alberto
You could look for order independent transparency, you can find things like:
http://developer.download.nvidia.com...pthPeeling.pdf
Thanks, is this what most recent 3D graphics program use for transparency? Do you know any famous 3D graphics program using this approach, we would like to see it in action.
Alberto
Sorry, I don't know. I have the impression that this kind of approaches are not yet common, and they may still be expensive.
Only recently I learned about the "weighted average" fast approximation, I find it is a neat trick if perfect results are not needed :
http://www.slideshare.net/acbess/ord...y-presentation
Very nice and clear, thanks a lot ZbuffeR!
Besides multi-pass depth peeling approaches, there's also been some papers/presentations out recently doing A-buffers on the GPU. Essentially single-pass OIT (with some constraints). For instance, there was a cool presentation last year at SIGGRAPH doing smoke/clouds/translucent volume shadows (google Adaptive Volumetric Shadow Maps). Stores a few samples per fragment to represent a piecewise-linear visibility function. I think ATI's OIT demo a year or so ago did A-buffer too (google ATI OIT to get right to it). That said, I personally haven't implemented A-buffer on the GPU yet. Let me know how it goes!
But seriously, it's worth giving a serious think to how translucency occurs in and can be constrained in your world. With just a few assumptions/limits, you may find you don't need some super-fancy sub-pixel-sorted-blending-accurate technique that handles intersecting triangles between or within objects or arbitrary volumetric transparency with full refraction, internal reflections, subsurface scattering, and cross-translucent-volume global illumination lighting interactions. Ray tracing anyone? It may be cost/benefit cheaper to resolve certain issues using other approaches.
Besides intersection permutations (that you can't preprocess away), other things to consider: are your translucent objects all effectively 2D (flat sheets, like windows, canopies, etc.)? If not, are they convex? How are you modeling transmission through the medium (e.g. refraction, color shifting, scattering, etc.)? If objects intersect, do the component triangles of those objects intersect? Do you model partial reflection (e.g. fresnel reflectance)?
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?
Why aren't you doing BSP at triangle level?Pitty most model formats aren't actually BSP trees
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.
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.Originally Posted by devdept
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:
Posting Permissions
