Hi. I have weird bug with DistanceToNearestSurface material, it happens on custom plane, default plane, custom big cube, i dont know why. BUT it works with default cube. It also works if I turn on Nanites on my mesh asset, but i can’t use Nanites for this mesh because I’m planning to use WPO.
Watch the video:
What I already tried and it didn’t work:
• Turn on and off “Generate Mesh Distance Field” on mesh.
• Two sided Distance Field Generation on and off.
• Distance field shadow bias values from -100 to +100.
• Turn off “cast shadows” for this mesh on level.
• “Distance Field Resolution Scale” from 0 to 100
• Distance Field Replacement mesh with cube
• Turning off “Affect Distance Field Lighting”
Additional info:
• Under clear sky there is no bug. It only happens under the rocks.
• Rocks are Nanites. Turning nanites off on them changes nothing. Rock material does not use any distance fields features.
• Visualize Mesh Distance Field with custom mesh (nanites on and off no difference):
Hey, thanks for the response!
The whole material of the plane was shown in first second of the video, it definitely does not contain any more nodes than was shown.
I tried to replace rock material by simple white material too – no effect.
I tried DistanceFieldGradient node, it had exactly the same artifacts too on every channel.
Plane has Affect Distance Field Lighting turned off and distance fields turned off, so it probably doesn’t do it to itself? But I’m not sure on this one.
Again, default cube works perfectly fine with the same material, but default plane doesn’t:
They’ll ignore it, but you ought to file a bug report with a downloadable project on that.
IT seemed like some sort of Z-Index issue. It’s probably something wrong in the render path…
Or it could be a GPU or driver specific problem. But yeah, he should report it just in case.
Another issue that can pop up too is when you non-uniformly scale assets. It can make the distance fields get messed up. A common mistake you’ll see dozens of threads about on here is people not understanding why there is light leaking in some house scene. Then you find out they used the default cube and scaled it around to make different walls and pieces.
That should be easily fixed by forcing the recalculation of the distance fields.
Distance field is essentially just a simplified mathematical interpretation of a mesh.
It does respond to scaling/manipulation.
The rendering issues are usually caused by not using manifold geometry.
Or, by placening 2 single sided distance field meshes in front of one-another (both sides of a wall).
Lack of understanding isn’t an engine issue - theyd have the same or similar issue in any engine they did stuff lile this.
The issue found is an acrtal bug. Regardless of what workaround solution was found.
And while it looks more like Z fighting than anything else, it shouldnt have anything to do with z fighting… theoretically at least…
The recalculation happens at the model level like as in when you open a static mesh in its own window. Any scaling there, on import, will allow the DF to be generated correctly. The problem is that AFTER you do that and drag the mesh into your leve, if you then non-uniformly scale the mesh in the level, it can break it.
Yeah, ideally, the editor would give an option to rebake them, after scaling adjustements within the level, but then you run into the problem of having 3000 starter cubes being scaled 3000 different ways, which means 3000 unique distance fields being generated and having to be stored in memory vs only having one for them all.
It’s a static baked texture that gets created on import. When you see it say “32x32x32” or something, it literally means 32 slices of 32x32 texture information.
I’ll test it out and edit this post, but I don’t think I’ve personally had this problem and I’ve made dozens of shaders like these for shore effects on water planes that are at Z=0.
