Triangle mesh is misaligned

[GoogleCodeExporter]

If you download the attached cone.osg model and run the following:

$ osgbpp cone.osg  --triMesh --debug

you'll notice that the triangle mesh is offset from the actual shape.

Original issue reported on code.google.com by godbyk@gmail.com on 7 May 2014 at 1:33

Attachments:

• cone.osg

[GoogleCodeExporter]

Original comment by SkewMat...@gmail.com on 20 May 2014 at 2:09

• Changed state: Accepted

[GoogleCodeExporter]

The issue is related to the fact that the center of the cone's bounding sphere 
is 0,0.25,0. You can temporarily workaround the issue by manually editing 
cone.osg and changing the ShapeDrawable "Center" from "0 0 0" to "0 -0.25 0".

I imagine this error message:
osgwTools::transform can't transform non-Geometry yet.
gives us some clue. If osgBullet is counting on osgwTools::Transform to move 
the Drawable data, and osgwTools::Transform can't do that because the vertices 
of a ShapeDrawable are not accessible, that might explain the discrepancy.

I'll investigate further.

Original comment by SkewMat...@gmail.com on 20 May 2014 at 2:35

[GoogleCodeExporter]

ComputeShapeVisitor documentation: 
https://code.google.com/p/osgbullet/source/browse/trunk/include/osgbCollision/Co
mputeShapeVisitor.h#45
lines 45-53 gives us some good information.

To correctly support center of mass, the geometric data must be transformed by 
the negated center of mass. In this case, that's 0,-0.25,0. But we know that's 
not happening (due top the displayed error message). The documentation goes on 
to say that triangle mesh shapes are created from the transformed geometric 
data. Since that data is NOT transformed (again, the error message), the result 
is a tri mesh shape created from untransformed geometry, and therefore offset 
0.25 in Y from the visual representation of the rigid body.

It seems like there are two possible fixes.

1) Add support to osgwTools::transform for ShapeDrawables. I think this would 
be possible: copy the ShapeDrawable and manipulate its paramatric controls to 
effect the transform, then build the collision shape from the copy. However, I 
favor another option...

2. Instead of using ShapeDrawable, use the osgwTools/Shapes.h functions to 
create cone shapes. These create the objects directly in an osg::Geometry. 
osgBullet already fully supports osg::Geometry, so an osgwTools cone should 
work fine.

In summary, osgBullet (and osgWorks) do not have good support for 
ShapeDrawable, but they offer an alternative in the osgwTools Shapes routines. 
It is not uncommon to have poor support for ShapeDrawable; even many 
NodeVisitors and export plugins included with the OSG distribution ignore 
ShapeDrawables and support only Geometry.

So, I'm not planning on doing any code changes for this, but I'm open to 
further discussion on the issue.

Original comment by SkewMat...@gmail.com on 20 May 2014 at 3:14

• Changed state: WontFix