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 >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
