Hi, guys. I’ve been working on a graphic for when enemies get spawned in my game. This involves a few particle systems, none of which are particularly cpu demanding. I’m using object pooling for the enemies, so I use play on awake to trigger the animation. The problem I’ve run into is that I notice a serious drop in framerate the first time any of the enemies are enabled. For some reason the particle systems are very demanding, just the first time they are played. Would appreciate it if someone could school me on why this is, and any potential workarounds. Thanks in advance.
Always best to add the tag “particles” to get the attention of particle devs who might be floating around here. 
I added that for you.
1 Like
Low hanging fruit suggestions first:
The initial creation of particles requires a memory alocation and I believe how much is reserved right away depends on the max particles setting. So make sure that’s not way higher than needed.
In every case Unity has a counter measure: “prewarm” which should alocate ahead of time. Have you activated that? (that won’t help unfortunately if you instantiate the object at runtime of course)
However you say “the first time the enemy is enabled”. Does that mean the enemy instance is created in the same frame so your pooling is efectively not doing anything yet? Further re-awakes however happen smoothly?
In that case you might want to “prewarm” that pool yourself during a loading screen etc.
1 Like
Instantiation incurs a cost but not as high as a first time use of a 3D asset (shader compile or resource upload), so my money is on the fact you’re using the particle system for the first time and perhaps resources are being put on the GPU.
You can have a scene to warm up GPU resources, it’s common to do that, assuming it’s the case.
Enemies are not particle systems. In any case I’m fairly sure that your problem is first-time warmup, and more complex games do require that warm up.
Profiler should show where the spike is.
1 Like
Good suggestions. My max count was indeed much higher than needed on the particle systems. I didn’t consider that it was actually allocating space for that. Lowering them unfortunately did not fix my issue, but it’s still good to know about.
I cannot prewarm unfortunately, because I need for the particles to not loop. I never really understood why prewarm was loop dependent, but there ya go.
To answer your questions, the enemies are pooled but disabled before the scene starts. I enable them as needed and cycle through. I enable them one after the other with about a 2 second delay in between to not overload the system. The first time they are enabled is when I see the frame skip. Enabling the enemies subsequent times has no frame skippage.
EDIT: I was able to figure out a way to use loop and prewarm while still getting the effect I wanted. Unfortunately, this didn’t seem to fix the issue. FPS still drops by about 100 for a brief moment the first time the particle system is enabled.
Do you enable ones with different materials and does it occur on every of those?
hippocoder could well be on the right track. There are some quirks like that unfortunately.
You could check this by instancing an enemy of every type (like so all materials are used) independently of your pool and instantly destroy them after the second frame (or just place them in the scene with a script that destroys them on that second frame).
If that solves it for all later creations in the pool, then it’s clearly the materials and not the particle systems themselves. Then there are of course smother ways to ensure the shaders are loaded.
Hmmm, ok. I’m not 100% sure I’m understanding everything you guys are talking about, but I think I’m getting there. Both the enemies and the particle system are copies of the same prefab, so it’s basically the same enemy and particle system over and over, so I don’t think that loading up and destroying one independent of the pooling would have an effect. Is that right?
So it sounds like my best bet is something you guys both brought up, which is to have a pre-warming load screen. I’m assuming that’s basically where you just have a UI overlay to hide the fact that you are enabling and disabling stuff off camera?
Well check the profiler first, it will show you a spike and you can use the hierarchical (text) display to sort by millisec. This will then put all the most expensive tasks at the top to see what takes up time.
1 Like
Thanks for all the advice, Hippocoder! I’m new to the profiler so it took me a bit to figure out what I was looking for, but if I’m reading it right, the module that keeps showing up at the top of the list on the spikes is EditorLoop. At the spikes it ranges from 70 - 95% of the total time taken.
I was able to find a forum here that discusses this issue and a fix that worked for me. No idea why it works, but it does. Copied and pasted below for convenience.
"For anyone else that will or might have this obscure problem in the future, here’s a solution that doesn’t make sense but it worked anyways:
- Go to Edit > Preferences
- In the general section, find “Interaction Mode” (should be at the way bottom)
- Set the value to “Monitor Refresh Rate” (mine was set at “No throttling”)
CPU was instantly freed up in the editor, and the issue does not occur anymore."
3 Likes
Now that’s a result - nice one!
2 Likes