Hi Chris, On Fri, May 15, 2009 at 2:10 AM, Chris 'Xenon' Hanson <xe...@alphapixel.com> wrote: > 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.
Depth partioning then :-) > 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. So you're simulating using two slave Camera's for each of the depth ranges. osgViewer is capable of doing depth partioning although the osgdepthpartition example hasn't yet been ported across to take advantage of the flexibility of osgViewer, it is something on my TODO list. By putting the management of the dept partitioning into the viewer rather than the scene you remove viewing specific code form the scene graph, and make it possible to load any scene into the viewer and have it manage the depth partitioning automatically. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
