Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris,
I assume the call to traverse() is what actually adds the skydome to the
render graph, so I'd need to trace down into that right?
I traced down into that, and the drawables are added to the graph... It
goes down to
inline void CullVisitor::addDrawableAndDepth(
osg::Drawable* drawable,osg::RefMatrix* matrix,float depth)
{
// ...
_currentStateGraph-addLeaf(createOrReuseRenderLeaf(
drawable,_projectionStack.back().get(),matrix,depth));
}
and adds them. So it seems that they should be drawn.
I think the problem is that the skydome is being clipped by OpenGL
before rasterization. I think there's no real way to get around that,
because the dome is really big and the near/far computed are really
small. So I think my only real solution is the additional camera.
What do you think?
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
On Wed, Apr 22, 2009 at 4:36 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Jean-Sébastien Guay wrote: I just had a thought, could the object on which this callback is set have any influence on the results? Should I set the cull callback on the Geode, or will any parent node do? I was setting it on the parent node of my skydome, which is a MatrixTransform. Perhaps that had some influence... I no longer recall how I handled that, but I think I had a MatrixTransform up there too. I think I'd ask Robert if you're barking up the wrong tree. A little theory validation goes a long way. Can't add anything really, this has been a long and twisting thread. Only things I can think of adding is perhaps adding the ability to manually set the compute near/far that the CullVisitor would be appropriate change. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chuck, Although not an optimal solution, and probably more of a work-around to your question ... I use a skydome as well. In my case, I just create a sphere whose radius is that (or a little less than that) of the camera's far-field value, which I've set to be quite large (60,000-meters). This works for my use case. But again, it's not an optimal solution. I'd also be interested in a more optimal and scalable solution. I prefer letting OSG manage my near+far planes according to the geometry in my scene, that way I can have optimal depth precision in pretty much all situations. The problem here is that this particular node should not be part of those calculations (I've set it to always win the depth test and render first, so that transparency with it works and it will be drawn even if the far plane is closer than its surface). Thanks for your suggestion though. Anybody else have an idea? I just had a thought, perhaps I could make a ComputeBoundCallback that would return a very small bounding sphere, and disable culling on the skydome... I'll try that and report how it goes. J-S chuck -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 21, 2009 12:13 PM To: OpenSceneGraph Users Subject: [osg-users] Geometry considered in near+far plane auto computation Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be in the world - if I use the same trick as for a skybox (moving the cube with the camera) it will look like the horizon moves up relative to the terrain if I move the camera higher in altitude... Not a desirable effect. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi JS, Hows about using a cull callback that caches the compute near/far values before traversing the subgaph then restores the value afterwards, it'd only take a couple of lines of code. Robert. On Tue, Apr 21, 2009 at 6:55 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Chuck, Although not an optimal solution, and probably more of a work-around to your question ... I use a skydome as well. In my case, I just create a sphere whose radius is that (or a little less than that) of the camera's far-field value, which I've set to be quite large (60,000-meters). This works for my use case. But again, it's not an optimal solution. I'd also be interested in a more optimal and scalable solution. I prefer letting OSG manage my near+far planes according to the geometry in my scene, that way I can have optimal depth precision in pretty much all situations. The problem here is that this particular node should not be part of those calculations (I've set it to always win the depth test and render first, so that transparency with it works and it will be drawn even if the far plane is closer than its surface). Thanks for your suggestion though. Anybody else have an idea? I just had a thought, perhaps I could make a ComputeBoundCallback that would return a very small bounding sphere, and disable culling on the skydome... I'll try that and report how it goes. J-S chuck -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 21, 2009 12:13 PM To: OpenSceneGraph Users Subject: [osg-users] Geometry considered in near+far plane auto computation Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be in the world - if I use the same trick as for a skybox (moving the cube with the camera) it will look like the horizon moves up relative to the terrain if I move the camera higher in altitude... Not a desirable effect. J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Robert, Hows about using a cull callback that caches the compute near/far values before traversing the subgaph then restores the value afterwards, it'd only take a couple of lines of code. Hmm, another interesting approach. I'll try it. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Robert,
Hows about using a cull callback that caches the compute near/far
values before traversing the subgaph then restores the value
afterwards, it'd only take a couple of lines of code.
Unless I'm reading the headers wrong, there is no setter for the
computed near and far values? Only getters?
inline value_type getCalculatedNearPlane() const {
return _computed_znear; }
inline value_type getCalculatedFarPlane() const {
return _computed_zfar; }
I don't see anything that sets _computed_znear and _computed_zfar except
for methods that do actual calculations, like updateCalculatedNearFar(...) .
Is there some other way of doing what you're suggesting that I'm missing?
Otherwise, I guess I could cache and reset the ComputeNearFarMode like this:
class DoNotIncludeInNearFarComputationCallback
: public osg::NodeCallback
{
public:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor *cv =
dynamic_cast osgUtil::CullVisitor*( nv );
// Default value
osg::CullSettings::ComputeNearFarMode oldMode =
osg::CullSettings::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES;
if( cv )
{
oldMode = cv-getComputeNearFarMode();
cv-setComputeNearFarMode(
osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
}
traverse(node, nv);
if( cv )
{
cv-setComputeNearFarMode(oldMode);
}
}
};
Does that look like something that could work? (it doesn't seem to at
first glance, but maybe I'm doing something wrong)
Thanks,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi J-S -- I have a similar issue in one of my apps. I have a large scene (VPB database) with some geometry right in front of the eye (which I draw in eye coordinate space). So the near plane must be very close to the eye and the far plane extremely distant. I currently disable autocompute and set a large far plane value and a small near plane value, but this results in z fighting. To solve this in OpenGL, I'd use two projection matrices, one for the planet and one for the very close eye space geometry. The equivalent to this in OpenGL would be to use two Camera nodes. I haven't had time to code this up yet, but I'm certain it will address the issue. The first camera will auto compute near and far based on the planet, then the second camera will clear the depth buffer, will auto compute based on the eye space geometry, and will render that geometry. Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. (By the way, to set the near and far plane values, you set the projection matrix. OSG abstracts this away to make them look like two separate concepts, which is why we have a FAQ on why does OSG seem to ignore my near and far values? The answer is that OSG, by default, autocomputes the near and far planes and overrides those values as set by an application that explicitly sets the projection matrix.) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 21, 2009 10:13 AM To: OpenSceneGraph Users Subject: [osg-users] Geometry considered in near+far plane auto computation Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be in the world - if I use the same trick as for a skybox (moving the cube with the camera) it will look like the horizon moves up relative to the terrain if I move the camera higher in altitude... Not a desirable effect. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Paul Martz wrote: Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. Maybe I'm missing something, but usually a skydome doesn't need z-buffering at all. Backface culling is sufficient for when you're inside a tessellated sphere, so you can just clear the z-buffer, turn off Z writes/compares, render the skydome, turn on z-write/compare and render the actual scene. Am I overlooking something? This has always worked for me. Concerning the huge-world-with-near-objects z-fighting problem, yeah, I've always fought with that issue. I've thought about looking at some way to mess with the z-write in a fragment shader so that it scales the z-distance according to some rule other than the (exponential?) one it uses now. That way you could have very near clip planes without wasting all of your z precision up front. But I've never tried implementing it, and I don't know if the programmable pipeline would let me get away with it. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Paul, I currently disable autocompute and set a large far plane value and a small near plane value, but this results in z fighting. That's exactly what I'm hoping to avoid. The equivalent to this in OpenGL would be to use two Camera nodes. [...] Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. Yes, that seems like it could work. I'll look into it. (By the way, to set the near and far plane values, you set the projection matrix. OSG abstracts this away to make them look like two separate concepts, which is why we have a FAQ on why does OSG seem to ignore my near and far values? The answer is that OSG, by default, autocomputes the near and far planes and overrides those values as set by an application that explicitly sets the projection matrix.) I'm familiar with the projection matrix and the auto compute modes... I don't want to set the actual near and far plane values, I want to set the values that the CullVisitor computes... It seems to me that the computed values will be computed completely before any actual drawing occurs, so setting the near/far myself won't change anything since the auto compute will then overwrite my values. I'm basically looking for a way for my skydome not to affect the calculated near/far values. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris, Maybe I'm missing something, but usually a skydome doesn't need z-buffering at all. Backface culling is sufficient for when you're inside a tessellated sphere, so you can just clear the z-buffer, turn off Z writes/compares, render the skydome, turn on z-write/compare and render the actual scene. Am I overlooking something? This has always worked for me. Nope, that's exactly what I'm doing, the problem is that OSG still uses the skydome when auto-computing the near+far planes for the other objects in the scene. And I need the dome to be really big, otherwise I get the problem I mentioned earlier (when moving away from the ground in altitude, the dome will seem like it's not touching the horizon anymore). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote: Nope, that's exactly what I'm doing, the problem is that OSG still uses the skydome when auto-computing the near+far planes for the other objects in the scene. And I need the dome to be really big, otherwise I get the problem I mentioned earlier (when moving away from the ground in altitude, the dome will seem like it's not touching the horizon anymore). Yeah, but I had a way to avoid this. Let me look at my code again... J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Chris 'Xenon' Hanson wrote: Yeah, but I had a way to avoid this. Let me look at my code again... From memory, can't you create a NodeCallback that checks to see if it's being traversed by a CullVisitor (dynamic-cast the NodeVisitor) and if so, temporarily switch off the near/far computation, traverse the node/subgraph, and then turn it back on? J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris, From memory, can't you create a NodeCallback that checks to see if it's being traversed by a CullVisitor (dynamic-cast the NodeVisitor) and if so, temporarily switch off the near/far computation, traverse the node/subgraph, and then turn it back on? That's what I've done (see a previous post in this thread) but it didn't work for some reason - the subgraph was never rendered. I've done what Paul suggested: the skydome is under a PRE_RENDER camera and so has its own projection matrix and thus, doesn't affect the computed near/far values for the main camera. It works, but it has more implications on the rest of my scene graph/viewer setup than I'd like. All other cameras need to be set to only clear the depth buffer otherwise they'll clear my skydome (of course) and since in my app, views may be added at any time, this introduces an extra required step when creating a view... I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
J-S (and others),
You could look at doing this is the same way the depth partition node does
it, which is what I do:
I use a class based on an OSG camera with an overriden traverse method, that
forces the projection matrix to a particular z near and z far. Oh, and the
camera has setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR)
in its constructor. The skydome is then a child of this camera.
You then set the z near and z far to be whatever you want (i.e. enveloping
your skydome radius). I typically have a skydome with a radius of 1
void CExtentsCamera::traverse(osg::NodeVisitor nv)
{
// If the scene hasn't been defined (i.e. we have no children at all)
then don't do anything
if(_children.size() == 0) return;
// If the visitor is not a cull visitor, then we are not interested in
intercepting it, so pass it directly onto the scene.
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*(nv);
if(!cv)
{
Camera::traverse(nv);
return;
}
// Get a reference to the Cull Visitor's projection matrix
osg::Matrix* projection = cv-getProjectionMatrix();
// NB : This might be possible to simplify and hence optimise (haven't
yet checked)
double a = (*projection)(2,2);
double b = (*projection)(3,2);
double c = (*projection)(2,3);
double d = (*projection)(3,3);
double trans_near = (-_zNear*a + b) / (-_zNear*c + d);
double trans_far = ( -_zFar*a + b) / ( -_zFar*c + d);
double ratio = fabs(2.0/(trans_near - trans_far));
double center = -0.5*(trans_near + trans_far);
// Set the projection matrix
projection-postMult(osg::Matrixd(1.0, 0.0, 0.0,0.0,
0.0, 1.0, 0.0,0.0,
0.0, 0.0, ratio,0.0,
0.0, 0.0, center*ratio, 1.0));
Camera::traverse(nv);
}
Probably a better way of doing it, but it works fine for me.
I also do this on the camera's stateset
{
osg::Depth* depth = new osg::Depth;
depth-setFunction(osg::Depth::LEQUAL);
depth-setRange(1.0,1.0);
stateSet-setAttributeAndModes(depth,osg::StateAttribute::ON );
}
so that you can render the sky last, and any expensive pixel shaders don't
get unnecessarily run.
Hope that helps,
David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote: That's what I've done (see a previous post in this thread) but it didn't work for some reason - the subgraph was never rendered. Ok. I stepped into the conversation late. I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Yeah, that should be the way to do it. Did you copy a working recipe or wing it from scratch? Thanks, J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris, I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Yeah, that should be the way to do it. Did you copy a working recipe or wing it from scratch? From scratch, I couldn't find another cull callback that did things before and after the traverse() in the examples... Any suggestions? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote: Otherwise, I guess I could cache and reset the ComputeNearFarMode like this: Does that look like something that could work? (it doesn't seem to at first glance, but maybe I'm doing something wrong) It looks exactly like I'd expect it to be. I think you can omit setting the oldMode default value even. Have you debugged it to keep an eye on what happens to the near/far values when it runs through? I wonder if the Cull is somehow not adding the skydome to the render graph? Have you been successful in just loading a new near/far value manually? If so, what if you cache the far value from here externally, then manually load it prior to rendering, and see if it renders your skydome. Thanks, J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote:
From scratch, I couldn't find another cull callback that did things
before and after the traverse() in the examples... Any suggestions?
I dug back into my e-mail archives and found a message from Robert on
10/7/2003 that I
used as my inspiration:
There isn't at present a away to disable the computation of the near far for a
subgraph via settings on Node's. However, what you might be able to try
would be to disable the near far computation via a NodeCallback attached to
the skydome subgraph. Something like
struct MyCullCallback : public osg::NodeCallback
{
virtual void operator()(Node* node, NodeVisitor* nv)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
osgUtil::CullVisitor::ComputeNearFarMode saveComputeNearFar;
if (cv)
{
saveComputeNearFar = cv-getComputeNearFarMode()
cv-setComputeNearFarMode(
osgUtil::CullVisitor::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES);
}
traverse(node,nv);
if (cv)
{
saveComputeNearFar = cv-getComputeNearFarMode()
cv-setComputeNearFarMode(saveComputeNearFar);
}
}
}
Now, there's some missing semicolons there, but those are easy to fix. Oddly
though, it
looks like he's recommending switching to
COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES and I
think it should be DO_NOT_COMPUTE_NEAR_FAR. Also, the lower saveComputeNearFar =
cv-getComputeNearFarMode() should not be there. But, I think this demonstrates
you're on
the right track, and maybe just need to debug what's really happening at
runtime.
J-S
--
Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris, I dug back into my e-mail archives and found a message from Robert on 10/7/2003 that I used as my inspiration: Thanks for digging that up. Indeed, after the corrections you mention, it looks almost exactly like what I have. But, I think this demonstrates you're on the right track, and maybe just need to debug what's really happening at runtime. Well, I've confirmed at least that the cull callback operator() is called at run time and that the dynamic_cast succeeds, so I just need to know what to check for to make sure my geometry would be rendered... I've never had to debug a cull callback before, what would you suggest I check for? Which of the CullVisitor's variables should I keep an eye on? I assume the call to traverse() is what actually adds the skydome to the render graph, so I'd need to trace down into that right? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi again, I dug back into my e-mail archives and found a message from Robert on 10/7/2003 that I used as my inspiration: Thanks for digging that up. Indeed, after the corrections you mention, it looks almost exactly like what I have. I just had a thought, could the object on which this callback is set have any influence on the results? Should I set the cull callback on the Geode, or will any parent node do? I was setting it on the parent node of my skydome, which is a MatrixTransform. Perhaps that had some influence... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
