Niagara mesh renderers affect each other in case CPU sim?

Hello.
I have simple Niagara system:

One emitter shows sphere: 1 particle for 20 second. Another shows circles on ground: 5 times shows 1 particle. Both particles are meshes.
Material for sphere is set from C++ code. It is dynamic material. In case shield is hit by projectile, C++ code starts timelines, which change progress of propagation of “hit impact wave” (pink circle).
Untitled

Hit impact propagation is implemented in material. I calculate mask on sphere and use the same mask to offset faces and to color them (the more offset, the more pink color).
Everything works fine if I have only the 1st emitter. As soon as I enable the 2nd one for drawing circles on ground, I have this:

As you can see, pink area goes in front of offsetted faces. In my understanding it is literally impossible, because, as I said previously, the same mask is used for both: offsetting and coloring of hit impact faces :slight_smile: Position of mask on sphere is specified by one single parameter, which is provided by timeline from C++ code. I can provide part of my material, if it makes sense. Also, how is it possible, that adding new emitter (which has nothing to do with this material - it renders another mesh with another material) affects material of the first one?
I noticed that after some time issue disappears and even in case of 2 emitters hit impact becomes correct. It happens approximately after 2nd emitter life time is over + some delay about 5 sec.
I checked amount of displayed particles by Niagara Debugger. Issue is reproduced when there are 2 particles (sphere + circle) and about 5 seconds after there is 1 particle (sphere). After these 5 seconds particle count is still 1, but issue disappears.
I found workaround. If I select GPU simulation for both emitters, instead of CPU sim, issue is not reproduced anymore. But I have no idea why.
Can anyone explain, what is going on? :slight_smile: May be I’m doing something completely weird and what I want to reach is normally done in another way, which engine handles without such issues?
Thank you in advance!

I’ve just reproduced this issue inside Niagara editor.
To make sure that circle mesh and circle material are not causing this issue, I choose mesh and material from engine. I just slightly move position in timeline and this issue appears.


I also made material opaque, one-sided, disabled reflections, opacity, offset, base color (I left only emissive color) - issue is still reproducible: enabling 2nd emitter changes colors on the 1st mesh.

UPD: I found that “Object Position (Absolute)” node of my sphere material is changing from (0, 0, 0) to the “Position Offset” value set in Niagara emitter for circle emitter. I underline, “Position Offset” set in one emitter and affects “Object Position” of material in another emitter.
It happens not instantly, but during some time. It happens only in case CPU simulation and only in case both emitters are enabled.

I found the reason of this weird behavior.
Inside of my material I was using node called “Object Position (Absolute)”. Which, to be honest, has nothing to do with object position. It contains position of center of bounding box around all meshes of current VFX (refer to Coordinates Material Expressions in Unreal Engine | Unreal Engine 5.3 Documentation section “ObjectPositionWS”). So, if there is only 1 emitter, then yes, center of bounding box is center of sphere and everything works fine. But in case 2nd emitter is enabled, it creates 2nd mesh, which changes bounding box around meshes and thus “Object Position (Absolute)” starts giving position, which is not center of sphere anymore.
The node I should use is called “Actor position”. It always contains center of sphere, as I need.
To be hones, Epic could give better and less confusing names to these nodes. Intuitively I expected that “actor” is something, which has sub-objects (components, etc.). So “object” is one of this sub-objects (rendered mesh).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.