triangle_normal not normalized in CollideConvexVsTriangles::Collide causing a "ioV.IsNearZero()" exception error in debug mode

[olivierbrun]

Hello Jorrit,

The Vec3 triangle_normal variable is not normalized int the CollideConvexVsTriangles::Collide function (in line 51) , causing time to time a "ioV.IsNearZero()" exception error in EPAPenetrationDepth::GetPenetrationDepthStepGJK, (in debug mode).

Replacing line 51
Vec3 triangle_normal = mScaleSign2 * (v1 - v0).Cross(v2 - v0);
with
Vec3 triangle_normal = mScaleSign2 * (v1 - v0).Cross(v2 - v0).NormalizedOr(Vec3::sAxisY());

seems to solve the problem.

I don't know whether keeping this calculated normal unormalized is on purpose.

Cheers
Olivier

[jrouwe]

triangle_normal is not normalized on purpose to save some CPU cycles. If this assert triggers, then usually (and that appears to be the case here too given your fix) a degenerate triangle / sliver is being provided to Jolt. I'm assuming this call came from a MeshShape, in which case I would check the mesh to see if it is 'clean'. Jolt tries to remove degenerate triangles, but there's always edge cases. Alternatively, the shape could have been scaled to a really tiny shape which leads to the same issue.

[olivierbrun]

Thanks for the quick feedback, I understand the need of keeping the triangle_normal not normalized to avoid the expensive cost of a square root and divide calculation,
You may close this issue.
As an interim solution, I'll use the LengthSq() function which doesn't require square root calculation, to check whether the triangle_normal length is close to zero, and if so, use the alternate Vec3(0.0, 1.0, 0.0).

[jrouwe]

As an interim solution, I'll use the LengthSq() function which doesn't require square root calculation, to check whether the triangle_normal length is close to zero, and if so, use the alternate Vec3(0.0, 1.0, 0.0).

I would really investigate the mesh that you're sending to Jolt, the code shouldn't have to be altered.

[olivierbrun]

Thanks, I've found the guilty triangle in one of the mesh colliders.

As a side note:
The Sanitize() function uses the IsNearZero() function, which uses 1.0e-12f as minimal default value.
However, for float values the mantisse is 23 bits long, which limits the precision to 6-7 significant digits.
In the Vec3.h file, if I replace 1.0e-12f with 1.0e-6f for default float values passed as parameter, then I'm not getting the "ioV.IsNearZero()" exception error anymore, as in that case the Sanitize() function has automatically removed the problematic triangle.

/// Test if two vectors are close
JPH_INLINE bool				IsClose(Vec3Arg inV2, float inMaxDistSq = 1.0e-6f) const;

/// Test if vector is near zero
JPH_INLINE bool				IsNearZero(float inMaxDistSq = 1.0e-6f) const;

/// Test if vector is normalizeddefult 
JPH_INLINE bool				IsNormalized(float inTolerance = 1.0e-6f) const;

The same limit with float precision also applies to the Vec4 class.

[jrouwe]

These parameters are squared distances, so the actual error is not 1.0e-12 but 1.0e-6 which should be significant if the value is around 1. In the case of the IsDegenerate check, it means that it removes triangles that have an area of roughly 0.5 mm^2. If you change the default value in IsNearZero to 1.0e-6 then it will start removing triangles that are approx 1.5 cm^2 in size, which is rather large. In practise there is no single value that you can put there that will work for everything since people have content at various scales.

[olivierbrun]

I've fixed the mesh collider causing the issue and set the default values back to 1.0e-12f, thanks for your advice.
In the case of the playground test map that I'm using to experiment Jolt, 1 unit represents 1 meter, which means 1.0e-6f represents 1mm^2. So having this small triangle removed by the Sanitize function was not a problem, so far. But I agree with all your comments, it's always better not having degenerate triangles at all.
Many thanks again for your support and responsiveness.