Hi Roland,

The best I can suggest is to compute the required near and far planes for your other renderers then use this is the clamping of the near and far in OSG's cull traversal, then take its results back into setting the projection matrix of the other renderers. 

Alternatively do you own work to compute the near and far for all renderers yourself then apply the projection matrices and keep the compute near far off in the OSG.

Robert.

On 9/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:
Hello Robert,

we would prefer not to disable near/far planes to use the available
z-buffer resolution as good as possible.

The problem with overriding the clamping is, that this only helps, when
the near and far planes for all other renderers are known before the
culling step of OSG and the final projection matrix is then calculated
within the clamping callback.

This integrates quite badly with the rest of our rendering system. We
need to get the clipping planes from all renderers first. Then a new
projection matrix is calculated based on these clipping planes. This
matrix is finally used for rendering.

Best regards,
Roland

Robert Osfield schrieb:
> Hi Roland,
>
> You can disable the compute of the near far planes (see the FAQ), or
> override the clamping of the near far via methods in osgUtil::CullVisitor,
> you'll need to bit of digging as I can't recall the methods off the top of
> my head.
>
> Robert.
>
> On 9/26/06, [EMAIL PROTECTED] <
> [EMAIL PROTECTED]> wrote:
>>
>> Hello,
>>
>> Thanks for your answer. I think, using the bounding volume of the whole
>> scene won't help much. We want to use the scene graph to render objects
>> into terrain, which is drawn by our own renderer. So most of the time
>> the user will probably be within the scene graphs bounding volume.
>>
>> We considered using a fixed near plane, but would prefer to use a
>> dynamically calculated one, since the terrain mesh is quite big and we
>> would like to use the available z-resolution as optimal as possible.
>>
>> But if there is no other way, we will possibly use a fixed near plane.
>> The two other options, I see at the moment is either writing my own
>> visitor to find the near plane or using an really ugly hack to change
>> the projection matrix after the culling step.
>>
>> State seems to be ok at the moment, though I got the problem, that OSG
>> stops with an GL_ERROR, when an VertexBuffer is bound before its draw is
>> called. Possibly a bug?
>>
>> Best Regards,
>> Roland
>>
>> Paul Martz schrieb:
>> > Do you need to have OSG recompute the near/far planes? If not, I would
>> > disable it if I were you, and instead use the top-level bounding volume
>> in
>> > your computation of the global projection matrix.
>> >
>> > I used to maintain an application that had OSG as well as other
>> renderers. I
>> > did as described above: I created a projection matrix used by all
>> renderers
>> > based on the bounding volumes of all geometry in all renderers, and I
>> told
>> > the osgUtil::SceneView to not compute the near/far planes.
>> >
>> > (The bigger problem I ran into was managing state between all the
>> renderers,
>> > but that's another thread.)
>> >
>> > Best of luck with this,
>> >    -Paul
>> >
>> >
>> >> -----Original Message-----
>> >> From: [EMAIL PROTECTED]
>> >> [mailto:[EMAIL PROTECTED]] On Behalf Of
>> >> [EMAIL PROTECTED]
>> >> Sent: Tuesday, September 26, 2006 1:15 AM
>> >> To: [email protected]
>> >> Subject: [osg-users] Near/Far Clipping Plane when integrating
>> >> OSG withexternal renderers
>> >>
>> >> Hello,
>> >>
>> >> we would like to combine OSG with other renderers, which are
>> >> called independent from OpenScene Graph. The Problem is, that
>> >> for this to work, all renderers have to use the same near and
>> >> far clipping planes.
>> >>
>> >> To do this, we collect the near and far clipping planes,
>> >> required by the different renderers, before we start
>> >> rendering and combine them to an projection mMatrix, which is
>> >> then used by all renderers.
>> >>
>> >> At the moment I'm using osgUtil::SceneView to render the Scene Graph.
>> >> The problem is, that the clipping planes are calculated in
>> >> SceneView::cull. But after calling cull it seems to be
>> >> impossible to change the projection matrix again, as it is
>> >> already stored in the renderLeaf objects and a change has no
>> >> effect, before cull is called a second time.
>> >>
>> >> Is it possible to get the clipping planes independent from
>> >> the culling?
>> >> Or is it somehow possible, to change the projection matrix
>> >> after culling? Or would you generally recommend a completely
>> >> different approach to combine OSG with other renderers?
>> >>
>> >> We already considered integrating the other renderers in
>> >> Scene Graph nodes, but would prefer, to keep them apart to
>> >> reduce the dependence on each other.
>> >>
>> >> Best Regards,
>> >> Roland
>> >> _______________________________________________
>> >> osg-users mailing list
>> >> [email protected]
>> >> http://openscenegraph.net/mailman/listinfo/osg-users
>> >> http://www.openscenegraph.org/
>> >
>> > _______________________________________________
>> > osg-users mailing list
>> > [email protected]
>> > http://openscenegraph.net/mailman/listinfo/osg-users
>> > http://www.openscenegraph.org/
>> >
>> >
>> _______________________________________________
>> osg-users mailing list
>> [email protected]
>> http://openscenegraph.net/mailman/listinfo/osg-users
>> http://www.openscenegraph.org/
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to