Niagara Shader Module Delegate Never Set

Development Asset Creation FX
, , , ,
1

After packaging my game which uses various Niagara emitters and Systems as well as forming these systems in C++ to be used in Blueprint, my game crashes with this error log:

Assertion failed: OnRequestDefaultDataInterface.IsBound() [File:D:/Build/++UE4+Licensee/Sync/Engine/Plugins/FX/Niagara/Source/NiagaraShader/Private/NiagaraShaderModule.cpp] [Line: 55]
Can not invoke OnRequestDefaultDataInterface. Delegate was never set.

My game works perfectly fine in the editor as well as all of the niagara visual effects. I recently upgraded from 4.23 to 4.25 Preview. Any help would be much appreciated!

2

I’m also getting this crash when booting up my packaged game.

The timing of the crash is when I search for my Niagara Systems using the following code at the timing of my GameInstance’s Init().

ConstructorHelpers::FObjectFinder<UNiagaraSystem> effectFinder(*effectPathString);

After doing some testing, I determined that this only occurs for GPU effects.
This crash actually began occurring after I changed some of my CPU effects into GPU effects to improve performance.
Reverting them back to CPU effects stopped the crash from occurring.

The relevant parameters are Emitter Properties → Sim Target ( CPUSim → GPUCompute Sim) and Emitter Properties → Fixed Bounds ( false → true ). Either or both of these parameters seems to be the cause of this crash.

I’m hoping that the 4.25.1 hotfix fixes this…

3

Thank you so much for posting this. This was exactly the issue. The warning message that they had should have been an error message that wouldn’t allow compiling if GPU needs fixed bounds to be set. Very strange that this was happening at all.

4

I am on 4.25.1 and this crash is still happening to me. I checked all the Niagara systems i have in the project, and those set to GPU sim all have ‘Fixed bounds’ set to true. Setting it to Off results in error message saying i should turn that On.

5

No, i haven’t tried that. Those particle systems would run very poorly on CPU, lots of particles. But i can do that just for testing sake. It will take ~90min, i will report it here.

6

I can confirm that after settings all the emitters to CPU, cooked project doesn’t crash. It is not a good solution, but it works for the moment.

7

Have you tried setting the GPU sims to CPU sims altogether? I had to do this to get it working. This probably needs a bug report to EPIC since GPU sims should be allowed I would think.

8

I checked again on the new 4.25.2 hotfix, but it still doesn’t appear to be fixed. Getting the same critical error on load “Can not invoke OnRequestDefaultDataInterface. Delegate was never set.”

I hope that Epic is aware of this issue?

9

I submitted a bug report a long time ago and never got a response back. Maybe if more people submit their own or find one that exists for it and upvote it? I’m not sure why they never gave me a ticket for it.

10

I am on 4.25.4 and I am also having this crash with packaged builds.

I set all systems to CPU and “fixed bounds” but I was never able to prevent the crash. Identical error every time I built the game.

I’ve ended up removing all Niagara systems for now. Once I’m able to migrate to 4.26 hopefully this has been fixed in that build?

11

I’ve just tested it on 4.26, and no improvement. What i find most baffling, is that when migrate all my Niagara systems to fresh project, everything works just fine. No clue how to replicate this error, so my hopes of reporting it and getting fixed are pretty low.

12

Well, that’s depressing. I liked what I saw in the editor, but if I can’t actually run a packaged build then what’s the point?

If anyone who works on the engine sees this thread, please chime in that you’re aware of this issue…

13

Facing the same issue. We are just months away from shipping the game and now can’t change the the particle simulation from gpu to cpu as cpu is occupied with other things.

Can’t imagine having to change the game’s architecture just to work around a bug found so late!

Too bad that you didn’t get a ticket and it not getting fixed even on 4.26

14

Problem with getting ticket to get this fixed, is that this crash is hard to reproduce. Few months back, i migrated few of my emitters to fresh project and after packaging, it crashed.
I tried that few days back, when 4.26 was released, with Niagara systems migrated to fresh project caused no problem, but my main project crashes (which i cannot submit to bug fixing).
Maybe you could try that, perhaps you’ll have ‘better luck’ and you’ll end up with simple project with bug that is easily reproduced.
(this suggestion is for anyone having this issue. We need clean, simple project with one, perhaps two Niagara system that reliably crashes, so it can be submitted to epic)

15

Hi guys! Have the same issue on 4.26.1. I’ve got the pack with VFX and cannot use it properly.
Thought about init time, maybe BP with Niagara system ref try to init before the plugin’s delegate was setted?!
Any suggestions/advices/directions how to fix it would be appreciated!

16

Besides setting all your emitters to CPU emitters, it doesn’t look like there’s much we can do, and it’s not clear if Epic is working to fix this. The only options I can think of are:

  1. Find a way to reproduce the problem starting with an empty project and send the necessary info to Epic
    or
  2. Debug the engine code, find the source of the problem yourself, and push a fix
17

Just chiming in that we are also encountering this issue with some Marketplace Niagara packs in a fairly fresh project in UE4.26.1. Switching from gpu to cpu emitters fixed our packaged build. If anyone from Epic cares to investigate we can probably package the project up and send it over for confidential investigation.

18

Problems still exist on 4.26.2. Any info on the bug ticket?

19

Hey, if you have a solid repro case for this problem you can send the project/asset to michael.galetzka@epicgames.com and I’ll take a look.

20

This is apparently due to one or more of your Niagara assets loading before the Niagara Module loads. You might have an asset that is referencing an actor or class that has a Niagara component that is loaded at startup. If that’s the case it can cause this issue.

To see what’s causing it, run your game standalone (i.e. “Development” not “Development Editor” from visual studio) and check out the stack when it crashes at startup. In our case it was due to a TSubclassOf<> class pointer in a data asset that we load at startup that ultimately was including a Niagara system. We replaced it with a TSoftClassPtr<> instead so that it doesn’t actually load the class into memory when the data asset is loaded, preventing the issue. Everything works fine for our builds now.