Multi-material tri mesh problems with using uchar type

[sebby_man]

This is a really specific question, but I'll bring it up anyways.

I'm trying to make a multi-material tri mesh. For the per-triangle material indices, I'm using an array of uchars rather than the typical array of ints. When I do that, the program crashes during the gContactAddedCallback function. I've tried using ints instead, and everything works perfectly.

Here's the code.

Code: Select all

// Create btIndexedMesh called part

uchar* triangleMaterials = new uchar[part.m_numTriangles];
for (uint i = 0; i < part.m_numTriangles; i++)
{
    triangleMaterials[i] = 0;
}

btMaterialProperties mat;
mat.m_numMaterials = numMaterials;
mat.m_materialBase = (const unsigned char*)materials;
mat.m_materialStride = sizeof(btMaterial);
mat.m_materialType = PHY_FLOAT;
mat.m_numTriangles = part.m_numTriangles;
mat.m_triangleMaterialsBase = (const unsigned char*)triangleMaterials;
mat.m_triangleMaterialStride = sizeof(uchar);
mat.m_triangleType = PHY_UCHAR;

btTriangleIndexVertexMaterialArray* meshInterface = new btTriangleIndexVertexMaterialArray();
meshInterface->addIndexedMesh(part, PHY_SHORT);
meshInterface->addMaterialProperties(mat, PHY_UCHAR);
btMultimaterialTriangleMeshShape* trimeshShape = new btMultimaterialTriangleMeshShape(meshInterface, true, aabbMin, aabbMax);

[Basroil]

Why bother with UCHAR though? On x86 systems it takes just as long to move UCHAR as Int.

The problem with uchar is that it's unsigned and only 256 units, which means if you have more than 256 triangles you'll be in trouble at runtime. My guess would be that you're sending two different values into the pipe, and getting an index out of bound or uninitialized read/write in CustomMaterialCombinerCallback (gContactAddedCallback )

[sebby_man]

I'm using uchar for the triangleMaterialsBase, which is for each triangle to give an index into the material array. Since I only have around 5 materials, the values are always in the [0-4] range and will never exceed 255. Besides that, using uchar makes a lot of sense for me because I'm storing this data in a file and would like small file sizes and easy transfer when I load the binary.

I don't really understand what you mean by sending two different values into the pipe. Where would this be happening?

[Basroil]

I don't really understand what you mean by sending two different values into the pipe. Where would this be happening?

Just imagine one function is expecting an int array and gets a char array instead, the compiler might throw an error, or it can "forget" that error and it ends up crashing your program. Bullet has a lot of interconnected classes and functions, so it's hard to say how or where issues like that could happen if you use non-standard types.

If your concern is file loading rather than memory constraints, why not just convert to the right units when saving/loading? Maybe even look into lightweight compression if your files are disk limited rather than computation limited. It's a hell of a lot less work than rewriting large chunks of bullet