Dirk Reiners wrote: > Hi Marcus, > > Marcus Lindblom wrote: >> Depth peeling. It requires many render passes and custom shaders, but it >> will give fast and correct out-of-order rendering of transparent >> intersecting trianglers. > I've been thinking about putting DP into the system for a while, but > haven't got around to it.
It'd think it would be hard to do generic, as it requires custom shaders. (You need to read depth from a texture sampler and check whether to discard the current pixel.) However, a SimpleDepthPeelMaterial might be doable, if it has explicit TextureChunk field(s) for input depth. You'd also need a DepthPeelComposeViewport. It won't work if you start doing custom stuff (we placed some effects in the compose pass to avoid rendering extra alpha-blended full screen polys) but it might help devs get started. >> Yeah. I've been offline for a few weeks due to a wisdom tooth, and then >> I've switched jobs. Anyway, that link doesn't work for me. :( >> > Hope your tooth trouble is finished. I got rid of two a long time ago > and I'm hoping the other two stay quiet... > > What;s your new job? I'm lead developer at ORZone, a startup that will still work in the medical field (as did my previous company, Mentice), but with focus on operation planning support and team-training (as opposed to realistic simulation trainers for individual operators). We're defining our product line along with all techicnal stuff (i.e. decide on languages, third-party libs/apps (OpenSG is in the plan :), build environment etc). I'm thinking about Python, Maya, Qt, VTK etc, but nothing is set in stone yet. Very exciting times. :-D >> Anyway, I did try with BSP sorting (recreating indices as you say) but >> as we had dynamic transparent geometry it wasn't fast enough at all. >> Depth-peeling worked like a charm (we only needed 3-4 layers to render >> our rather simple but heavily intersecting geometry). >> > How hard was it to integrate that? Would you be able to provide a simple > example program that shows how to do it? Well, most of it was implemented in the XML-scripting layer, so it would take some work to convert it to C++. Also, I don't have access to that source anymore. :( However, I think one should be able to understand how it works from some cut'n paste of that (it is very transparent). I know there is at least one fellow at Mentice reading this list (Hi Shahrouz! :), but he's working part-time until end-of-year so I don't know if he has time time to post the XML code & some shaders to the list. But the work in OpenSG is very straight-forward if you know how depth-peeling works. For N depth-peel layers, you need something like: * a number of depth & color textures (1 + N of each) * a number of FBOViewports (1 + N) and regular one (compose to framebuffer) * custom shaders for rendering with depth-peeling (that reads depth from previous pass and decides whether to discard the pixel) * a custom compose pass that blends all layers together (in the regular viewport) checking depth I also used the trav-mask to simplify the scene-graph a bit, by keeping the light and some common stuff near the root, then setting up 5 nodes with trav-masks under which I put geometry with different shaders: * 1 - opaque geometry * 2 - first depth peel layer * 4/8 - intermediate layers * 16 - final layer (render remaining layers without sorting) Cheers, /Marcus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
