The particular mesh that I am using has 912 vertices, and it doesn't comprise any additional submeshes. After implementing the function in the above link, the vertex count it calculates is 1922. Can anyone explain where the additional vertices come from? I suspect there is a reason for it, but given that I don't know what it is, when I try and use the vertex data to construct a convexHullShape in Bullet, the collider is not correct as my code treats the mesh as if it has the exported amount from maya, and therefore the collider has additional triangles that shouldn't be there.

Strangely enough the index count is correct, as it is 3x the amount of tris in the model (5376 -> 1792)

The vertex count you get from a modelling program can be different from the vertices in the final mesh. Extra vertices get created at UV splits, or where two faces have a sharp angle between them.

For instance, if I make a cube in blender and set it to solid, Blender says there are 8 vertices but the ogre model will have 24 vertices, 4 for each face, because of the different normals of the faces. (Each corner vertex has to be recreated 3 times with 3 different normals.) If I set it to smooth, I'll go back to 8 vertices. Then when I texture map it, it'll change again depending on how the texture seams are set.

That might be what you are seeing.

"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

The vertex count you get from a modelling program can be different from the vertices in the final mesh. Extra vertices get created at UV splits, or where two faces have a sharp angle between them.

For instance, if I make a cube in blender and set it to solid, Blender says there are 8 vertices but the ogre model will have 24 vertices, 4 for each face, because of the different normals of the faces. (Each corner vertex has to be recreated 3 times with 3 different normals.) If I set it to smooth, I'll go back to 8 vertices. Then when I texture map it, it'll change again depending on how the texture seams are set.

That might be what you are seeing.

Thanks for the reply. The issue is though that vertices are being put into triangles that they shouldn't be part of (for the convexHullShape, I mean). If I was loading the mesh as an obj, I'd load in every vertex once, then use the indices to access which vertices should be part of each triangle. This has worked for me in the past. Trying that approach here using the data retrieved from Ogre isn't working for me, so I must be doing something wrong.

The vertices and indices arrays are filled out the same way as in the function in the link I posted previously. And yet for some reason there are triangles joined together that shouldn't be.

Here is an image to demonstrate the issue, I am using a simplified version of the mesh to show the issue. As you can see, on the left in Blender, the triangles of the model are shown as would be expected. When trying to generate the ConvexHullShape with the data gained from the function in the link above, the collider is not correct. Vertices are being connected that shouldn't be. I'm not sure where I'm going wrong.

Ah. There's your problem. The convex hull shape generated there is correct. The problem is your mesh, it is not a convex hull.

A convex hull is a shape without any dents or bends, where a line from any point on the surface to any other point on the surface never leaves the shape.

In a physics engine you'll usually have a greatly reduced number of vertices in the convex hull compared to the mesh too. The engine will usually give you some option for the number of points, or have a function to reduce them. So a character head mesh that has 500 vertices might be represented by a hull with just 10 vertices.

"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

Ah. There's your problem. The convex hull shape generated there is correct. The problem is your mesh, it is not a convex hull.

A convex hull is a shape without any dents or bends, where a line from any point on the surface to any other point on the surface never leaves the shape.

In a physics engine you'll usually have a greatly reduced number of vertices in the convex hull compared to the mesh too. The engine will usually give you some option for the number of points, or have a function to reduce them. So a character head mesh that has 500 vertices might be represented by a hull with just 10 vertices.

Ah right, so it was my understanding of when to use convex hulls that was wrong. I've since changed to a different type of mesh collider in Bullet and it now generates the correct collider that I was looking for. Thanks for the help and clarification

In bullet, things that move are done using convex hulls, and if you need something moving that isn't a convex hull you can construct it out of a bunch of other convex hulls joined together. For stationary environments you can use tri-meshes, I'm guessing that's what you're doing now.

"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

In bullet, things that move are done using convex hulls, and if you need something moving that isn't a convex hull you can construct it out of a bunch of other convex hulls joined together. For stationary environments you can use tri-meshes, I'm guessing that's what you're doing now.

Yeah I'm using a tri-mesh. I have used them previously, I stupidly hadn't thought of using them for this particular model for some reason until this conversation.

In case the issue crops up again for other non-convex hull objects that do move (this one doesn't), I'll look into joining convex hulls together, thanks!