Willy P wrote:
Out of curiosity, how did you produce those .png's?
It's a little script that traverses a scenegraph and writes out a file for the dot graph drawing tool.
I hope to release it and much more in the near future... Paul
On 9/26/06, *Paul Melis* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:Just for fun: here's two graph diagrams of your scene. The out.png is without optimizer, the out2.png is what comes out when the optimizer has done its work. Two differences: two Group nodes have been removed and a MatrixTransform node has (supposedly) been pushed down into the Geometry drawables. Paul Paul Melis wrote: > John Aughey wrote: >> There is a problem with the osg Optimizer. I generally don't run the >> Optimizer on scenes because I want to preserve the node construction, >> but it is used by default in osgviewer and osgconv. I discovered >> this problem when trying to view a model in osgviewer. >> >> A model that exhibits the problem can be found at >> http://thinksplat.com/cubetest-cleanup.osg You can ignore the >> textures. If you view this with osgviewer, you'll see a cube, an >> outline of a cube, and another cube 7 times higher than the outline. >> The correct viewing of this file should be to have the cube that is >> way up in the air be within the bounds of the wireframe cube. >> >> If you modify osgviewer and comment out the optimize step, it looks >> like it is supposed to look. I do not have a fix for the Optimizer, >> but I can give some suggestions. The group that is offset has 7 >> children, and those children are offset by a factor of 7. It looks >> like the problem could be in Optimizer::*::removeTransforms methods. > Well, the different positioning of the cube is definitely > reproducable. Turning of the optimizer indeed changes the scene shown. > As you're probably aware you can turn off the optimizer without > changing any code by setting the environment variable OSG_OPTIMIZER to > OFF. > > I think the optimizer should be disabled by default. There's too many > surprising and unwanted side-effects because a scenegraph is altered > when it is loaded. Only when a user specifically requests the > optimization should it be performed. > > But there is a difference between working with a scene graph as a > data-structure on which you want to perform operations and merely > viewing the scene. In the former case you don't want anything to touch > the graph without your permission (i.e.what the optimizer does). When > you're just viewing a graph it might not be a problem that the scene > gets optimized for viewing at load time. > > What happens in your case is simply incorrect. > > My 2 eurocent... > > Paul > > _______________________________________________ > osg-users mailing list > [email protected] <mailto:[email protected]> > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] <mailto:[email protected]> http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ------------------------------------------------------------------------ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
-- Paul Melis VR Specialist, Center for High-Performance Computing & Visualization, University of Groningen, The Netherlands T: +31 50 363 9298 E: [EMAIL PROTECTED] W: http://www.rug.nl/rc/hpcv/index _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
