Unexpected behavior cooking complex meshes

[jbeard4]

Hello,

I have integrated an OBJ loader with PhysX, such that it loads a mesh and "cooks" it. This is working well for some simple meshes, like the following:

However, for more complex meshes, I have found I am getting some unexpected results, where it fails to create a convex hull from the mesh description. For example please consider the following mesh of a high-resolution body scan: https://www.artec3d.com/3d-models/full-body-scan

This mesh consists of ~150k vertices and ~300k faces.

This yields the following mesh when cooked in PhysX.

I tried simplifying the mesh in meshlab to reduce the number of faces and vertices of the mesh, to ~11k vertices and ~22k faces, and this yields better results, but is still produces some gaps in the mesh, and unexpected shapes:

What could account for this unexpected mesh cooking behavior? Is there any way to produce a better result? I would appreciate any insight anyone can share. Thank you.

[EverThunder]

I've had the same problem in Physx3.3.3.I don't think the algorithm of cooking convex is perfect, It produce an error report "Cooking::cookConvexMesh: user-provided hull must have less than 256 vertices!".Continue to reduce...I used to use qslim.

[AlesBorovicka]

Is this problem related to convex cooking or triangle mesh cooking? From the screens it looks like triangle mesh cooking right? Are you sure that you pass the correct stride etc, from the screenshots it looks like there might be something wrong with the indices stride. Could you please try to use checked or debug build and see if there are some errors in the error stream?

Hmm not sure how your error - "Cooking::cookConvexMesh: user-provided hull must have less than 256 vertices!" is related to cooking convex algorithm of PhysX, as you did provided the hull, there was no convex algorithm of PhysX involved at all. You either provide just points and add eCOMPUTE_CONVEX flag, then PhysX does the convex compute or you have to provide the convex points, faces, indices in which case PhysX does just checks and computes runtime convex info. In your case the check failed.

[PierreTerdiman]

Just a thought: it might also be PVD rendering issues if the number of triangles is too large. Maybe the PhysX mesh is fine but the vertex buffer is limited to 64K vertices or something (I am not familiar with the PVD render code, just a thought).

[jbeard4]

@EverThunder I don't believe I have seen that error message. I am using PhysX 4.1. I had been using meshlab for simplification - thank you for the tip about qslim!

[jbeard4]

@PierreTerdiman I don't believe this is a PVD rendering issue, as I can actually run physical simulations on the weird meshes. For example, you can see the green boxes in the above screenshot, which are interacting with the mesh in a manner consistent with how they are rendered.

The interaction between the mesh and cubes is like a game of Pachinko. Therefore, it does not appear to simply be a rendering issue, but is in fact cooking the mesh in an unexpected way.

However, I believe I have seen the rendering issue you described, when working with complex meshes. For example, when I attempt to cook this complex mesh, it renders in PVD like this:

Such that only half the mesh is rendered, and that mesh has holes in it. I have seen other complex meshes with similar rendering issues in PVD, missing half or more of the faces.

However, it is useful to note that this is a rendering issue only, as I have confirmed through simulation that physx does treat the mesh as a convex shape. For example, you can see in the following screen recording, the cube bouncing off a shoulder, even though the shoulder is not rendered:

http://g.recordit.co/zoTkhGEAQt.gif

In this example, I believe PhysX is cooking the mesh correctly, even though it is not being rendered correctly. Therefore, I believe that the PVD rendering issue you describe is a separate issue from the mesh cooking issue.

[jbeard4]

@AlesBorovicka I can confirm this problem is related to triangle mesh cooking. I am fairly certain that the stride is correct - I based the code on the snippetdeformablemesh code so it is using the same struct Triangle, and meshDesc.triangles.stride = sizeof(Triangle). I can post some example code later to create a minimal reproducible example.

By "error stream", do you mean stdout/stderr emitted to the console? Or is there a different channel for capturing errors from PhysX?

Thank you for your help with this.

[ldepn]

Hi @jbeard4 , how do you integrated an OBJ loader with PhysX？Can you share the code?

[pkxpp]

And how to handle it finaly? = =

[ldepn]

您的邮件已收到，我会尽快处理！