Thanks for pin pointing this bug. When writing the flatten static transforms visitor I didn't consider the possibility of sharing vertex arrays. The code should detect this, or as you suggest duplicate the arrays and allow them to be indivudually positioned. The arrays are all ref counted so if the ref count is more than one you can be sure that its one to consider as being shared. A patch in this direction would certainly be very welcome.
As a general note, use of the Optimizer is very important for producing good runtime peformance. Very few loaders create optimal scene graphs, and they need serious massaging to get anywhere need something that is good for run-time. The performance difference between optimized and non optimized can easily be 10 fold or more for big models. Converting to .ive or .osg via the optimizer would allow the subsequent models to be loaded without optimization, so I'd use this approach for graphics apps that performance is critical.
Robert.
On 9/28/06, John Aughey <[EMAIL PROTECTED]> wrote:
Ok, I have more information on this problem. The problem is I have multiple drawables that share the same VertexArray, NormalArray, and TexCoordArray. The CollectLowestTransformsVisitor::doTransform method uses the osgUtil::TransformAttributeFunctor on each drawable. But since the drawables share the same VertexArray, the transform is applied multiple times rather than just once.
There are two ways I can see to fix this problem. The ideal way would be to keep track of whether or not a VertexArray has been transformed to make sure it is only applied once. This turns out to actually be harder than it looks because the osg::Array objects do not keep track of their parents or what type of an array it is which the TransformAttributeFunctor needs.
The second way is to make a copy of the vertex and normal arrays if they are referenced more than once. While this may not be an optimal from a space point of view, it does produce the correct results.
Unless anyone objects, I'll put a patch together and submit it. It's a simple 5 line patch.
JohnOn 9/26/06, John Aughey <[EMAIL PROTECTED]> 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.
John Aughey
_______________________________________________
osg-users mailing list
[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/
