Re: [osg-users] Really Big Scenes and clipping
Hi Richard, The OSG supports high level and low control over draw order via the StateSet::RenderBinDetails. Basically the rendering backend is constructed as a graph of what is called RenderStage(s) and RenderBin(s), the StateSet::RenderBinDetails tells the cull traversal how to build this graph, both the type of RenderBin to create/use and what order it should drawn in. Its a very powerful feature, but its is one of the more advanced and complex to understand ones so you'll need to be patient and steadily bite into rather than diving straight in the deep end and expect understand it all right away. To learn about making a subgraph draw first have a look at the osghangglide example - it has a skydome that it renders first, and you can switch off depth testing for it. The osgvertexprogram example also has a skybox that is view dependant. For general rendering order control have a browse through the osgreflect example. The osgprerender example also provides another example, this time using render to texture cameras. Robert. On Dec 17, 2007 11:22 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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
Re: [osg-users] Really Big Scenes and clipping
Richard, I've seen this type of thing before in my scenes with cracks in the terrain. Adjusting of lines 242-243 in DepthPartitionNode.cpp seemed to fix this for me: znear *= 0.99; zfar *= 1.01; - D. On Dec 17, 2007 5:30 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Donald, Thanks... that's a pretty easy looking solution. However, I seem to be doing something unorthodox somewhere that is preventing this node from working as intended. I get a moving gap cut through the world that is more or less parallel to the camera plane, and that moves around as the camera moves (I am moving my camera manually). Have you seen this effect before (see below)? Richard On Dec 17, 2007, at 9:03 AM, Donald Cipperly wrote: Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor:: DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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 ___ 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] Really Big Scenes and clipping
Thanks, scaling just a little bit more than you did the trick. This is a pretty useful node! Richard On Dec 18, 2007, at 7:36 AM, Donald Cipperly wrote: Richard, I've seen this type of thing before in my scenes with cracks in the terrain. Adjusting of lines 242-243 in DepthPartitionNode.cpp seemed to fix this for me: znear *= 0.99; zfar *= 1.01 ; - D. On Dec 17, 2007 5:30 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Donald, Thanks... that's a pretty easy looking solution. However, I seem to be doing something unorthodox somewhere that is preventing this node from working as intended. I get a moving gap cut through the world that is more or less parallel to the camera plane, and that moves around as the camera moves (I am moving my camera manually). Have you seen this effect before (see below)? Richard On Dec 17, 2007, at 9:03 AM, Donald Cipperly wrote: Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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 ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Robert, Yes, mastery of a new technology certainly is a long term investment ;-) Thanks for this explanation, it is a valuable insight. As I continue to grok more of the OSG philosophy, I'm sure more of this will become more intuitive to me. I have now found three different solutions to my original problem that all work, so I feel I have moved another rung or two up the ladder ;-) I will also look at the examples you recommended for further insights. Richard On Dec 18, 2007, at 4:16 AM, Robert Osfield wrote: Hi Richard, The OSG supports high level and low control over draw order via the StateSet::RenderBinDetails. Basically the rendering backend is constructed as a graph of what is called RenderStage(s) and RenderBin(s), the StateSet::RenderBinDetails tells the cull traversal how to build this graph, both the type of RenderBin to create/use and what order it should drawn in. Its a very powerful feature, but its is one of the more advanced and complex to understand ones so you'll need to be patient and steadily bite into rather than diving straight in the deep end and expect understand it all right away. To learn about making a subgraph draw first have a look at the osghangglide example - it has a skydome that it renders first, and you can switch off depth testing for it. The osgvertexprogram example also has a skybox that is view dependant. For general rendering order control have a browse through the osgreflect example. The osgprerender example also provides another example, this time using render to texture cameras. Robert. On Dec 17, 2007 11:22 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode (osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a
Re: [osg-users] Really Big Scenes and clipping
Hello Richard, However, I also have some transparent items, so the sky still needs to be drawn first (and I did neglect to mention this to be fair). Just set your transparent bin to be a larger number than the skybox. Then, the order will be: 1. Opaque objects 2. Skydome 3. Transparent objects Anyways, it's a relatively minor thing. If you're not fill-limited, don't even waste time on this... I was just mentioning it so you know, and might consider it for future projects. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Hello Chase, It sounds like he wants to render it first because he's placing a unit sphere around the eyepoint, which is probably closer than everything else and surely won't get clipped by the far plane. That way, everything that's rendered later will overwrite it as if occluding it, leaving only unoccluded areas of the sky still visible without any fear of z-fighting. By changing the depth test as was done in the code I posted, that's not a problem. The skybox/skydome will be rendered, regardless of its size, wherever nothing has written in the depth buffer before (more precisely, wherever the depth is at maximum, so at the far plane itself). J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor:: DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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] Really Big Scenes and clipping
Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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] Really Big Scenes and clipping
Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Richard S. Wright Jr. wrote on Monday, December 17, 2007 5:22 PM: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) To have the skydome always rendered last, give it a StateSet and call setRenderBinMode(USE_RENDERBIN_DETAILS) and setRenderBinNumber(3). Most stuff uses RenderBin 0, (or 1 and 2 if there's transparent stuff), so this should force it to be last (you can certainly set a higher number if needed). Nested cameras and anywhere else you don't use the default StateSet RenderBinMode will complicate things, though (RenderBins can nest, and the numbers are relative order within the current RenderBin). HTH! On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Richard On Dec 17, 2007, at 6:41 PM, Thrall, Bryan wrote: Richard S. Wright Jr. wrote on Monday, December 17, 2007 5:22 PM: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) To have the skydome always rendered last, give it a StateSet and call setRenderBinMode(USE_RENDERBIN_DETAILS) and setRenderBinNumber(3). Most stuff uses RenderBin 0, (or 1 and 2 if there's transparent stuff), so this should force it to be last (you can certainly set a higher number if needed). Nested cameras and anywhere else you don't use the default StateSet RenderBinMode will complicate things, though (RenderBins can nest, and the numbers are relative order within the current RenderBin). HTH! On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ 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] Really Big Scenes and clipping
Doh!! Thanks! Richard On Dec 17, 2007, at 8:46 PM, Jason Daly wrote: Richard S. Wright Jr. wrote: Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Negative numbers also work for render bins. You can use -10, for example, to get it drawn first. --J ___ 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] Really Big Scenes and clipping
Richard S. Wright Jr. wrote: Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Negative numbers also work for render bins. You can use -10, for example, to get it drawn first. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Hello Richard, Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Why do you want to render it first, and then have it be overwritten by your objects, which might (worst case) result in having drawn the whole screen twice for nothing? Render it last, but only setting pixels at the far plane. That way, pixels that contain other objects will not be overwritten by your skydome. For example, this is from the skybox code in my current project, but I can't take credit as most of it was lifted from a post to this very mailing list. Unfortunately, it's from the old list server and I can't seem to find the message in the current archives. The old link was: http://openscenegraph.org/archiver/osg-users/2005-June/0581.html osg::StateSet* stateset = new osg::StateSet; // Set texture mode to REPLACE osg::TexEnv* te = new osg::TexEnv; te-setMode(osg::TexEnv::REPLACE); stateset-setTextureAttributeAndModes(0, te, osg::StateAttribute::ON); // Turn off lighting and cull face stateset-setMode(GL_LIGHTING, osg::StateAttribute::OFF); stateset-setMode(GL_CULL_FACE, osg::StateAttribute::OFF); // Basic principle of skyboxes: render it last, and with a depth func // that only sets pixels at the far plane. That way, if the sky is not // visible at all for example, the sky won't be drawn (and possibly // fragment shaders will not be called) whereas rendering it first will // cause all pixels to be written, then overwritten by objects, and // possibly fragment shaders will have been called for nothing. // Clear the depth to the far plane. osg::Depth* depth = new osg::Depth(osg::Depth::LEQUAL, 1.0, 1.0); stateset-setAttributeAndModes(depth, osg::StateAttribute::ON); // Make pretty darn sure it is drawn last. stateset-setRenderBinDetails(1000, RenderBin); // Create a drawable for the skybox. osg::Geometry* drawable = new osg::Geometry; // Create vertices for box // [...] // Create texture coordinates for cubemaps // [...] // Create an index array for the box // [...] // Create a geode for the skybox osg::Geode* geode = new osg::Geode; geode-setName(Skybox); // Disable culling geode-setCullingActive(false); // Set the stateset geode-setStateSet(stateset); // Add the skybox geode-addDrawable(drawable); // Next is setting the texture and the transform node... // [...] -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
