Please also implement it for Instanced Static Mesh components. That way, it can be used with PCG and foliage 
Ideally also for Landscape Grass Types, those are very fast and efficient. 
Will bring gigantic performance boost 
Hi, for the Foliage, you can select the Foliage Actor and in the details, select the FoliageInstancedStaticMeshComponent and change it from there.
I’m not sure about PCG though, you may be able to access the HISMC and change it from blueprint.
I guess that’s better than nothing but it would be more ideal if it could be set on the foliage type like most other settings.
Thank you for letting me know - it’s also possible in PCG by selecting the ISM components the PCG Volume spawns in the world outliner.
None of these options work for GPU spawned PCG ISM Components, tho.
It would be amazing to have this option for Landscape Grass Types and FTs, too.
More fine grained controls in the ISM/HISM components would be good, too. Making sure it can be set inside the PCG Graph instead.
What makes you say that? I’m finding PCGs runtime generation + GPU compute perfectly capable of landscape grass. But I think runtime generation doesn’t let you set up the actor in the outliner like pre-built, so any settings that aren’t exposed are inaccessible.
Like RecourseDesign mentioned, perhaps it can be set via blueprint or something in runtime after generation.
The nanite programmable pixel distance can’t be set via blueprint. I did dig a bit
Maybe using HLSL it could be set?
I’m pretty sure I’ve seen a tutorial on PCG where the author accessed the HISMC itself from a Blueprint - there was a setting from memory called Post-Process Blueprint in the StaticMesh Spawner.
I just had a quick look to see if I could find the video but didn’t have any luck.
Maybe ask someone on the PCG channel of the Unreal Source Discord server?
Edit: Right, There’s a getter for it but not a setter so that wouldn’t help anyway - I would think that will be added fairly soon though.
Not sure if HLSL would work. You’d have to dynamically branch away all pixel programmable functions. Even if you did I’m not sure that would necessarily result in nanite knowing to automatically switch to fixed function shading.
Edit: I’m speculating here though. Ultimately I need to look at what exactly that setting is doing under the hood… I guess my point is just that there’s a chance that if nanite doesn’t detect these features (mask, WPO, PDO…) it may automatically switch.
No idea what would be involved in dynamically branching the shading model though. So I’ll have to give it a solid maybe.
Exactly, there is a getter, not a setter. I talked to someone from the PCG team and they mentioned it’s up to rendering to expose it to the relevant components.
Mainly FISMComponentDescriptorBase
I could imagine it autoamtically switching.
But I was wondering if via HLSL it could be possible to just set the PP distance variable.
Because there is HLSL exposed in PCG, to some extent
I think it is more the opposite - the HLSL reads the bool to determine if it should be pixel programmable or not, and then the shaders go from there.
#if NANITE_PIXEL_PROGRAMMABLE appears to be what the shader is looking for when deciding if it will allow those features.
You can also default it to enabled in the engine code with a distance to use as a global max value until we get better support.
I’ve also added support for it in rdInst, adding it as a property for instance settings in each actor and a setter function for any HISMC/ISMC.
Nice! I have this plugin. I will try it out.
That code is in the new version (1.50) that I’ll hopefully be updating on Fab in around a week.
Those are some nice steps.
No luck on the HLSL side. Unless I messed something up, branching does not seem to have any impact - and I’m getting the impression it might be impossible to branch the blend mode anyway.
So basically I think the nanite pass is switching to a different permutation based on the distance, so the dynamic permutation is still viewed as pixel programmable due to having something plugged into the relevant pins, even if the value branches to 0.
Thanks for looking into it. Makes sense.
From what i can see, this means that for anything GPU-generated, we can’t set the NPPD value in PCG (or LGT or FT) currently.
Good idea, cheers.
Should not be terribly hard to port the setter code to the ISM or HISM components.
That being said, it doesn’t seem to be in current ue5-main (5.6)
Maybe for 5.7?
One of the best open world solution so far . Especially for conifer forests ! Also i did not noticed?? it is only in 5.5 ???
