Paul Martz wrote: > I Robert -- No, I don't think stencil applies here. Chris might not have > described the rendering task precisely. What he is trying to do is a sort of > smart depth partition, in which he knows that part of his scene graph is > always the background, and another part of always the foreground.
Paul is right. I tried to simplify it to make it easier to explain, but probably messed it up. I will expand on the abstract explanation, and then reveal my optimal solution -- which is a bit of a hack, but is still the most elegant. Basically we have VPB terrain for a very large area, but low detail. Within it, we have a smaller world, which the user cannot leave. This terrain is also built with VPB, at a much higher detail. This small world needs to be rebuilt frequently with different data, and we don't wish to rebuild the entire surrounding world each time. this is because the surrounding world doesn't change, and we don't want to spend all the time rebuilding the surrounding world to the same degree of detail as the inset local world. It's kind of like a skydome/box/environment technique, but it's a world-dome/box/environment. It has to be rendered with Z-test and Z-write enabled to sort out self-occlusion, whereas a skydome can often skip Z-test/z-write as long as it's a sphere and you use backface culling. The solution is to render the surrounding world, then wipe the Z-buffer, then render the local world. this means that even if the local world terrain surface drops below the surrounding world in the middle, it still obscures the exterior world. Things could get weird close to the edge of the local world, but we prevent that from being an issue by restrictions on the local world and near-edge movement. What I did was this: Render surrounding world in RenderBin -3. Create an empty piece of dummy Geometry (with a Geode) and render it in RenderBin -2. Render the local world in RenderBin -1. The dummy geometry has a draw callback on it that issues a raw OpenGL glClear() only on the Z-buffer channel. It doesn't disrupt the OpenGL state in any way, just wipes the Z-buffer. It works great. no second cameras to track, no RTT, no goofy stuff. The only cost is a full-screen Z-clear operation. Thanks to everyone for their suggestions. BTW, should we document that there really should only be one ClearNode in the scene graph at a time, and what effect exactly it actually has? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
