We are observing weird graphical results when using emissive actors (Emissive light source = true) that use materials with custom primitive data to define the color of the emissive materials.
We can see that the lumen scene contains incorrect colors for the materials representing the emissive light sources.
We did some experiments and we found out that disabling nanite for these actors (disallow nanite = true) fixes the issues.
We are not able to reproduce the issue in simple scenes and we are trying to narrow the combination of things that create the issue.
Is there any limitation that we should know when using nanite, custom primitive data and emissive light source mesh actors?
Is there any limitation that we should know when using nanite, custom primitive data and emissive light source mesh actors?
A specific limitation doesn’t come to mind, but in the past we’ve seen issues with Material Layers on Nanite objects causing issues - are material layers involved here?
There was an issue in 5.5 that should be fixed in CL#37259530 where Nanite Software VRS uses the custom primitive data for the primitive under the upper left pixel of a cluster, rather than the primitive under the centroid and this was visible easily with Emissives or BaseColor. You could turn off VRS to see if it has an effect with r.Nanite.SoftwareVRS=0.
If you can provide additional info like a screenshot of the problem that includes the lumen scene that could help. If you’re using SWRT Lumen may not be able to generate enough surface cards for the Nanite object if it is sufficiently complex - and maybe your non-nanite object is simplified? This should be easy to spot by comparing the Lumen scene with and without Nanite on those objects.
Thanks for your quick answer. Unfortunately r.nanite.softwareVRS=0 didn’t make any change.
Here you have a comparison screenshot of the lumen scene (right image is the good one, the only difference is that the sphere mesh has disallow nanite = true).
You can see that the red material is barely visible in the left image.
Is the sphere casting any light at all in the left image?
Are you using material layers on this emissive material? In the past I’ve seen issues passing data down that was contained in material layers so if that’s the case here, you may try a simple material setup as a test.
Also, do you have any warnings or errors in the logs that might be related?
In the left image the sphere seems to cast a color in one direction of the hemisphere and another one in the other direction with low intensity, I would say that the colors belong to the lumen scene (you can see that the sphere has two different colors in opposite directions).
We are not using materials layers in the emissive material.
Here you can see the graph that is pretty simple:
[Image Removed]There are no relevant warnings in the log.
I will continue making more experiments and keep you updated.
I created a simple 5.6.0 project with a lot of emissive meshes (map Content\Developers\SergiGonzalez\TestEmissiveCPD).
I was not able to reproduce the same issue that we are having with more comples scenes but I found a weird behaviour that could be related.
If you fly quickly you will see that some spheres get an incorrect material when they are being updated. They will get the correct color after some time.
This does not happen if you disable nanite from the sphere mesh or using DisallowNanite from the static mesh actors.
If you use a material that does not use custom primitive data, the spheres also display the correct material all the time.
Let me repeat that this is not the same problem that we are having.
Update: Setting any of the following variables fixes both issues
Apologies for the delay. Thank you for providing this sample project, it appears the method we’re using to detect Materials with CPD is not working reliably in NaniteResourcesHelper.h. Lumen card sharing is not support to be active on Nanite meshes with custom primitive data and I was able to verify this in the debugger by checking the results and by changing the source to not use the cached data, which does appear to detect custom primitive data correctly.
`auto IsCompatibleWithLumenCardSharing = &
{
if (Entry.Material->IsCompatibleWithLumenCardSharing())
{
// Material is explicitly marked as compatible
return true;
}
// bHasPerInstanceCustomData should be TRUE but isn’t
//&& !CachedMaterialData.bHasPerInstanceCustomData
// HasCustomPrimitiveData() does return TRUE
&& !Entry.Material->HasCustomPrimitiveData()
&& !CachedMaterialData.bHasWorldPosition;
};`As you noted, you can disable card Lumen card sharing or card sharing detection to workaround this issue. Lumen card sharing is mostly useful in scenes with many instances of the same Nanite mesh - like scattered rocks on a landscape, especially on background objects, so you may not even notice a performance differenced by disabling it.