I updated to Unity 6 and Cesium 1.10.0 and now I get a lot of errors in playmode that look like this:
Failed to create Physics Mesh from source mesh. One of the triangles is too large. It’s recommended to tesselate the large triangles. Source mesh name:
Hi @krumelmonster , welcome to the community!
Thanks for letting us know about this error. I personally haven’t tested Unity 6 yet, but I looked up this error message and it seems that others are getting it as well, as reported on the Unity forum .
Could you try this workaround that I found on Youtube?
If that workaround doesn’t help, we can try to reproduce this ourselves, and see if there’s a way to circumvent it.
This video shows not really a workaround. And the errors occur in playmode, when the tiles are generated , not when the app is build.
Hi @krumelmonster ,
Thanks for specifying what dataset you’re using. Does it make a difference if you use Cesium World Terrain instead? (Only asking for debugging purposes, I am not suggesting that you shouldn’t use Photorealistic 3D Tiles.)
We’ll work on reproducing your issue on our own machines, and get back to you with what we find. Thank you!
1 Like
The bug also happens with “Cesium world terrain”.
1 Like
Is there any update on this issue?
It is still happening with the latest version of unity and cesium although its now a warning rather than an error.
Detected one or more triangles where the distance between any 2 vertices is greater than 500 units. The resulting Triangle Mesh can impact simulation and query stability. It is recommended to tessellate meshes that have large triangles. Source mesh name:
1 Like
janine
July 22, 2024, 1:57pm
7
Hi @RandomName87 ,
There hasn’t been an update on this issue, but it sounds similar to an issue we discovered in Cesium for Unreal.
CesiumGS:main ← CesiumGS:scale-for-physics
opened 09:09AM - 30 Jun 24 UTC
Fixes #1250
Lending further support to my theory that "anytime a software dev… eloper is typing the word 'epsilon', they're typing a bug"...
(See my previous rant about epsilons in CesiumGS/cesium-native#914)
We've had trouble with Chaos physics ever since Unreal Engine switched to it by default. The first problem was that Chaos would frequently crash in debug builds, or hang and spam the log in release builds, when doing collisions against many of our meshes (#1084). It was caused by checking for (and logging) "degenerate triangles". So, we decided to filter out degenerate triangles from our meshes using the same test that Chaos itself uses (#1106).
That worked well in that it stopped the crashing and freezing. But we still occasionally heard reports (#1250) of failed lined traces against our meshes. We assumed this was because the triangles it was supposed to hit were quite small, and so Chaos is (incorrectly) flagging them as degenerate.
But with the San Francisco Ferry Building model, the triangles being missed really aren't all that small. What is going on here? I finally spent a chunk of time looking at it today.
My diagnosis is that the degenerate triangle test that Chaos is using is astoundingly bad. It looks like this:
```cpp
const ParticleVecType& A = MParticles.X(Elements[FaceIdx][0]);
const ParticleVecType& B = MParticles.X(Elements[FaceIdx][1]);
const ParticleVecType& C = MParticles.X(Elements[FaceIdx][2]);
const ParticleVecType AB = B - A;
const ParticleVecType AC = C - A;
ParticleVecType Normal = ParticleVecType::CrossProduct(AB, AC);
if(Normal.SafeNormalize() < UE_SMALL_NUMBER)
{
UE_LOG(LogChaos, Warning, TEXT("Degenerate triangle %d: (%f %f %f) (%f %f %f) (%f %f %f)"), FaceIdx, A.X, A.Y, A.Z, B.X, B.Y, B.Z, C.X, C.Y, C.Z);
CHAOS_ENSURE(false);
return FVec3(0, 0, 1);
}
```
A, B, and C are the three vertex positions and `UE_SMALL_NUMBER` is 1e-8. And if you dig into that `SafeNormalize`, you'll see there's yet another epsilon test. If the squared magnitude of the vector is less then 1e-4, then SafeNormalize will return 0.0. Zero is definitely less than 1e-8, so this warning will be triggered.
This computation is done in model coordinates. Which means.... wait for it... the quantities here do not have any known units (it depends on how the model is scaled). So here we go again applying an absolute epsilon to quantities of unknown magnitude. 🤦 Which is guaranteed to end in heartbreak.
Let's say our model coordinates are meters, and we have a simple right triangle that is 9cm on a side. The `Normal` will have a magnitude of 0.09 * 0.09 = 0.0081 meters. So the magnitude squared of that vector will be 0.00006561 m^2. That is clearly less than 1e-4, therefore SafeNormalize will return 0.0 and Chaos will log a "degenerate triangle" warning about this triangle! For a 9cm per side right triangle!
Maybe the author of this code didn't realize that `SafeNormalize` has a 1e-4 epsilon check on the magnitude squared? Probably not, because I don't think the UE_SMALL_NUMBER check will _ever_ make sense with that in place. I mean, to be fair, it's _absolutely insane_ that SafeNormalize - a function working with double-precision values! - returns zero when the magnitude squared is less then 1e-4.
I guess maybe UE can get away with this when model coordinates match world coordinates, and so the units are centimeters instead of meters. A 9cm triangle being degenerate is a big problem, but a 0.09cm triangle being degenerate is I guess kinda sorta more acceptable.
But it's worth noting that there are a bunch of other peope complaining about this problem; it's not just us:
https://forums.unrealengine.com/t/degenerate-triangle-and-tvector-ensure-crashes/544465
Ok, so what do we do about it? Short of changing UE itself, I can only think of one solution: change the scale of our mesh. So that's what this PR does. It multiplies every vertex position in our meshes by 1024.0 (chosen so that only the exponent of the floating point number is affected, not the mantissa... I think I did that right?). And then adjusts the UCesiumGltfPrimitiveComponent matrix to scale by 1 / 1024.0 to bring the model back down to the correct size. With the mesh scaled up by 1024, the silly absolute epsilon becomes less silly. It means our right triangle would have to be less 0.1mm to be considered degenerate. I tried to find a way to scale only the physics mesh, but it didn't seem possible.
This PR is a draft because it's not super well tested and needs some cleanup, but it seems to work very well with the basis tests I've done so far.
Basically, in Unreal, the Chaos Physics system hardcodes certain epsilons that don’t adjust for the scale of the values. Something similar may be happening in Unity. In that case, the solution in the linked PR could also apply.
But we haven’t tried this out yet. If you end up modifying the plugin and address this error, let us know – we’d welcome a community contribution to resolve this!
The error is gone in the latest Unity version (>= 6000.0.14?)
2 Likes
I am using unity 6000.0.20f1 and still see this warning spam using source from URL https://tile.googleapis.com/v1/3dtiles/root.json
Detected one or more triangles where the distance between any 2 vertices is greater than 500 units. The resulting Triangle Mesh can impact simulation and query stability. It is recommended to tessellate meshes that have large triangles. Source mesh name: 0x00007fff17830d7d (Unity) StackWalker::ShowCallstack 0x00007fff17840d39 (Unity) PlatformStacktrace::GetStacktrace 0x00007fff18aa58ce (Unity) Stacktrace::GetStacktrace 0x00007fff1904c87f (Unity) DebugStringToFile 0x00007fff176206a0 (Unity) <lambda_4f956d5c6c9b55fb5841f9cc39e6625d>::operator() 0x00007fff17613a08 (Unity) <lambda_4f956d5c6c9b55fb5841f9cc39e6625d>::<lambda_invoker_cdecl> 0x00007fff17b3bdb3 (Unity) PhysicsCommands::Physx::CookAnyPhysicsMesh 0x00007fff17b32232 (Unity) PhysicsCommands::Physx::CookCollisionMesh 0x00007fff176282db (Unity) Physics::CollisionMeshCooking::CookMeshFromUnityMesh 0x00007fff1761029b (Unity) PhysicsModule::CreateNxMeshFromUnityMesh 0x00007fff175c1a38 (Unity) CollisionMeshData::BakeSharedPhysicsMesh 0x00007fff175fa039 (Unity) PhysicsManager::BakeMesh
Hi @Thaina_Yu , welcome to the community!
I’m not sure that there’s much we can do about this. At some low levels of detail, we show the entire Earth as one model. If we tessellated all the triangles over Earth’s ~500 million square kilometers to be only 500 meters at most, as the message suggests, the model would have hundreds of millions of triangles and Unity’s rendering would surely grind to a halt (if the system didn’t crash first due to being out of memory).
If the latest versions of Unity 6 are still spamming this message, I suggest reporting it to Unity as a bug.
I think it’s worth checking that the message you’re seeing is coming from a Cesium mesh, though. The OP clearly had Cesium in the call stack, but I don’t see anything Cesium-related in your call stack. Is it possible you have another very large mesh?
This is full callstack
Detected one or more triangles where the distance between any 2 vertices is greater than 500 units. The resulting Triangle Mesh can impact simulation and query stability. It is recommended to tessellate meshes that have large triangles. Source mesh name:
0x00007fff19050d7d (Unity) StackWalker::ShowCallstack
0x00007fff19060d39 (Unity) PlatformStacktrace::GetStacktrace
0x00007fff1a2c58ce (Unity) Stacktrace::GetStacktrace
0x00007fff1a86c87f (Unity) DebugStringToFile
0x00007fff18e406a0 (Unity) <lambda_4f956d5c6c9b55fb5841f9cc39e6625d>::operator()
0x00007fff18e33a08 (Unity) <lambda_4f956d5c6c9b55fb5841f9cc39e6625d>::<lambda_invoker_cdecl>
0x00007fff1935bdb3 (Unity) PhysicsCommands::Physx::CookAnyPhysicsMesh
0x00007fff19352232 (Unity) PhysicsCommands::Physx::CookCollisionMesh
0x00007fff18e482db (Unity) Physics::CollisionMeshCooking::CookMeshFromUnityMesh
0x00007fff18e3029b (Unity) PhysicsModule::CreateNxMeshFromUnityMesh
0x00007fff18de1a38 (Unity) CollisionMeshData::BakeSharedPhysicsMesh
0x00007fff18e1a039 (Unity) PhysicsManager::BakeMesh
0x00007fff18258dc6 (Unity) Physics_CUSTOM_BakeMesh
0x000001f902aff786 (Mono JIT Code) (wrapper managed-to-native) UnityEngine.Physics:BakeMesh (int,bool,UnityEngine.MeshColliderCookingOptions)
0x000001f902afee63 (Mono JIT Code) UnityEngine.Physics:BakeMesh (int,bool)
0x000001f902afed4b (Mono JIT Code) Reinterop.ReinteropInitializer:UnityEngine_Physics_CallBakeMesh_dUTFInDZC08B3wpYvm01lw (int,byte) (at ./Library/PackageCache/com.cesium.unity/Runtime/generated/Reinterop.RoslynSourceGenerator/ReinteropInitializer.cs:63440)
0x000001f83f64fa63 (Mono JIT Code) (wrapper native-to-managed) Reinterop.ReinteropInitializer:UnityEngine_Physics_CallBakeMesh_dUTFInDZC08B3wpYvm01lw (int,byte)
0x00007ffef3f316f9 (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007ffef3f251e3 (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007ffef3fd8176 (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x000001f902ab8f69 (Mono JIT Code) (wrapper managed-to-native) Reinterop.ReinteropInitializer/ActionNativeFunction:System_Action_InvokeCallback (intptr)
0x000001f902ab8e13 (Mono JIT Code) Reinterop.ReinteropInitializer/ActionNativeFunction:Invoke () (at ./Library/PackageCache/com.cesium.unity/Runtime/generated/Reinterop.RoslynSourceGenerator/ReinteropInitializer.cs:58231)
0x000001f902ab8bc1 (Mono JIT Code) System.Threading.Tasks.Task:InnerInvoke ()
0x000001f900bd7625 (Mono JIT Code) System.Threading.Tasks.Task:Execute ()
0x000001f900bd754b (Mono JIT Code) System.Threading.Tasks.Task:ExecutionContextCallback (object)
0x000001f900b9d46e (Mono JIT Code) System.Threading.ExecutionContext:RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
0x000001f900b9c79b (Mono JIT Code) System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
0x000001f900bd7043 (Mono JIT Code) System.Threading.Tasks.Task:ExecuteWithThreadLocal (System.Threading.Tasks.Task&)
0x000001f900bd66cb (Mono JIT Code) System.Threading.Tasks.Task:ExecuteEntry (bool)
0x000001f900bd63e3 (Mono JIT Code) System.Threading.Tasks.Task:System.Threading.IThreadPoolWorkItem.ExecuteWorkItem ()
0x000001f900b99129 (Mono JIT Code) System.Threading.ThreadPoolWorkQueue:Dispatch ()
0x000001f900b97ee3 (Mono JIT Code) System.Threading._ThreadPoolWaitCallback:PerformWaitCallback ()
0x000001f900b98455 (Mono JIT Code) (wrapper runtime-invoke) <Module>:runtime_invoke_bool (object,intptr,intptr,intptr)
0x00007fff0521697e (mono-2.0-bdwgc) mono_jit_runtime_invoke (at C:/build/output/Unity-Technologies/mono/mono/mini/mini-runtime.c:3445)
0x00007fff05158444 (mono-2.0-bdwgc) do_runtime_invoke (at C:/build/output/Unity-Technologies/mono/mono/metadata/object.c:3068)
0x00007fff05195de5 (mono-2.0-bdwgc) worker_callback (at C:/build/output/Unity-Technologies/mono/mono/metadata/threadpool.c:386)
0x00007fff05198d83 (mono-2.0-bdwgc) worker_thread (at C:/build/output/Unity-Technologies/mono/mono/metadata/threadpool-worker-default.c:502)
0x00007fff0518806b (mono-2.0-bdwgc) start_wrapper_internal (at C:/build/output/Unity-Technologies/mono/mono/metadata/threads.c:1272)
0x00007fff0518827e (mono-2.0-bdwgc) start_wrapper (at C:/build/output/Unity-Technologies/mono/mono/metadata/threads.c:1348)
0x00007fffa8837374 (KERNEL32) BaseThreadInitThunk
0x00007fffa8a1cc91 (ntdll) RtlUserThreadStart
I am facing the same issue. It started with an error that crashes the editor in Unity 6000.0.0f1 and after updating to 6000.0.21f1 it is now a warning. I can see that it is not doing much but it’s causing Unity to be slower and therefore the app is slower in play mode.
When we get a chance, we’ll take a deeper look and see if we can find a workaround, even though I’m not extremely optimistic. In the meantime, I suggest reporting this to Unity. I would hope they could at least change Unity so that it reports this just once, rather than slowing down the app by spamming it.
