Hi,
I’m developing a space sim using large worlds.
In this sim, ships can launch missiles, which leave trails.
The trails are particle emitters which emit smoke sprites.
The missiles can travel for several hundreds of km (in 1:1 scale), leaving such smoke trail.
Up until 5.0.3, the smoke trail had absolutely no issue, and behaved exactly like anyone can expect a smoke trail to behave.
However, since 5.1, when I launch a missile, after a few seconds ALL Niagara particle systems start resetting every few seconds.
I get a series of error messages, one per particle system:
NiagaraSystem /Game/…path…/P_Ribbon_Trail_Blue_1.P_Ribbon_Trail_Blue_1) required LWC tile recache and was reset
Curiously, there is no error message for the smoke trail, just a series of identical error messages like above, for ALL other Niagara systems present in the level.
Therefore, the effect of smoke trail which has been working since 4.26, is now broken.
What is the meaning of this error?
It seems that it has to do with the Large World Coordinate cells, which provoke a general Niagara particle systems reset.
But why now in 5.1, while it was working flawlessly in 5.0.3 with identical settings?
How can this be fixed?
Hi, no I believe there is no solution and it looks like an engine limitation which was introduced with 5.1.
This issue behaves identically as in UE4 when re-basing the world.
I have submitted a bug tracker ticket. We’ll see if it gets fixed.
Hi Cultrarius,
Thanks for your very good input!
The trail is using WorldSpace. When I tick LocalSpace, the trails are not visible anymore, I wonder if/where they get rendered.
However, when I disable the LWC support… the trails do not reset anymore!
Problem solved? I wonder what is going on under the hood.
I also found out a very weird detail: the “LWC Support” is not displayed anymore in the Niagara panel:
Problem solved?
Might switching off LWC support cause larger issues?
From a short testing, everything now seems to work.
So the bottom line is: in order to make Niagara work with LWC we need to… choose the option NOT to support LWC?
I will update again if there are further issues generated by this workaround
Thanks!
I tested on a Large World map and yes, there are game-breaking issues
Without the LWC support, the Niagara system ends up making a mess at a certain distance from the origin (0,0,0).
I imagine it’s because, without LWC support, the Niagara system uses Floats and does not use the “cell” system, resulting in loss of accuracy.
The result looks like a total mess and it can be an interesting exercise to try, if someone is interested in this kind of effects
I understand from this attempt, that LWC Support is absolutely required for Niagara systems using LWC.
However, the original issue still stands and the solution is still NOT found for the continuous re-setting of all Niagara systems, due to the LWC re-cache.
Still looks like a very bad engine limitation introduced by 5.1.
The fundamental problem is that without resetting the system, you’re always going to get render artefacts with world space systems. The warning is just a hint that you should reset the system yourself of find a way to display the effect without moving the system over such large distances. This is a limitation of using floating point precision inside Niagara and won’t go away soon.
You can disable the resetting behavior by changing the cvar “fx.LWCTileRecache” to 0, but once the system moves a large distance you will get the same rendering artefacts that you get when disabling LWC and then moving it away from 0,0,0 (usually things start to break down in the 100-1000km range).
Hi Michael,
thanks for the input, that’s the result I was looking for!
I inserted “fx.LWCTileRecache 0” and the re-cache behavior ceased.
I quickly tested, and the behavior seems to be back to how it was before 5.1.
However, two points:
This effects doesn’t seem to be just a warning, the reset behavior happens automatically at the same time of the warning. It happens to all Niagara systems at the same time, regardless of where they are located and/or for which length they stretch
I’m currently at these coordinates, flying at the speed of 10km/s (space sim ):
I don’t see major breakdowns or issues with Niagara systems due to LWC.
When I previously unticked the behavior “LWC support” in Niagara, all Niagara systems became a total mess, and the issue with floating point precision was obvious.
However, in this moment it seems to be running fine.
The only issue I see is that the ribbons make some small “spike” every now and then.
I also see some “stuttering” in the smoke trails of my missiles, with the sprites teleporting instead of drifting smoothly. However it seems to be due to TSR AA: the stuttering goes away if I switch to FXAA.
All in all, I would love to see Niagara systems switch to double precision, and TSR to become more stable at high speeds and large distances
It shouldn’t reset all the systems, only the ones that travelled too far from their starting point. But if you’re travelling that fast then that includes basically all the systems at the same time.
The stuttering you see when moving too far is one of the problems you get when float precision is not enough to accurately display the particle position in the renderer. My recommendation to you would be to disable the tile recaching and then author all systems that travel with the ship as localspace systems. Localspace positions don’t suffer from the precision problems that worldspace positions do.
I don’t see Niagara switching to doubles any time soon, because it’s not supported by all gpu manufacturers. Even when they do have double support, it’s super slow compared to floats.
Interesting, I didn’t know that the limitation was actually hardware-related.
I will follow the advice, and try to work around the limitation
I understand then that by switching to FXAA, the “stuttering” problem disappears, because also TAA/TSR rely on float precision?
That would also explain another issue I see here, where my ship’s mesh gets “fuzzy” every few seconds: Very strong "fuzziness" artefact with TSR
The rendering pipeline uses float precision relative to the camera position, so that shouldn’t be a problem in your case. But they do rely heavily on accurate motion vectors and multi-frame sampling. Your objects are probably going too fast for the AA algorithm, I doubt anyone on the rendering team ever tested them with such fast moving objects.
Yes, I was imagining that the high speed is causing trouble.
The problem seems to appear at >100m/s, and definitely at >400m/s (40000uu/s).
Just now I cannot find an appropriate AA setting for a space sim
FXAA looks not good enough, TAA is super-jittery, TSR is beautiful but generates this fuzziness.
With UE I’m struggling to find a way to make the game look good, while I see that in other engines this might be possible, even for fast objects.
I will try with MSAA to see if I can find some compromise.
I would like to inject into this thread to Mac users. It’s that on 5.1 using MacOS, this same issue doesn’t generate error messages. It instead crashes the editor. You have to run in XCode debugger to see what is actually causing the problem but you could also find in the log down in Library the offending Niagara system. Disabling LWC stops the crash but doesn’t fix the issue and one could assume it’s the same solution as above. In our case interestingly, it showed up when a space vehicle went into warp, so speed was an issue. The emitter had no problems slowly moving around the large world (could not have seen any artifacts with the distances involved, i.e., not saying it’s good, just didn’t crash in shorter distances at slower speed). I felt I needed to mention this because it’s obscure when it happens and takes a bit to find out what caused it.
Thanks to those in this thread who exposed the situation.
Crashing is definitely a bug and should never happen - do you have a callstack or repro steps by chance?
If you have an asset you could send me that causes a crash when moving too fast that would be very helpful to fix the issue.
I would have to create a cutdown project with our flight pawns and their intelligence. The project is at 55G right now so I can’t send the real thing (woes of using satellite). I don’t want to miss the opportunity to help in that respect. I will see what I can do but it could take some time.
Thanks very much for the interest!
Edit: Would the crash as shown in XCodes debugger provide what you need? I can get that pretty quick.
Here is a screen shot of the crash in XCode Debugger. I achieved this by turning on Large World Coordinates in the emitter. Let me know what else I could do to provide help.
This, thank you! at first, fixed bound worked, but at large distances niagara system reset as OP mentioned and unticking LCW fixed the issue. Working in 5.3.
