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
