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
