Jolt crashing on JPH_ASSERT

[Pindrought]

I am not sure what exactly this assert means or what ioV is.
Any ideas on what might be causing this? It seems like both my basic character controller and wheeled vehicle controller trigger it when going over a specific point on my road mesh.

https://www.youtube.com/watch?v=KvisjT9RN98

If needed, I can try to put together a demo that can be run from the Jolt samples project, but it will take some time to put it together.

[jrouwe]

My guess is that there is a degenerate triangle in the mesh that you're driving/walking over at that moment.

Can you try calling MeshShapeSettings::Sanitize on the mesh before you create the shape? (both constructors do this internally, but if you fill in mTriangleVertices/mIndexedTriangles later then it won't be called automatically).

[Pindrought]

I am using Visual Studio 2022 for my compiler.
My project is currently using /fp:precise

I noticed that in the Jolt project where it works without issues, /fp:fast is on

I tried changing my project to match these values, but I still get this crash.

I also removed the preprocessor define JPH_USE_FMADD on the library and my project, and rebuilt both of them. I am still getting the crash.

For reference, this is what my preprocessor defines look like
%(PreprocessorDefinitions)
WIN32
_WINDOWS
_DEBUG
JPH_PROFILE_ENABLED
JPH_FLOATING_POINT_EXCEPTIONS_ENABLED
JPH_USE_AVX2
JPH_USE_AVX
JPH_USE_SSE4_1
JPH_USE_SSE4_2
JPH_USE_LZCNT
JPH_USE_TZCNT
JPH_USE_F16C
NOMINMAX

Any ideas on what else I could try?

The only thing I can think of is trying to make a minimal reproducible solution, but this will take a lot of effort so I wanted to hopefully exhaust the other options before doing that.

[Pindrought]

Just an update, I am working on setting up a basic project to reproduce my issue.

[Pindrought]

Well, I made a basic project to try to reproduce the issue and it doesn't crash even though my jolt related logic is the same between the two projects. I have no idea on what the root cause could be. My main engine project is doing all of the engine/physics updates processing on a secondary thread. Could creating/updating the jolt physics systems on a thread other than the initial program startup thread be an issue?

[jrouwe]

That shouldn't be an issue, but I can't look in your code to see what you may have done wrong.

In any case I don't think that assert will lead to really bad things happening (it could cause you to miss a collision, but since this is a degenerate triangle that's probably not a big deal), so you could also just comment out the line.

[Pindrought]

My code is not public, so I will need to add you to the repository for it.
Before I do that, there is a lot of cleanup that needs to be done, because certain things are a bit of a mess right now.
I am going to try to spend the next week cleaning things up, and when it is ready I can give you access the repo if you are hopefully able to take a look at it.

Thank you so much for all of your help.

Also, is there any way to donate to the project?

[jrouwe]

I did a little experiment with your sample code in https://pastebin.com/1JSTavcs, if I change IndexedTriangleNoMaterial::IsDegenerate to always return false and undefine JPH_FLOATING_POINT_EXCEPTIONS_ENABLED (because otherwise I get div-by-zero exception during mesh creation) then I can repro your assert. The bad news is that ignoring it will cause troubles down the line, so commenting out the assert will not help.

Looking at the callstack, there are only 2 ways why triangle can be degenerate:

1. Degenerate triangles are provided and for some reason the Sanitize function doesn't do its job. In your example I hit the following line 5x:

JoltPhysics/Jolt/Physics/Collision/Shape/MeshShape.cpp

Line 104 in c1556df

mIndexedTriangles[t] = mIndexedTriangles.back();

So it removes 5 degenerate triangles, and that ensures that the issue doesn't happen in the Samples app. Maybe you can check that in your application it removes the same amount?

2. One level up in the callstack, in CollideConvexVsTriangles::Collide, you can take a look at the variables. This is the important bit:

// Scale triangle and transform it to the space of 1
Vec3 v0 = mTransform2To1 * (mScale2 * inV0);
Vec3 v1 = mTransform2To1 * (mScale2 * inV1);
Vec3 v2 = mTransform2To1 * (mScale2 * inV2);

inV0, inV1 and inV2 are the vertices of the triangle as it was stored in the mesh shape. If these form a degenerate triangle then it is possible that the vertex quantization (done for mesh compression) snapped two vertices together while they were not together in the original input data. Otherwise either mTransform2To1 or mScale must cause the triangle v0, v1, v2 to become degenerate. Maybe you can check which of the two it is?

[Pindrought]

I have added code to remove degenerate triangles in my current project, but before I had added this I was getting many hits (much more than 5) at that breakpoint in MeshShape.cpp. Edit: Just to clarify, I think the Sanitize function is working. I had just originally assumed it wasn't since my program still crashes.

When I traverse the callstack, it looks like the issue is with inV1, inV2

inV0 = {30.4649086, -13.4499702, 93.5703278, 93.5703278}
inV1 = {26.4438229, -11.9567986, 87.7664108, 87.7664108}
inV2 = {26.4438229, -11.9567986, 87.7664108, 87.7664108}

Here is a link to my repo: https://github.com/Pindrought/ModWorld2021
I sent you an invite so I believe it should be visible.

When you run it, be sure to run it in debug mode, as everything else will break at the moment. It should automatically load in the demo with the player on on this mesh near the point where the crash occurs. Hold right click to move the camera and WASD controls. Ctrl or Shift both will increase the player's speed.

[jrouwe]

I think I have a potential fix for your issue.

Can you try out #891?

I haven't tested this on your repo, but I think the difference between your project and the sample project is that you didn't export your mesh with enough precision (you need to use at least 6 digits behind the dot to be certain that there is no loss during export). If I fudge the vertices a bit then I can reproduce the crash, and with this change I can't anymore.

[Pindrought]

I think this fixed it!! Thank you so much!!

[jrouwe]

Thanks for testing! I've cleaned up the change a bit and merged it with master.

[jrouwe]

Oh and to answer your other question:

Also, is there any way to donate to the project?

If you mean a monetary donation, then no, I'm not accepting those at the moment.

[Pindrought]

Yes, this is what I was referring to.