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
[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
_______________________________________________
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
