Hiya, this issue was finally resolved by changing the plugin load timing as below.
NiagaraUIRenderer.uplugin
“Modules”: [
{
“Name”: “NiagaraUIRenderer”,
“Type”: “Runtime”,
“LoadingPhase”: “Default”, <=== Changed to “PreDefault”
1 Like
I have another question.
Is it possible to use Dynamic Material Parameters with this plugin?
I have a material that is being faded in using a dynamic parameter, it is working fine in the Niagara System editor. The replacement UI version of the material also has the Dynamic parameter set up, but doesn’t get faded when running as part of the NiagaraSystemWidget.
The fade works if I assign it to a sine node etc. instead, but the Dynamic Material Parameters do not seem to be updating when used with the Niagara UI Renderer plugin.
Am I missing something or is it just not supported?
Best Regards,
Hi, Thanks for letting me know. I’ll include this fix in the next plugin update.
Unfortunately the UI material is very limited in comparison to the “normal” particle material. The way it works right now is by using the SMeshWidget which only supports FSlateVertex which limits what data can be send to the material. Because of that I can’t pass most of the particle data in (things like ParticleRandom, DynamicMaterialParameters, …). That’s the reason why you can’t even use particle color, but I have to convert it to a vertex color, which limits it to 8 bits per channel.
There’s one thing that could help you with the Dynamic Material Parameter. As a workaround for sprites, I’m sending the first Dynamic Parameter R and G channels to Texture Coordinates with Coordinate Index 1. I know that It’s not ideal, and it’s very limiting, but that’s the best I can do for now.
Thanks for the Information, I’ll look into that.
Hello, I just want to report a crash bug I found.
When disabling one of emitters in the Niagara System that attached to the Niagara System Widget, then go back to the widget blueprint, UE engine crash. Open it up again, trying to open or even just click the widget blueprint file in the content browser cause the crash again.
Enable the emitter in the NS will fix this.
Conclusion, don’t disable emitters in NS when attached to Niagara System Widget to avoid engine crash
I use UE 5.0.2
Hope it helps
Hi, Thanks for reporting the bug. I’ve pushed a fix for it to the GitHub repo. I’m going to include it in the next plugin update, but in the meantime, you can just get it from GitHub if you need to.
1 Like
Hey it’s me again. After a while playing with the plugin, trying to understand it, I want to make sure if I get it correctly so I don’t create bunch of same and unused materials in my project.
Let’s say I have 1 surface master material for UI purpose that will be used in many area.
I use that 1 surface master material for the Niagara System (NS) to render it correctly in NS viewport.
I convert the master material into UI material and use it in Niagara System Widget (NSW), tweak the VFX as much as I want through the NS and its own UI material, but since the final result will be the one in NSW, I can ignore the render looks in the NS viewport.
The next time I want to create another UI VFX, I can reuse the same surface master material just for rendering purpose again in NS viewport, but create another UI material for its own UI VFX.
So I come to conclusion that I can create just 1 surface material to use it for as many UI materials as I want. Is it right?
Hi, yes, you’re right. If you don’t care about how the Niagara System looks like in the world / particle editor, you can totally use just one surface material for all your systems. The only reason for having multiple materials in that case would be having multiple renderers with different desired UI materials in the widget. In that case you’d need a unique surface material / material instance for each different UI material.
Cool!
One more thing, I tried to use UI material instance as remap material in NSW with the surface material as the original one and it works. But using surface material instance as the original material in NSW, it can’t be rendered in the widget.
Is it a must to use surface material (not the instance one) as the original material in NSW?
You should be able to use a material instance for the surface particle material. I’ve tried it out, and it seems to work without any issues. Please make sure the material instance is the same in the particle renderer Material property as it is in the material remap list in the widget.
If you’re sure that everything is set up correctly and the issue still persists, please send me detailed repro steps / example project with the issue, and any details you can think of. Thanks.
Hey sorry for late reply,
yeah I think it was an error from my side since I was still learning how the plugin works, etc. Never have issue with the material instance anymore.
As I try the plugin more and more, I think the best and neat workflow is keep using 1 surface material (or instance) for 1 UI material (or instance) even if not planning to render the vfx in world space. To minimize confusion which surface material has been used for UI material.
Was in state when I want to use 1 surface material for different UI material in different emitters but can’t duplicate the material in material remap list for two different UI material 
Any thoughts about this?
Another thing, I wonder if it is possible somehow to activate the Niagara System Widget in the UMG animation window and play it just in editor like scrubbing the timeline and we can see it starts playing the vfx. I tried with “enable” and “visible” the NSW in animation window, it didn’t work.
Hi, the material remap list works for the whole widget, not individual emitters. Which means you can remap each surface material to only one UI material for the whole Niagara system. If you want multiple emitters to have different UI materials, they must have different surface materials too.
1 Like
Yes, you can absolutely do that. You can check out the demo project to see how to do that. A good example is in the “WB_NiagaraDemo” in the “ShowDemoText” animation. I’m activating/deactivating particles there with events that have “Call in Editor” enabled.
Cool, thank you! I’ll into it
Hello!
I’ve had created a pretty advanced particle effect to serve as a loading screen of sorts for my game. My goal is to call this “WBP_LoadingScreen” every time I hit a loading thread in the game or do it manually through a plugin ( Common Loading Screen in Code Plugins - UE Marketplace (epicgames.com))
While all particles are CPU, I’m wondering if it’s possible to coordinate when the effect starts/ends/when it’s active. Trying to add a delay off your simple example isn’t working and I’m wondering if I’m doing something wrong.
Thank you for the amazing plugin so far!
Hi, unfortunately using this plugin while the level is switching is not supported. The way this plugin works is that it spawns an invisible actor with the Niagara particle system in your world, and uses the particle data generated by it to create a custom widget. This is not possible when the engine is switching levels, since there’s no valid world at the time. The old one gets destroyed and the new one gets loaded.
1 Like
UPDATED TO SUPPORT UE 5.1:
Hi!
I’ve updated the plugin to support the newly released UE 5.1! This update also comes with some bug fixes that will be included in other versions soon (They’re already on GitHub, but not in precompiled plugin and marketplace). I’ve already submitted the marketplace version, but it meantime you can get it from GitHub, or a version with precompiled binaries here:
Niagara UI Renderer v1.7:
Download 5.1:
1 Like
Crash when trying to Add to Viewport widget with NiagaraSystemWidget placed on it.
Interestingly, it work for the main menu of the game, but the crash occurs due to the HUD during the game.
-
In Level blueprint of the Main Menu level, I Cast to Game Instance and trigger its Custom Event which is Create Menu Widget, Add it to viewport, also Create HUD Widget.
And it works. -
However, when I click the button to open the first normal level of the game, the Construction Script of my main character Cast to Game Instance and launches a Custom Event similar to the menu, which here is only Add to Viewport of an already created HUD Widget.
Now the program crashes. Node Is Valid doesn’t seem to help.
But, If I add a Delay for a second before this Add to Viewport, then the crash doesn’t occur!
Without Niagara there is no error and everything works. Sometimes only when I make some changes the HUD stops working and I have to restart the whole program, probably to reset Game Instance.
Here is crash log;
> LoginId:7d8bc63d484c2936f54b9db9670b10a4
> EpicAccountId:1fb6140f70ba41b09cca427c7009baa9
>
> Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x0000000000000250
>
> UE4Editor_NiagaraUIRenderer!AActor::ForEachComponent_Internal<UNiagaraUIComponent,0,0,<lambda_9caae4225cc5c417bc67b10a19a36ad4> >() [D:\RocketSync\4.27.0-17155196+++UE4+Release-4.27\Working\Engine\Source\Runtime\Engine\Classes\GameFramework\Actor.h:3006]
> UE4Editor_NiagaraUIRenderer!ANiagaraUIActor::SpawnNewNiagaraUIComponent() [D:\build\++Portal\Sync\LocalBuilds\PluginTemp\HostProject\Plugins\NiagaraUIRenderer\Source\NiagaraUIRenderer\Private\NiagaraUIActor.cpp:20]
> UE4Editor_NiagaraUIRenderer!UNiagaraSystemWidget::InitializeNiagaraUI() [D:\build\++Portal\Sync\LocalBuilds\PluginTemp\HostProject\Plugins\NiagaraUIRenderer\Source\NiagaraUIRenderer\Private\NiagaraSystemWidget.cpp:86]
> UE4Editor_NiagaraUIRenderer!UNiagaraSystemWidget::RebuildWidget() [D:\build\++Portal\Sync\LocalBuilds\PluginTemp\HostProject\Plugins\NiagaraUIRenderer\Source\NiagaraUIRenderer\Private\NiagaraSystemWidget.cpp:20]
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_UMG
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_CoreUObject
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_Engine
> UE4Editor_UnrealEd
> UE4Editor_UnrealEd
> UE4Editor
> UE4Editor
> UE4Editor
> UE4Editor
> UE4Editor
> UE4Editor
> kernel32
> ntdll