I’d like to highlight this pull request I’m opening, which adds a Niagara Data Interface to allow CPU niagara stages to write parameters onto material instance dynamic objects. https://github.com/EpicGames/UnrealEngine/pull/13222
We found this to be an effective way to circumvent the lack of Nanite support with Niagara effects - by assigning the material instance used on a mesh, to a Niagara user parameter, and setting some necessary parameters. This allows us to use a setup where we don’t use a niagara renderer to render a mesh, instead we only use niagara to implement WPO logic. Due to not having a niagara renderer, we need another way to send parameters to the material (instead of “DynamicMaterial0-3Binding”). This NDI offers a solution to that problem.
Having Nanite supported in Niagara would be a big positive, but wouldn’t fully cover what we can do with this NDI.
Currently this NDI gaps 2 situations:
no support for nanite
Being able to set as many material parameters as we like, instead of being limited to the 16 Dynamic Material Bindings available (we have had situations where we needed more)
Additionally, I think it is a good thing to have a way to set some material parameters just once - on spawn, which won’t change over the duration of the effect’s lifetime. Instead of being bound and continuously served to the material.
Dare I ask what the progress is of rendering Nanite in Niagara?
This isn’t really a replacement for dynamic parameters as they vary per particle, this is a material parameter which is applied to all particles (so to speak).
If you were working exclusively inside Niagara then you would use the Material Parameter Bindings, which is why I was asking about if you had Nanite rendering
[Image Removed]
What I do like is it allows Niagara to control external things, which opens more doors.
On Nanite rendering question, I had something working a while back for CPU emitters, and I just got around to finding time to get the GPU path working. It isn’t in the current mesh renderer and I’m not sure it will go back there, primarily because we have to inject our vertex factory which might add complications. So my current plan is to release an experimental plugin for the Nanite Renderer and experiment with a new path for sending data to materials using per instance data. Then this will either be the path forward, or we will roll it into the existing mesh renderer, that’s all tbd right now.
You make a fair point, the NDI is not a 1-1 replacement for particle dynamic attributes, as it’s a granularity level higher - per emitter, not per particle.
My use-case was for a physics body simulation, where there is one mesh rendered, and niagara is used to simulate joints within the mesh.
I’m with you, the more we can control from within Niagara, that is outside, the better in terms of minimising setup requirements (fewer blueprints, more portable, easier to understand).
So with that context reframed, do you reckon it could still get adopted?
it definitely has use cases for us.
Thanks for sharing your progress on implementing Nanite renderers for Niagara. Very exciting!
Do you have an estimate of which UE version it might land in?
