Mesh Distance Field Generation has different result on different machine

We got different Mesh Distance Field results on different machines in UE5.1 for basic engine shapes, like the cylinder or cube. We have the same VoxelDensity (0.2) and MDF Scale.
The results are attached below:
图片
Have any idea what causes this?

1 Like

Are they running the same engine version and project settings? There have been adjustments to the default resolution and stuff over time.

Left one looks like the global distance field not the mesh distance field

Yes. Same engine version and settings. I captured the settings below:
Project Settings:
图片
Build Settings for the Cylinder
图片

Is there anything else I need to check?

Yes, you’re right. The left one is the global DF, and I attached the global DF for the right cylinder below.


There’s no bumping on the cylinder.

I’ll dump all the intermediate data for the cylinder MDF generation.
UE5 uses Intel Embree to generate signed distance field data for mesh. I’ll dump the in-params for Embree’s interfaces and the ray tracing out data by Embree.

Looks like one of the cylinders is aligned to XYZ axis and one is slightly tilted. There are stepping artifacts in distance fields when assets don’t align with the underlying grid.

…So are you actually experiencing some kind of problem? Or are you just bothered by the way it looks in the debug view?

The global distance field is generated at runtime and it will look different depending on where you are and the objects position/orientation in space

It’s a problem. The bumping side of the cylinder is incorrect, and it should be smoother.

I dumped the intermediate data for the cylinder mesh distance field generation, and it showed that the runtime-generated hemisphere sample directions were incorrect.


All the y components are ZERO. The left one is from the machine with this problem, and the right one is from mine, which is correct.

Another thing is that the machine with this problem uses AMD CPU, and mine uses INTEL.

I mean… yes. But also you generally do not view distance fields directly, they’re used as a part of another feature such as Lumen, DFAO, particle collision… If it causes a noticeable problem there then that is understandable.

So far, it has yet cause any visual problems since we are still in the pre-production stage.
But we are running the rendering functionality tests on the build machine, and it fails while running distance field tests.
We can’t assume it will cause no visual problems while the assets pile up. So we need to solve this, or at least understand what causes this.

This problem is because the function UniformSampleHemisphere fails on the AMD CPU.


The workaround is to disable optimization for the function, and the MDF result is correct.

I’m not sure what causes the failure. The compiler reorders the operations and alters some instructions into more efficient SSE2 instructions in code generation optimization.
Both of them may cause incompatibilities on AMD CPU.

The assembly code with optimization enabled:

The assembly code with optimization disabled:

The compiler uses sse2_sincos to alter sin and cos. This one is suspicious and needs more investigation.
Does anyone have any ideas?