After some brain-twisting, I did realize that even with z comparison off, OGL
probably rejecting the skydome because it's beyond the far clip plane. I've
been trying to
think of a way to fool this, but it seems like it is unavoidable.
Yeah, that's the conclusion I got to as well.
I wonder if there were somehow a callback you could apply somewhere that
would hork with
the near/far clip, or if it's just easier to use multiple cameras at that point.
I wonder where the near/far for final rendering are set. I'll
investigate this. I agree with your intuition, if we can find an
appropriate place where we could set a large value for the far plane,
then reset it to the previous value when the skydome is rendered then
that would work.
Perhaps in a Drawable DrawCallback? Something like:
struct MyDrawCallback : public osg::Drawable::DrawCallback
virtual void drawImplementation(osg::RenderInfo& renderInfo,
const osg::Drawable* drawable) const
// Save old values.
double left, right, bottom, top, zNear, zFar;
left, right, bottom, top, zNear, zFar;
// Set the far plane to a large value.
left, right, bottom, top, 1000, 10000);
// Reset the far plane to the old value.
left, right, bottom, top, zNear, zFar);
I'll test something like that out, in combination with the cull callback
for ignoring the skydome in the automatic near/far computation, tomorrow
when I get in the office.
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
osg-users mailing list