[osg-users] Update to Depth Patitioner

[Ravi Mathur]

Hi all,

A looong time ago I had created the DepthPartitionNode, which split up an OSG scene into multiple depth partitions and rendered them with multiple cameras. This turned into the original osgdepthpartition example. My implementation created nested cameras, which worked fine at the time, but posed some problems with shadows. The solution to this was to use slave cameras, and eventually my DepthPartitionNode was removed from OSG in favor of the dual slave camera approach that is currently in osgViewer::View.

Recently I've gotten back into OSG-related development, and my first task has been to rewrite the DepthPartitionNode. I've created a new DepthPartitioner class which dynamically creates and manages slave cameras for a given osgViewer::View.  A few features of the new DepthPartitioner class: 


*Creates its own "main" slave camera, and attaches a slave update callback that dynamically creates additional slaves to render depth partitions. Important to note that it doesn't mess with any callbacks that may be installed on the View's master camera.

*Obeys the relevant settings of the View's master camera. e.g. near/far ratio, graphics context, viewport, view/projection matrices (except depth of course).

*Disables its unused slave cameras instead of destroying them, since the osg::Camera is lightweight.

*Cleans up after itself when you no longer need to depth-partition the osgViewer::View.

*Specify a minimum zNear that will never be violated. This is useful for VR applications where you really don't want anything drawn closer than a few cm from the eye.

* Customize how slave cameras are created. By default one camera is created per depth partition, but this can be overridden to create stereo cameras per partition for rendering unlimited depth precision within VR. I've done this, and it's VERY cool to sit on a satellite with the Vive and watch other satellites in your constellation move around you while you orbit the Earth.


I was wondering, is there interest in this for the general OSG community? Currently it resides as a part of my own Open Source OSG-based API, but I would be happy to contribute it as standalone code to OSG.

Thanks!
Ravi

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70967#70967