High-edged shape faces cause array overflow

[justin.ead]

When a ShapeConvex is being created, the Unigine source code will store non-triangular faces in a Face struct. Each of these contains a static vertex array of size 16, along with an edge array of size 32. We've had a handful of assets that resulted in ShapeConvexes with faces containing over 20 vertices/edges. The index buffer overflowed as a result. This then attached the wrong vertices to the face when looping based on num_vertex, ruining convexity and later math. I'm pretty sure negative volume doesn't exist.  ;)

 

On another note, it seems a little inefficient to do the math calculating volume twice (once upon creating a Convex object, and again on setting the Convex object to the ShapeConvex). 

[silent]

Hi Justin,

Could you please share with us your models so we can reproduce this issue? Maybe also some additional screenshots to illustrate it?

Thanks!

[justin.ead]

Here is the visualizer showing the shape used for our wheel, ~CS_COLL/~CS_LW/~CS_LG/RootFrame. The two red arrows are pointing to an example line where it is crossing into the inside of the shape, effectively breaking being entirely enclosed and being convex.

 

Uploaded an example to the FTP server. We generate our shapes using roughly the following code applied to the source mesh:

for ( int i = 0; i < collisionMeshObject->getNumSurfaces(); i++ )
{
	Unigine::Ptr<Unigine::ShapeConvex> shapeConvex = Unigine::ShapeConvex::create();
	shapeConvex->setObject( collisionMeshObject->getObject(), i, error );
	m_bodyRigid->addShape( shapeConvex->getShape() );
}

In the case for the wheels, error will be 0. That would not be true for other surfaces.

 

The left wheel (~CS_LW) will result in a negative integral_1 value and the shape will be cleared out of its geometry in ShapeConvex::update_convex(). The right wheel (~CS_RW) has similar problems, but lucks out in maintaining a positive value and so still remains, albeit with a broken shape. The proper vertex indices were stored properly, and volume calculated properly, when initially created in the Convex class. It was only due to the copy that occurs from Convex to ShapeConvex that vertex index data in certain faces is lost/corrupted. See faces[1] on ~CS_LW for an example of a high-edged face that exceeds the 16 vertex limit.

[silent]

Hi Justin,

 

Thanks for the mesh file. I'm not sure, but will not be simpler and more performance friendly in that case to generate cylinder or sphere body instead?

I will file a bug to our internal bug tracker anyway, but with low priority, I'm afraid.

 

Thanks!