Hi Guy,<br><br>Personally I'd like change the osgdepthpartion example across to using a series of viewer slave cameras, rather than in scene graph cameras.  In the future I hope to add this support doing effects like stereo and depth partition as an integral part of the osgViewer library (stereo is suppported via the lower level SceneView right now) so that these effects can be requsted via viewer configuration.  I have plenty of other tasks on my plate right now so can't tackle these yet, but it's useful for you to know where I'm going with this support.<br>
<br><div class="gmail_quote">On Mon, Mar 23, 2009 at 2:46 PM, Guy <span dir="ltr"><<a href="mailto:guy@dvp.co.il">guy@dvp.co.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 In the depth partition example, the class DepthPartitionNode allows<br>
changing the render order of the camera to PRE/NESTED but then the<br>
calculation of the RenderBin leaves is incorrect. <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 
What is the logic for changing the cameras order?<br>
</blockquote><div><br>You have to render the cameras from back to front so rendering order is critical.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 
Besides I would like to know what are the disadvantages of using<br>
DepthPartitionNode in ALL osg based application? Does is have problems<br>
with HUDS or transparency?<br>
</blockquote></div><br>The main problem is that your traversing the scene multiple times to cull for each for cameras so CPU overhead is up and require extra buffer clears and rendering so it impacts performance.  Depth partitioning is a niche requirement, only essential in small subset of applications so is not appropriate to add in by default.<br>
<br>Robert.<br>