Hi!
I was doing some optimization and found the not so well documented NanitePixelProgrammableDistance and have noticeable gain with static mesh that doesn’t need opacity mask from a distance. I did try with InstancedStaticMesh and the shadow pass is more expensive (I must say they cover a somewhat large area) instead of saving me 1ms it cost me +1ms as in the shadow pass it seems to duplicate everything with alot of empty call that sometimes cost .1-.3ms. Is there some limitation for NanitePixelProgrammableDistance with ISM? I’ve seen that the ISM Descriptor in PCG doens’t have that property exposed so I’m wandering if it’s because it’s not well supported with ISM?
cheers
Hi Daniel,
It’s intended to work with ISM as well as regular static mesh components the same. I would only really expect an increase in rasterization cost if you have many different masked materials that also use World Position Offset. In general, having many raster bins can be quite detrimental to rasterization speed, and NanitePixelProgrammableDistance will indeed inflate that by doubling up your masked materials bins if they also have WPO. If they don’t have WPO, they should properly fall back to a fixed function bin instead, which should be faster.
If this is what’s happening, taking steps to lower the total number of materials can help. You might also try Nanite Material Visibility (r.Nanite.MaterialVisibility=1) to mitigate this to pre-cull empty bins, though that typically only helps if you have a lot of primitives, and it adds a little CPU cost to trade for GPU.
-Jamie
Yeah those instance are using WPO as well as masked material so I would not use NanitePixelProgrammableDistance. And for the other that was saving 1ms It has WPO and Masked but both end up disabled.
Everything r.Nanite.MaterialVisibility was already enabled with the exception of r.Nanite.MaterialVisibility.Instances but enabling it doesn’t have noticeable effect.
Also is there any reason it wasn’t exposed in the ISM Descriptor in the PCG StaticMeshSpawner? I’ve added it to the descriptor on our side to do some test.
cheers
Unfortunately even with WPODisableDistance + NanitePixelProgrammableDistance you’ll get double rasterization dispatches, but the WPO logic will be branched over for clusters that disable it. In general it’s our recommendation to avoid masked geometry with Nanite for performance reasons like this.
r.Nanite.MaterialVisibility=0 by default, so if it was already enabled, it must have been done so in your project’s configuration.
No particular reason I can think of for NanitePixelProgrammableDistance to not be exposed to PCG, other than it’s just been overlooked. We should probably add it. If you’d like to submit your changes as a pull request, we could get them into the main line. Otherwise, I can open a ticket for it to get added if it’s not been done already.
-Jamie
Yeah we try to avoid Opacity Mask with nanite at all cost but we can’t avoid it a some place.
I think that config setting comes from someone from epic that shared the fortnite config.
For the PCG I’m not a programmer so it may not be as clean as it should even if it’s only 4 lines in 2 files ( ../Engine/Source/Runtime/Engine/Private/ISMPartition/ISMComponentDescriptor.cpp and .h) a “real” programmer needs to review my change.
Thanks for your help
Hi Daniel,
Just wanted to pop back in here real quick to let you know I submitted support for NanitePixelProgrammableDistance for ISM/PCG. The change is in ue5-main and will be available in UE 5.7: https://github.com/EpicGames/UnrealEngine/commit/62369d14823895fa4b58bd4f48e4c92d7783a71a
Cheers!
-Jamie