Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi again Chuck, Thanks again. All of my apps have been "flight sim"-like apps, so a large radius is required. But I do things differently. I may try your approach and see if I can get better performance while still keeping relevant and viewable information from being culled. Actually, thinking about it, it should work there too. Since the skydome is setting fragments at the far plane after all other opaque objects have been rendered, and the really large far plane value will only affect the skydome itself, no z-fighting between the skydome and anything else should occur. Try it if you want, and let us (me :-) ) know how it goes. 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] Geometryconsidered in near+far plane auto computation
Hi J-S, > I just realized I didn't give you actual information, just how we get > the values... The radius turns out to be around 5000m most of the time. > In our simulators, most of the time the user will stay in an area about > 100mx100m in the center of the scene, so this works well. I think if we > were to make a flight sim where the user can travel large distances > this > wouldn't work and we'd need to do it differently. Thanks again. All of my apps have been "flight sim"-like apps, so a large radius is required. But I do things differently. I may try your approach and see if I can get better performance while still keeping relevant and viewable information from being culled. chuck ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi Chuck, I do have one question though out of curiosity ... what dimensions (particularly the radius) did you use to generate the skydome? I see that you use the radius to determine the far plane value, but didn't know what you used. I'm assuming that it has to be great enough to still be viewed as being far field. I just realized I didn't give you actual information, just how we get the values... The radius turns out to be around 5000m most of the time. In our simulators, most of the time the user will stay in an area about 100mx100m in the center of the scene, so this works well. I think if we were to make a flight sim where the user can travel large distances this wouldn't work and we'd need to do it differently. Hope this helps, 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] Geometryconsidered in near+far plane auto computation
Hi Chuck, Glad I can give useful and interesting information :-) I do have one question though out of curiosity ... what dimensions (particularly the radius) did you use to generate the skydome? I see that you use the radius to determine the far plane value, but didn't know what you used. I'm assuming that it has to be great enough to still be viewed as being far field. As I said in another thread, I generally place my skydome at the (x,y) of the complete scene's bounding sphere, with z = 0, and with a radius that encompasses the whole scene (so the scene's bounding sphere's radius). That's in our simulators, so we need values that work for all scenes, and that works for us. In another application we give control over the values (it's kind of like a content creation app, so users might want to tweak them). Hope this helps, 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] Geometryconsidered in near+far plane auto computation
Hi J-S, Thanks for keeping this post going with what you've done. I've been keeping an eye on it with keen interest. I do have one question though out of curiosity ... what dimensions (particularly the radius) did you use to generate the skydome? I see that you use the radius to determine the far plane value, but didn't know what you used. I'm assuming that it has to be great enough to still be viewed as being far field. Thanks. 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 28, 2009 10:14 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Geometryconsidered in near+far plane auto > computation > > Hello Chris, > > >> 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. > > > > Perhaps in a Drawable DrawCallback? Something like: > > OK, I've finally got this to work well, without the need to add an > extra > camera. It's a classic two-pronged attack: > > 1. Use a CullCallback that sets the compute near/far mode to off, > traverses the skydome and resets it to the previous value. > 2. Use a drawable DrawCallback on all the skydome's drawables that will > calculate the maximum possible value the far plane would need to be at > for the skydome to be visible from the current camera position, draws > the drawable, and resets the old far plane after drawing. > > One thing I found I needed to do is keep the same near plane value as > was set before, otherwise the skydome seemed to move when the camera > moved. > > Here's the code I'm using: > > struct DoNotIncludeInNearFarComputationCallback > : public osg::NodeCallback > { > 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); > } > } > }; > > struct OverrideNearFarValuesCallback > : public osg::Drawable::DrawCallback > { > OverrideNearFarValuesCallback(SkyDome* skyDome) > : m_skyDome(skyDome) {} > > virtual void drawImplementation(osg::RenderInfo& renderInfo, > const osg::Drawable* drawable) > const > { > osg::Camera* currentCamera = renderInfo.getCurrentCamera(); > if (currentCamera) > { > // Get the current camera position. > osg::Vec3 eye, center, up; > renderInfo.getCurrentCamera()->getViewMatrixAsLookAt( > eye, center, up); > > // Get the max distance we need the far plane to be at, > // which is the distance between the eye and the skydome's > // center, plus the skydome's radius. > double distance = (m_skyDome->getCenter() - eye).length() > + > m_skyDome->getRadius(); > > // Save old values. > osg::ref_ptr oldProjectionMatrix = > new osg::RefMatrix; > oldProjectionMatrix->set( > renderInfo.getState()->getProjectionMatrix()); > > // Get the individual values > double left, right, bottom, top, zNear, zFar; > oldProjectionMatrix->getFrustum( > left, right, bottom, top, zNear, zFar); > > // Build a new projection matrix with a modified far plane > osg::ref_ptr projectionMatrix = > new osg::RefMatrix; > projectionMatrix->makeFrustum( > left, right, bottom, top, zNear, distance); > renderInfo.getState()->applyProjectionMatrix( > projectionMatrix.get()); > > // Draw the drawable > drawable->drawImplementation(renderInfo); > > // Reset the far plane to the
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hello Chris, 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. Perhaps in a Drawable DrawCallback? Something like: OK, I've finally got this to work well, without the need to add an extra camera. It's a classic two-pronged attack: 1. Use a CullCallback that sets the compute near/far mode to off, traverses the skydome and resets it to the previous value. 2. Use a drawable DrawCallback on all the skydome's drawables that will calculate the maximum possible value the far plane would need to be at for the skydome to be visible from the current camera position, draws the drawable, and resets the old far plane after drawing. One thing I found I needed to do is keep the same near plane value as was set before, otherwise the skydome seemed to move when the camera moved. Here's the code I'm using: struct DoNotIncludeInNearFarComputationCallback : public osg::NodeCallback { 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); } } }; struct OverrideNearFarValuesCallback : public osg::Drawable::DrawCallback { OverrideNearFarValuesCallback(SkyDome* skyDome) : m_skyDome(skyDome) {} virtual void drawImplementation(osg::RenderInfo& renderInfo, const osg::Drawable* drawable) const { osg::Camera* currentCamera = renderInfo.getCurrentCamera(); if (currentCamera) { // Get the current camera position. osg::Vec3 eye, center, up; renderInfo.getCurrentCamera()->getViewMatrixAsLookAt( eye, center, up); // Get the max distance we need the far plane to be at, // which is the distance between the eye and the skydome's // center, plus the skydome's radius. double distance = (m_skyDome->getCenter() - eye).length() + m_skyDome->getRadius(); // Save old values. osg::ref_ptr oldProjectionMatrix = new osg::RefMatrix; oldProjectionMatrix->set( renderInfo.getState()->getProjectionMatrix()); // Get the individual values double left, right, bottom, top, zNear, zFar; oldProjectionMatrix->getFrustum( left, right, bottom, top, zNear, zFar); // Build a new projection matrix with a modified far plane osg::ref_ptr projectionMatrix = new osg::RefMatrix; projectionMatrix->makeFrustum( left, right, bottom, top, zNear, distance); renderInfo.getState()->applyProjectionMatrix( projectionMatrix.get()); // Draw the drawable drawable->drawImplementation(renderInfo); // Reset the far plane to the old value. renderInfo.getState()->applyProjectionMatrix( oldProjectionMatrix.get()); } else { drawable->drawImplementation(renderInfo); } } SkyDome* m_skyDome; }; struct AddCallbackToDrawablesVisitor : public osg::NodeVisitor { AddCallbackToDrawablesVisitor(SkyDome* skyDome) : osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN), m_skyDome(skyDome) {} virtual void apply(osg::Geode& node) { for (unsigned int i = 0; i < node.getNumDrawables(); i++) { node.getDrawable(i)->setDrawCallback( new OverrideNearFarValuesCallback(m_skyDome)); // Do not use display lists otherwise the callback will only // be called once on initial compile. node.getDrawable(i)->setUseDisplayList(false); } } SkyDome* m_skyDome; }; Then when adding the dome to the scene I do these extra steps: // Setup rendering so that the skydome does not affect the automatic // near/far plane calculation. m_node->setCullCallback( new DoNotIncludeInNearFarComputationCallback); AddCallbackToDrawablesVisitor visitor(this); m_node->accept(visitor); // Transparent bin is #10 by default so render just before // transparent objects. ss->setRenderBinDetails(9, "RenderBin"); ss->setAttributeAndModes( new osg::Depth(osg::Depth::LEQUAL, 1.0, 1.0), osg::StateAttribute::ON); I'm
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi David, Ah. I hadn't considered that in detail. (I wonder what my app's behaviour is then? I don't have many transparent objects so probably wouldn't have noticed if something was awry - I'll have to check). Forgot to mention, that's the reason I noticed it right away, because we have clouds that are just quads with semitransparent cloud textures on them, so it was very apparent :-) 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] Geometryconsidered in near+far plane auto computation
Hi David, For me, I will probably control the renderbins (if I'm not already doing it), and render ; i.e. putting the skydome in the regular opaque bin. Most of my objects are opaque so I get some benefit here. Yeah, that sounds like a happy medium. I'll try that out. 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] Geometryconsidered in near+far plane auto computation
Hi J-S, The problem when the skydome renders last is that it won't be blended > correctly with transparent objects (they need to be rendered after all > opaque objects, and sorted back to front). > Ah. I hadn't considered that in detail. (I wonder what my app's behaviour is then? I don't have many transparent objects so probably wouldn't have noticed if something was awry - I'll have to check). For me, I will probably control the renderbins (if I'm not already doing it), and render ; i.e. putting the skydome in the regular opaque bin. Most of my objects are opaque so I get some benefit here. Thanks for the caveat! David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi David, I had to use the approach I posted to simultaneously: 1) Make sure the skydome didn't participate in near/far autocalculation 2) Make sure OSG didn't cull the skydome 3) Make sure that OGL would actually draw something 4) Allow the skydome to draw last. The problem when the skydome renders last is that it won't be blended correctly with transparent objects (they need to be rendered after all opaque objects, and sorted back to front). Since the skydome is furthest from the camera, but if actually wraps around the camera, the only way to guarantee that it will be drawn in the correct order for transparent objects in the foreground to blend correctly with it is to render it first. I know this sounds bad, I previously advocated rendering skydomes/skyboxes last too (to take advantage of the fact that we can just set any fragments that have not been set yet by other objects) but I don't see how to reconcile that with the rendering of transparent objects in the foreground. So, given that I need the skydome to render first, it means I need to muck around with the clear settings and things like that, which I don't like. 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] Geometryconsidered in near+far plane auto computation
Hi Chris, After some brain-twisting, I did realize that even with z comparison off, OGL is 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; renderInfo->getCurrentCamera()->getProjectionMatrixAsFrustum( left, right, bottom, top, zNear, zFar; // Set the far plane to a large value. renderInfo->getCurrentCamera()->setProjectionMatrixAsFrustum( left, right, bottom, top, 1000, 1); drawable->draw(renderInfo); // Reset the far plane to the old value. renderInfo->getCurrentCamera()->setProjectionMatrixAsFrustum( 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. 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] Geometryconsidered in near+far plane auto computation
Hello Doug, Is the solution you posted below the final solution you settled on? I had trouble determining what you finally ended up deciding was the best path forward. Thanks for posting this information on the list. Yeah, as Robert said it was a convoluted thread... :-) Yes, I ended up using the code you quoted. As I said, it has too many implications on the scene graph and viewer but it ended up being the only solution I could find that worked and gave the results I wanted. I'm still open to suggestions though. :-) Glad I could help, 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] Geometryconsidered in near+far plane auto computation
Chris, > After some brain-twisting, I did realize that even with z comparison off, > OGL is > 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. > That's exactly what I found (or even wierder, the skydome vertices would clip, but the inter-vertex points wouldn't due to interpolation, so the dome looked "patchy". I had to use the approach I posted to simultaneously: 1) Make sure the skydome didn't participate in near/far autocalculation 2) Make sure OSG didn't cull the skydome 3) Make sure that OGL would actually draw something 4) Allow the skydome to draw last. In my app, I don't see a Camera with NESTED_RENDER as much of a per-frame overhead - it's pretty much negligible with all the rest of the CPU activity I'm engaging in, but I can appreciate that this might not be the case for everyone. Plus it had the advantage of being scenegraph agnostic - i.e. injection of this as a (for example) .osg worked without having to appeal to a particular application scenegraph structure in terms of PRE_RENDER, depth clears, etc. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Followup: After some brain-twisting, I did realize that even with z comparison off, OGL is 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. 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. -- 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] Geometryconsidered in near+far plane auto computation
Hello J-S, Is the solution you posted below the final solution you settled on? I had trouble determining what you finally ended up deciding was the best path forward. Thanks for posting this information on the list. Doug On Apr 22, 2009, at 12:40 AM, Jean-Sébastien Guay wrote: Hi again Paul, Anyways, that's a design concern, not implementation. Thanks for your suggestions. And I do want to emphasize that your solution (using a separate osg::Camera) does work. I've implemented it for both the skydome and cloud plane (which can get really big too) and I can now get really close to small models without them being clipped by the near plane. Barring any breakthrough on the other front, this will still be a very good solution. If anyone's curious, the code looks like: // Callback that checks other cameras namespace { int s_skyDomePreRenderCameraNum = -100; class CheckCamerasCallback : public osg::NodeCallback { public: virtual void operator()(osg::Node* node, osg::NodeVisitor* nv) { osgUtil::CullVisitor *cv = dynamic_cast< osgUtil::CullVisitor *>( nv ); if (cv) { // Do not use cv->getCurrentCamera() because it did not // exist in 2.2 which we still support osg::Camera* camera = cv->getCurrentRenderBin()->getStage()->getCamera(); // If the camera is either a pre-render camera with num > // our pre-render order, or not a pre-render camera if (camera->getRenderOrder() != osg::Camera::PRE_RENDER || camera->getRenderOrderNum() > s_skyDomePreRenderCameraNum) { // I should also check if the camera is set to render to // the framebuffer and is not an RTT camera, just to be // sure I'm only affecting the cameras I want to affect. // Set the camera to not clear the color buffer. if (camera->getClearMask() & GL_COLOR_BUFFER_BIT) camera->setClearMask( camera->getClearMask() & ~GL_COLOR_BUFFER_BIT); } } traverse(node,nv); } }; } SkyDome::SkyDome(...) { // Skydome initialization (the code is a modified version of the // osgEphemeris skydome) // ... // ... // Render the skydome through another camera so that the cloud plane // won't influence the main camera's near/far plane computations. // I'd prefer to find some other way to have the sky dome not // influence the main camera near/far values, because this has // repercussions on the viewer setup (see how CheckCamerasCallback // affects all other cameras). But it works well. #define USE_EXTRA_CAMERA #ifdef USE_EXTRA_CAMERA osg::Camera* camera = new osg::Camera; camera->setRenderOrder(osg::Camera::PRE_RENDER, s_skyDomePreRenderCameraNum); // set to -100 by default // Hopefully this will be the first pre-render camera, so it should // clear the color and depth buffers (this skydome is not guaranteed // to fill the whole view at all times). camera->setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); // The dome hangs under m_skyTransform. camera->addChild(m_skyTransform.get()); // m_node is the node that's exposed to be added to the graph by // client code. m_node->addChild(camera); // Make sure the main viewer camera only clears the depth buffer // otherwise it will clear our skydome... m_node->setCullCallback(new CheckCamerasCallback); #else // The dome hangs under m_skyTransform. // m_node is the node that's exposed to be added to the graph by // client code. m_node->addChild(m_skyTransform.get()); // The dome hangs under this #endif } Thanks a lot. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi again Paul, Anyways, that's a design concern, not implementation. Thanks for your suggestions. And I do want to emphasize that your solution (using a separate osg::Camera) does work. I've implemented it for both the skydome and cloud plane (which can get really big too) and I can now get really close to small models without them being clipped by the near plane. Barring any breakthrough on the other front, this will still be a very good solution. If anyone's curious, the code looks like: // Callback that checks other cameras namespace { int s_skyDomePreRenderCameraNum = -100; class CheckCamerasCallback : public osg::NodeCallback { public: virtual void operator()(osg::Node* node, osg::NodeVisitor* nv) { osgUtil::CullVisitor *cv = dynamic_cast< osgUtil::CullVisitor *>( nv ); if (cv) { // Do not use cv->getCurrentCamera() because it did not // exist in 2.2 which we still support osg::Camera* camera = cv->getCurrentRenderBin()->getStage()->getCamera(); // If the camera is either a pre-render camera with num > // our pre-render order, or not a pre-render camera if (camera->getRenderOrder() != osg::Camera::PRE_RENDER || camera->getRenderOrderNum() > s_skyDomePreRenderCameraNum) { // I should also check if the camera is set to render to // the framebuffer and is not an RTT camera, just to be // sure I'm only affecting the cameras I want to affect. // Set the camera to not clear the color buffer. if (camera->getClearMask() & GL_COLOR_BUFFER_BIT) camera->setClearMask( camera->getClearMask() & ~GL_COLOR_BUFFER_BIT); } } traverse(node,nv); } }; } SkyDome::SkyDome(...) { // Skydome initialization (the code is a modified version of the // osgEphemeris skydome) // ... // ... // Render the skydome through another camera so that the cloud plane // won't influence the main camera's near/far plane computations. // I'd prefer to find some other way to have the sky dome not // influence the main camera near/far values, because this has // repercussions on the viewer setup (see how CheckCamerasCallback // affects all other cameras). But it works well. #define USE_EXTRA_CAMERA #ifdef USE_EXTRA_CAMERA osg::Camera* camera = new osg::Camera; camera->setRenderOrder(osg::Camera::PRE_RENDER, s_skyDomePreRenderCameraNum); // set to -100 by default // Hopefully this will be the first pre-render camera, so it should // clear the color and depth buffers (this skydome is not guaranteed // to fill the whole view at all times). camera->setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); // The dome hangs under m_skyTransform. camera->addChild(m_skyTransform.get()); // m_node is the node that's exposed to be added to the graph by // client code. m_node->addChild(camera); // Make sure the main viewer camera only clears the depth buffer // otherwise it will clear our skydome... m_node->setCullCallback(new CheckCamerasCallback); #else // The dome hangs under m_skyTransform. // m_node is the node that's exposed to be added to the graph by // client code. m_node->addChild(m_skyTransform.get()); // The dome hangs under this #endif } Thanks a lot. 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] Geometryconsidered in near+far plane auto computation
Hi Paul, Yes, I understand this. And because you _have_ to disable color buffer clears in the other cameras, it'd be nice if you could also disable depth buffer clears. That way, the other cameras wouldn't have to invoke glClear at all. (That was the point I was trying to make, sorry it got convoluted. :-) Oh, yeah, I didn't get that you were suggesting a further step... Sorry about that. But what I would really like is to not require that my viewer be changed at all, i.e. that it keep its old way of doing things. The default for the main viewer camera is to clear color and depth, and I'd prefer to keep it that way because if I change it, it means that any other viewer that uses my skydome will also have to be changed otherwise the skydome will not render properly. I've already made a callback that checks all cameras and sets them correctly, but that seems heavy-handed to me. "If you want to use this skydome, you *must* do things this way". It also has chances of breaking other things that require other settings... I think the "disabling auto-compute" path would require less changes in other places, and run less chances of breaking in someone else's viewer. Anyways, that's a design concern, not implementation. Thanks for your 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] Geometryconsidered in near+far plane auto computation
Yes, I understand this. And because you _have_ to disable color buffer clears in the other cameras, it'd be nice if you could also disable depth buffer clears. That way, the other cameras wouldn't have to invoke glClear at all. (That was the point I was trying to make, sorry it got convoluted. :-) 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 4:02 PM To: OpenSceneGraph Users Subject: Re: [osg-users]Geometryconsidered in near+far plane auto computation Hi Paul, > Anyhow, you might be able to also avoid clearing depth in your other > cameras. Actually, the problem is not disabling clear of the depth buffer, it's disabling clear of the color buffer. Only the first camera needs to clear the color buffer, and since my skydome is rendered in PRE_RENDER, it's the first camera. I therefore need to disable clear of the color buffer for all other cameras. Anyways, I'll try to go forward with the other route (disabling auto computation of near/far) since I think this will have less implications. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi Paul, Anyhow, you might be able to also avoid clearing depth in your other cameras. Actually, the problem is not disabling clear of the depth buffer, it's disabling clear of the color buffer. Only the first camera needs to clear the color buffer, and since my skydome is rendered in PRE_RENDER, it's the first camera. I therefore need to disable clear of the color buffer for all other cameras. Anyways, I'll try to go forward with the other route (disabling auto computation of near/far) since I think this will have less implications. 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] Geometryconsidered in near+far plane auto computation
I can see that this might have "long fingers" in your app. Bummer. Anyhow, you might be able to also avoid clearing depth in your other cameras. Here's something to try: In the camera that renders the skydome, use Depth in the StateSet to set the depth range to something like 0.999-1.0. This puts your skydome all the way in the back of the depth buffer, and then it should be far enough back that subsequent scene cameras shouldn't need to clear either the color or depth buffers. It might be kind of a pain in your app, but hopefully avoiding those clears buys you some small performance gain that makes the change as a whole beneficial. 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 2:29 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Geometryconsidered 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org