Particle System Jobs/Performance

I'm working on a voxel game where I am trying to spend some time optimizing the code to get better frame rates in worlds that are heavily built up.

After reading a bunch about the particle systems, such as about procedural mode, and how it can have an effect on whether a particle system can be switched off when culled or whatever, I spent the better chunk of a day going through all the blocks and making sure all the particle systems associated with our blocks are set to pause simulation for the cull mode and have all the conditions that prevent "procedural simulation is not supported" info icon on the particle system.

As best I can tell, these are the things that can prevent the particle system from being able to zero out the cost when it's culled.

After all that, I was disappointed to find that the CPU and job cost did not drop as dramatically as I had hoped.

On a hunch I tried to fly up to the top of the world and look straight up, where nothing but the skybox is visible. Frame debugger shows nothing related to particle systems rendering, so culling is apparently working, but as I look at the profiler, I'm still seeing an vastly unexpected number of particle system jobs running even in this situation where virtually everything should be paused and doing nothing.

This makes me think there is some incomplete documentation as to the particle systems and their conditions for turning off properly, or a bug, or something.

A utility function I wrote to dump out some basic stats about the game objects in the scene
There are 4562 active particle systems. 4317 playing systems
There are 0 particle systems in cull mode. Automatic
There are 1417 particle systems in cull mode. PauseAndCatchup
There are 3137 particle systems in cull mode. Pause
There are 8 particle systems in cull mode. AlwaysSimulate

I would expect the number of particle systems "running" at this moment to be single digits, as everything else should be put paused and presumably not have jobs running for it.

What am I missing? Anyone have any insight to this issue?

 

Hi @richardkettlewell. Thanks for replying. I will file a bug.

Could it be that the use of LOD groups on these objects could defeat the internal particle simulation disabling? That's the next thing I may try to rule out.

 

This is a cloud hosted online world(https://www.creativersegame.com/), so getting you a standalone test scene may be tricky, but I'll see what I can do.

 

Yea, is there any other alternative @richardkettlewell ? It would probably take several days to get a test scene to you. Would a profile enabled windows build provide you the information you want? (then you can connect to a cloud world as a player would) Or do you absolutely need the code?

This is a pretty large complex online game where dissecting a standalone client with a representative chunk of the world loaded would be a pretty huge undertaking.

 

Definitely seems to be a bug with cull + pause particles. If I add a menu command to call pause manually on all the particle systems in the scene, the particle system drops to nothing in the profiler, so they aren't getting paused internally.

 

Question about the procedural culling indicator(show below from screenshot in docs)

In the docs https://blogs.unity3d.com/2016/12/20/unitytips-particlesystem-performance-culling/

It mentions that "If a value is changed via script or in the editor during play mode then those assumptions can’t be made and procedural mode is invalidated"

Is the popup indicator(shown below) supposed to show up at runtime if procedural mode is deactivated due to a runtime manipulation of the whatever changed value might have tripped the procedural mode check?

Is there some other way to determine what specific systems are still executing?



I'm trying to build up a skeleton test case.

 

@richardkettlewell I have filed a bug

(Case 1223508) Culled particles do not pause with cullmode pause

Interesting to note that I accidentally created the test project in 2019.2 and was unable to repro the issue, but when I move the logic back into 2018.3.12f1 it occurs in a simple test scene such as that provided.

 

2018.4.17f1 appears to have the issue fixed as well, though I don't know what version from 2018.3.12f1 to 2018.4.17f1 specifically fixed the issue. Nothing stood out in the changelogs about this issue in particular.

I suppose that means the fix is for us to update unity to the latest 2018.4 LTS.

 

Sounds like exactly the issue, though that says Fixed in 2018.3, which isn't really the case.