Is there no way to write material variables to niagara data channel? I’m generating a material dynamically and sending it to a niagara system currently, but there doesn’t seam to be a function to write materials. Does this need to be moved to the niagara effect in something like a scratch pad? Is it possible to call create dynamic material there or create canvases there?
Looking at the Sprite Renderer I don’t see a way to assign a module to it for the material source so I’m not sure where or how to best handle this for generating the canvas, texture, and material inside the effect itself.
So far only way I’ve been able to optimize it further is to use a lightweight emitter as I don’t need many features for floating damage numbers, but certainly wish I could figure out this NDC. Still can’t seam to find a way to generate the texture and material inside the niagara system or how to send the material to the NDC emitter.
Hi again @Krileon!
You are correct- there is no DIRECT communication from material to Niagara system (at least not to my knowledge.) That being said, there are a lot of ways to get around this limitation depending on what you’re trying to accomplish.
First of all, if all you need to do is set your particle system to your new dynamic material, you can do that pretty easily via blueprint.
If you’re generating a dynamic material instance with custom parameters, then you must be setting these values via Blueprint. Blueprint and Niagara can communicate via Data Channels or setting Niagara parameters, so ideally you can handle it that way if you need specific variable information.
Another, clunkier, method is to directly pull out variable information from your material. I am not familiar with C++, but these are some of the functions available via Python (not executable at runtime) so I have to imagine they have a C++ equivalent. I don’t really see you needing this though, since it can only read variables which should be set via Blueprint anyways.
If you need to pull out a specific calculation, that’s a lot trickier. I would say replicate it in a blueprint or your Niagara System if possible. If NOT possible, there are ways for Niagara to read color information, so your best bet is probably to send it through the material base color and reassign the material to the correct one after the calculation’s values are stored in the system.
Let me know if you want help with any of these ideas, and I’ll see what I can do. Otherwise, if these solutions won’t help you out, give me a little more information on the exact problem you’re trying to solve and I’ll try my best to guide you through a solution.
I always go to a material-parameter collection as the go-between as it’s widely-readable, and updateble as code. This way you can have your logic sink whatever into the mpc and then either write some of that to Custom Primitive Data itself, and/or a MPC. Either is readble in the material and once you set up the read, it’s usually go-to-go from there with little maint on that end (it’s a passive setup in the material).
Whatever is driving the niagara data-channel write/output can-also update the MPC or CPD. CPD is analagous to the data-channel but for mesh-thingies.
I don’t have any issues setting my material parameter for a non-NDC system. The problem with NDC is the Write functions don’t have a function for writing to NDC a material. Only things like int, float, vector, etc.. This material is entirely dynamic as I’m generating a render 2d target, adding text to it, and assigning the material then sending that material to niagara. It’s being used for floating damage numbers.
Below is what I’m doing.
This works fine and as expected. I’m using a lightweight emitter for it and works great. I was just seeing if I can make it even better using NDC, but NDC has no way to write materials to the data channel. Below are the only available functions to write to the data channel.
My point is bypass the NDC. It sounds like you wanted to write to the NDC and have it go into the material/material-instance as input/data?
Reference the stuff you wanted to push via NDC in the material, but instead have it point to the Material Parameter Collection (MPC). What you wanted to write as a scalar/4vec in the NDC, instead write into the MPC and it can be used as a live-channel into the material instead of the NDC.
My understanding is you somehow wanted-to get data you would otherwise inject to the Niagara System to ultimately get to the material, so my take is skip that and just-write-to something the material can reference directly. If you sync the updates to where you wanted to update NDC to the MPC instead, it should all come out in the wash at runtime; the different parts will be kept in sync.
I never thought of using niagara for damage numbers, I just made a floating widget with a status bar.
That is way above my head. I’m barely into learning materials so I’ll just continue with my lightweight emitter solution, lol. Hopefully NDC will be improved further to allow writing materials to user parameters as you can other types.
It works substantially better than widgets. Can have hundreds and hundreds of these on screen with basically no performance issues. Widgets however will eat performance like crazy. If only I could figure out a way to move healthbars to niagara, lol.
I could probably help you with the health bars! Likely all you’ll need is a green material with a red mask, and to move the mask in the material as they take damage. Let me know if you want help with this!