Hi, I suspect that the cause of your problem is creating the widget in construction script. In general it’s not a good practice to create widgets from construction script, but you should do it on Begin Play. The construction script is called before the whole world is fully initialized and since my widget is spawning a niagara particle system into the world, I assume that’s what’s causing the crash. I’ll have to look into it to be sure, and if it’s the case I’ll implement a check for it into the next update. In the meantime please try moving your widget construction logic into begin play and let me know if that solved it. Cheers!
I compiled a version for Mac (Rosetta) on Mac M1 with Xcode 13.4.1 with macOS 12.2.1.
Tested and renders on both Mac and iOS.
1 Like
UPDATED TO SUPPORT UE 5.2:
Hi!
I’ve updated the plugin to support the newly released UE 5.2! This update also includes bug fixes and other improvements. It will take a few days for Epic to process the update on Unreal Marketplace, but in the meantime you can download it from GitHub. Cheers!
Niagara UI Renderer v1.1.7:
Download 5.2:
1 Like
So I am having some trouble regarding bounds of the particles, no matter how I try to set bounds, the particle is hidden entirely whenever the pivot point is hidden, it’s like bounds are not being recognized 
Do you know a workaround or if it is some kind of bug?
Hi, sorry for the late response; I haven’t noticed your message earlier. I’ve tried to reproduce your issue, but I wasn’t exactly sure what you meant by your description, and no matter how I positioned the widget, everything worked fine on my end. Can you please provide more info about your issue? Either reproduction steps starting from an empty project or a sample project with the issue. Cheers!
I seem to be having an issue with this plugin.
I have my game’s software cursor set as a widget blueprint. The widget contains the cursor image as well as a simple particle emitter. It seems to work fine when first loading into the game. The issue occurs when I use OpenLevel to transition from one level to another. After loading into the new level the particle emitter on the cursor no longer functions. It’ll show my pointer image, but the niagara system no longer activates.
Hi, I don’t recommend using the Niagara System Widget inside of the software cursor, since it introduces several issues. Instead I recommend having the Niagara widget inside of another fullscreen widget - like your game HUD / menu, and update it’s position to follow the cursor; as shown in the tutorial: https://youtu.be/1O4fLjqosBg?si=0IgRMaP7TGJZwamB
You’re encountering the problem because the widget requires the particle system to be spawned and simulated in the game world. Because of this it can’t work in cases when the world doesn’t exist - like during level loading, and the particle system gets destroyed on level change. There are also other issues with the widget inside of the software cursor that are causing crashes on certain devices. For these reasons I recommend the other approach.
Cheers!
Hello, I’m trying to use it and find a problem about particles’ alignment. When I put a Niagara UI Widget as child into another parent panel, and a part of the child widget is outside of the panel. It seems that the child’s niagara emitter’s origin location is Clampped by parent panel, like the image below.
I’ve viewed the source code and find that when function SNiagaraUISystemWidget::OnPaint calls NiagaraUIComponent->RenderUI, it has transferred the clamped param ParentTopLeft. I’ve modified it to AllottedGeometry.GetAbsolutePositionAtCoordinates(FVector2D(0.f, 0.f)) and it looks fine.
Does that modification conflict with something you have concerned before (because I don’t know the reason to clamp the particles coord), and will it cause any other problems ?
Hi, I’ve tried to replicate your issue, but even with the same setup as on your image everything seems to be behaving correctly:
Can you please be more specific with with the reproduction steps (a step by step guide how to reproduce the issue from a blank project) or a sample project with the issue?
I don’t think your modification should cause any issues, but I want to be able to reproduce the issue first and verify everything works correctly. Cheers!
I’ve found the reason, that’s a series of misoperation. I’ll use the asset NS_Burst in your demo NiagaraUI.
In that system, the fire emitter did not use local space, did not spawn continuously, and particles will not disappear at end of lifetime. Then I’ve make the niagara widget clip to bounds.
That looks no different with local space unless part of the widget is out of its panel.
Scroll panel can replicate it more obviously.
After using local space, it works well and needn’t more modification. Thank you for your reply.
Hi, yes this behavior is by design. If the particle system is not using local space is spawns and keeps simulating in the world (screen) space. If you need it to be “attached” to the widget the emitters need to be simulated in local space. I’m glad you’ve figured it out. Cheers!
Hello, thank you for creating this plugin, it has been very useful for our current project!
We’ve been using it to render Niagara beams in UI, and I wanted to add some random UV/time offset to them so they’re not as repetitive. I saw earlier in this thread that there’s a way to pass data to the shader via texture coordinates for sprites, however this does not seem to work with ribbons/beams. Is there another workaround for beams?
Hi, for the ribbon renderer the plugin is passing the ribbon’s UV1 coordinates into the material, so there’s no additional custom data available. I might add an option in the future to override this behavior and force pass the custom data into the UV1 anyway, but right now it’s not possible without modifying the plugin. The next best things you can do (which might be enough depending on the use case) is to create a dynamic material instance per instance of your particle system, and apply it using the “Set Remap Material” function on the widget. This will allow you to use any of the built in material parameters to customize the look of your effect. The main disadvantage of this being that you cannot have different values per particle / ribbon.
Hi, it was actually really simple to implement, so I just did it. There is a new option now to pass dynamic material parameters from ribbon the same way sprites do, while replacing the ribbon generated UV1 coordinates. You can download the update right now from GitHub, and it will also be included in the future plugin updates. Thanks for the suggestion. Cheers!
Thank you so much for the fast response and update! I’m sorry to possibly make this more complicated for you, but will this fix work for UE 4.26?
I just thought about how do I make Ui particals…it’s very talent of you
You’re welcome. I’ve backported the change to the UE4 branch on GitHub, so you can download it and use it in UE4 too. Cheers!
1 Like
UPDATED TO UE 5.4:
Hi!
I’ve updated the plugin to support the newly released UE 5.4! This update includes a few bug fixes and other improvements. It usually takes a few days for Epic to process the update on Unreal Marketplace, so in the meantime you can download it from GitHub. Cheers!
Niagara UI Renderer v1.1.7:
Download 5.4:
Could be I am doing something wrong as aI have never used this before. I tried installing in 5.4 via project plugin (copied to my projects plugin folder). The plugin appears and is enabled in the plugin manager, but I do not see the widget or the right click option to convert materials.
Hi, copying the plugin into the plugins folder and enabling it should be enough to make it work. Can you please provide more details about your setup? What OS are you running on? Are you using C++ or Blueprint only project? Cheers!