[Nanite] Corrupted Vertex Color

Development Rendering
,
1

Hi,
I am trying to perform a world position offset on a mesh based on values I store in the vertex color attribute. This works perfectly fine on “normal” static meshes, but when I convert them into Nanite meshes, I get corrupted values when clusters get split / merged.
I managed to reproduce that issue with a simple sphere made in Blender.

Here I have a sphere where all vertices have a black vertex color expect some located on 3 distinct rows:

image
image975×522 56.3 KB

Once exported in UE 5.3, I created a simple material to perform the WPO operation:

image
image975×685 117 KB

I then created two spheres, one simply as a “normal” static mesh, the other one as a nanite static mesh, then applied that material to both:

image
image975×551 41.5 KB

As you can see, there is a missing piece of the geometry with the nanite version.
If I move the camera away, things get worse:

image
image975×498 36 KB

When disabling the WPO and just inspecting vertex color, we can see that the nanite version is distorted:

image
image975×500 42.6 KB

I’m wondering if it’s part of the issues mentioned here: https://youtu.be/eviSykqSUUw?t=1241
I tried to disable vertex interpolation here and pick the value of the closest vertex, but that did not have the expected result:

image
image1538×836 166 KB

I am very close to encoding those WPO values into a dedicated texture exported with the FBX, but that would be the last resort. Any suggestion to address this? Am I missing something?

Sphere_VertexColorTest.blend (2.5 MB)

2

Nanite will simplify the mesh, and as the verts are decimated in real time, the stored vertex color data will become inaccessible in the shader.
I would only encode something in vertex colors of a Nanite mesh if it is not critical that it be stable over a distance.

3

Thanks for the answer. From what I am seeing, it’s not really inaccessible, it’s more like, it’s not an exact 1 to 1 data conversion, and some errors might be introduced during conversion…
I tried to store that data in an unwrapped texture, but UVs have the same issues, so when I am sampling the texture, I end up sampling at the incorrect coordinates too…
Is the conclusion really that Nanite doesn’t offer a stable per vertex data storage mechanism?

4

You could try enabling full precision UVs to see if that helps, and if necessary using more accurate filetypes like OpenEXR which supports 32 bit floats. I talk about these things in this video where I sought to correct a UV sample point issues on one of my projects, due to the normal baking pipeline.

Personally I only found it useful to store data like simple masks in nanites meshes, like the ones used for procedural texturing, where a bit of instability would be largely unnoticed.

The specific issue with your interpolation is that if you have 3 sample points with values of 0, 1, 0 but then you decimate to two sample points, you will interpolate from 0 to 0 and all displacement will be lost. Because Nanites preservation method is precomputed you will have significantly better luck starting with your displaced mesh and storing the vectors to un-displace it. Then, Nanite will prefer to preserve polygons on the areas with detail, instead of assuming them to be flat.

5

Thanks a lot, I’ll have a look at that video!