Geometry Collection Mesh Distance Fields

Development Asset Creation
, ,
1

This question was created in reference to: [Geometry Collection - Mesh Distance Field, Root [Content removed]

I’m curious in 2025, what are the future plans or current solutions/state for generating mesh distance fields from geometry collections.

Is it possible to have these work with the distance fields used by Niagara or contribute to Lumen GI yet? Is there any future roadmap for these issues?

It would be great to get some insight into this as in 5.5 it still seems like its not possible to implement a decent solution for having chaos geometry collections contribute to distance fields to be sampled by Niagara and Lumen. Thanks!

2

Hi Alex,

We don’t have any plans to supporting Mesh Distance Fields for Geometry Collections.

From 5.5 we recommend to use HWRT instead for Lumen and this is also what we use internally for all our projects (FN is shipping with HWRT on all current gen consoles), at least if your PC min spec allows that (or you can drop dynamic GI on your min spec).

3

Hi Alex,

As [mention removed]​ mentioned, there’s no plan for that

However, I’d like to highlight that there is way around this limitation

Marvel Rivals actually uses distance fields for geometry collection by leveraging the Embedded Geometry feature of geometry collection

They talk about it in this article:

https://www.unrealengine.com/en\-US/developer\-interviews/unreal\-engine\-powers\-marvel\-rivals\-to\-create\-a\-new\-multiverse\-of\-marvel\-heroes

I don’t have all the details, but my guess is that they create the geometry collection , export them as meshes ( the fracture tools provides such feature ), then set those meshes as embedded geometry in the geometry collection

To avoid the rendering duplication, it is possible to strip the original geometry from the collection ( settings on the geometry collection )

With 5.5, the custom renderer feature for geometry collections could achieve the same effect potentially (rendering each piece of the geometry collection using ISMs )

We don’t have an official documentation for it, we hope to have one soon

I hope this helps

Cedric

4

An ideal solution would be to instead build the Global Distance Field from Nanite or BVH data at runtime. This way we can bypass all the static mesh baking workflow issues and support all geometry configurations. Its something we would like to do at some point, but there are no concrete timelines for that.

In the meantime likely the simplest workaround would be a single mesh SDF proxy for the entire GC (non-destructed state), which disappears when GC breaks. Or try to integrate that proxy directly into GC.

5

Hello Cedric,

Thanks for the reply, I did read that article a few times previously, its a good one that highlights the problem space. The answer wasn’t immediately clear to me on how they actually overcame it other than using some kind of proxy mesh that contributes to distance fields. I’m not sure its practical for more widespread destruction of buildings and such as it would result in thousands and thousands of static meshes needing to be added to the project as static meshes. Would make it hard to manage on a larger project I think.

I agree that more documentation around these issues would certainly be appreciated.

Thanks,

Alex

6

Obviously not what I was hoping to hear but, nonetheless, I appreciate you sharing the current roadmap and approach here, its helpful to know. Thank you.

7

So I think I initially misunderstood. You aren’t saying to drop lumen, but rather enable HWRT with Lumen. Can you explain how this helps with mesh distance fields on geometry collections please?

8

I think @Krzysztof.N meant that when enabling hardware RT Lumen, more types of geometry are supported as described in this documentation :

If you enable Nanite on Geometry collections, I believe you should be able to get HW raytraced Lumen to work with it