Hello, I am working with large terrain meshes based on real world data. These tiles represent 1 latitude x 1 longitude at around 100m resolution. These meshes are stored at 1/100th scale and have a scale of 100 applied in the scene. When attempting to perform line traces against these meshes, the hit point is inaccurate, often significantly above or below the displayed surface of the mesh. I made a reduced test case project, where tiles would be placed closer to world origin than in our actual project, and in doing so I observed that disabling the “enable ray tracing” option in the static mesh config significantly improved the accuracy of traces, but did not fix the issue completely. However I was unable to reproduce this result in our actual project, which displays the same inaccuracy regardless of that setting. I also did some digging through chaos, and noticed that much of chaos is still using single precision floating point math, but I was unsure if this was enough to explain what I had observed. I notice that the inaccurately detected hit point is proportionally affected by the mesh’s transform in the scene, as in the difference between the point detected as a hit and where I expect the hit to be detected (the actual mesh surface) will translate, rotate, and scale with the mesh, further supporting my belief that this has something to do with some inaccurate collision acceleration structure I am seemingly unable to influence.
Steps to Reproduce
See demo project, line trace is displayed at bookmarked camera position 1, hit point calculated through various methods is indicated by debug sphere, hit point is not on surface
Hello [mention removed]
Thank you for reaching out and bringing this issue to our attention.
Also, thank you for taking the time to create this repro project.
I was able to reproduce the behavior as described.
I’ll investigate some more and let you know.
All the best,
[mention removed]
Hey Rafael,
Thanks for taking the time to look into this, and glad you were able to reproduce the issue! Let me know if there’s anything else you need from me.
Hi [mention removed] ,
Thanks for the follow up! I attempted the following:
- Create a new empty level
- Add SkyAtmosphere, SkyLight, DirectionalLight, RayCaster, our Terrain mesh
- Set terrain to properly block all
I still observe the inaccuracy mentioned in my above post. It’s worth noting that the degree of inaccuracy is positional. If I translate BP_RayCaster while simulating, the surface hit point will move as though it is on a locally-flat surface, at some points below the geometry, at others above it. It’s visually almost as if the mesh is using displacement for rendering, which I do not believe to be the case, or if the LineTrace function is tracing against a decimated version of the terrain, which also shouldn’t be the case (unless there’s some configuration I missed).
Can you confirm if you produced a case where the tracing remains accurate regardless of intersection location?
Thanks again!
[mention removed]
Hey [mention removed]
For whatever reason, I’m not able to view the complex collision mesh in the editor, but that observation matches my intuition of the problem. Any advice on a workaround? This project already has some engine modifications, so if it’s possible to change that maximum resolution, that’d be an acceptable approach.
Thanks,
[mention removed]
Hello [mention removed]
While testing, I noticed something interesting: if we use a Basic or Empty Level as a basis and add both SM_Terrain_100x188 and BP_RayCaster, the behavior looks correct.
[Image Removed]If that’s the case, the issue might not lie within physics itself, but in Open World levels.
I’m still investigating, but I wanted to share this finding immediately and, if possible, get your confirmation that this behavior reproduces on your end.
I look forward to hearing from you soon.
All the best,
[mention removed]
Hello [mention removed]
Thank you for the reply.
I’ve tweaked your project and added a new level, following your instructions.
I’ve added a runtime animation so we can have a reproducible path.
With that, I noticed that indeed the collision on some hills looks wrong - the sphere goes under them.
However, when inspecting the SM_Terrain_100x188 mesh, its complex collider does not appear to follow the terrain with sufficient accuracy. You can see them intersecting in many places:
[Image Removed]I’ve shared the updated repro project.
Could you take a look and confirm that’s what you are seeing?
I’ll continue investigating, but I suspect we’ve reached a limit in the resolution of the complex collision mesh.
All the best,
[mention removed]
Hello [mention removed]
To enable the rendering of the Complex Collision mesh in the Static Mesh Editor, use Show>ComplexCollision:
[Image Removed]
Regarding the complex collision, which was clearly a decimated version of the mesh you provided, I might have found a workaround:
Open the SM_Terrain_100x188 mesh, and on the Details Tab, go to Nanite Settings > Fallback Target.
The default is Auto: change it to Percent Triangles and leave Fallback Triangle Percent at 100.
Below, press Apply Changes:
[Image Removed]This is what I had:
[Image Removed]This is after bumping up the Fallback Mesh to 100% of the original:
[Image Removed]It’s so dense it “breaks” the rendering by flickering.
But now, whenever I do the raycasting, the collision always matches the surface of the mesh:
[Image Removed]Although I haven’t verified the implications of such an approach, I also didn’t notice a significant impact on performance - you might need to profile in your particular project to confirm this is not causing issues.
Let me know if this is helpful.
All the best,
[mention removed]
That’s certainly an interesting, if a bit surprising of a fix. I was able to confirm that this does result in accurate line traces in my test scene. I don’t foresee this causing performance issues in our actual project due to the traces themselves, as we trace infrequently, but I’m curious as to what implications this might have for rendering performance. I’m still working on integrating this into our project, and may have more to say when I’m able to test there.
Thanks for the insight!
Hello [mention removed]
I don’t expect this to impact rendering, as colliders are invisible.
It might impact the physics side, though.
I suggest you profile the memory footprint and physics timings to avoid surprises.
As this solution resolves your issue, should I mark this case as closed?
Let me know.
All the best,
[mention removed]
Hey [mention removed]
Just wanted to follow up and keep a pulse going. Haven’t been able to confirm viability of this setting in our project, so I’m not ready to call this closed yet, but I’ll be sure to update as soon as I can confirm.
My primary concern is that this, being a Nanite setting, will have an impact on the performance of Nanite, both in terms of runtime and storage, and it’s not quite as simple as just hitting the checkbox in the context of our project. The physics performance will also be relevant to this project, though talking with my co-workers, it’s unclear at this time what the scale and sensitivity of that will be.
If there’s any other suggestions, I’d be interested in them, but otherwise I’ll reply again as soon as I’m able to verify that this fallback setting is suitable for our needs.
Thanks again!
[mention removed]
Hello [mention removed]
Nanite can change its detail density based on camera distance. This can cause issues with many UE systems, and that’s where the Fallback Mesh is used: it is a sort of conventional static mesh approximation that is kept alongside Nanite and used by systems that don’t work with Nanite or hardware that doesn’t support it.
Collision is one of such systems. Instead of colliding with the Nanite surface, the line trace will hit the Fallback Mesh. Another system that uses the Fallback Mesh is Ray Tracing - that might explain your observation that disabling it affected collision-hit accuracy.
To generate Fallback Meshes, Unreal provides three Fallback Target modes: Percent Triangles, Relative Error, and Auto (which in turn chooses one of the other two). When I suggested you set Fallback Target to Percent Triangles and Fallback Triangle Percent to 100, I assumed you wanted a perfect match between Nanite’s visual representation from up close and the position of the collision that is being taken from the Fallback Mesh. This might not be the case. You probably can get away with a much less dense mesh, but that is entirely dependent on your requirements.
In your Repro project, it looks like Fallback Target Auto is choosing Relative Error with Relative Error at 1.0 - the resulting mesh is very low density when compared to the Nanite mesh when observed from up close, no wonder the hit result was so far from the visual surface.
I recommend you experiment with these settings to see how low you can go while still maintaining an acceptable error, and don’t forget the importance of the distance between the camera and the Nanite mesh while testing.
Let me know if this is helpful.
All the best,
[mention removed]
Hey [mention removed],
I forgot to add that I’m waiting for the results of your tests.
Take your time.
I’ll leave this case as Open; otherwise, it might auto-close.
All the best,
[mention removed]
Hi again [mention removed]
While I haven’t been able to test performance at our application’s scale with this approach, this setting does appear to result in accurate collision tests. Thanks again for digging into this!
Hello [mention removed]
No problem, it was my pleasure!
Thank you for marking my reply as “Best Answer”!
Have I addressed your questions?
Should I close the case?
If you need further help, you can either reply, and the case will automatically reopen, or you can open another case and reference this one.
Let me know.
All the best,
[mention removed]