Stuttering - Performance issues

Hello

I've almost finished my test project, but I got this performance problem which bugs the hell out of me and makes the game almost unplayable. I've used the Profiler to try identify the problem, and got this result:


I'm fairly new to Unity, so I'm far from knowing all about it yet, hence I write here

As you can see I drop below 30 fps, and below the graphs it's telling me that it's the Update.ScriptRunBehaviourUpdate that probably causes this.

My Setup(If necessary):

GPU = Nvidia 980 Ti

CPU = I7 4280K - 3.7GHz

RAM = 16GB

My computer should be strong enough to handle this without problems in my head, but apparently it isn't, so I'm lost. I hope someone will help me understand this problem, and learn me how to solve it.

Furthermore, if it would help solve the issue and understand it, I have a link here for the whole project(.zip file - 160MB ):

https://www.dropbox.com/s/plxhvxj81men7mv/Roller Madness.zip?dl=0

 

Looks like too many Instantiate () calls I think. Maybe try pooling whatever is being spawned so much?

 

Thanks for the answer!

Oh wow, I see that now. The script SpawnGameObjects seems to be the problem?
I actually don't know what's getting spawned at that exact moment, and I don't know yet what pooling spawns is?

 

It looks like the baking of physics collision data is what is really causing it. A few things can cause this (rather than look at that code ill just give some pointers).

1. Unity has issues with scaling things up larger, spawn something with a larger scale it doesn't enjoy it. Try to get your models imported at proper size if possible.
2. Mesh colliders eat resources when moving, which is why you see most people using capsule colliders.
3. Are you using navmesh? New navmesh agents propgating can cause some bumps, and there are issues with a lot of nav agents using the mesh at the same time with performance in unity (make sure if you wanna use navmesh that your out of view stuff sleeps).
4. Another issue with navmesh, if you didn't set things up right, pls read the documentation, you can have some head banging between your agent and your animations causing thrashing (though I don't believe that is the problem here, just throwing this in there).

Now all that said, again if you look the issue is the physics collision data. You are spawning game objects, that collision data has to be updated, which is why it climbs upwards to your spawning script. So I would focus on making sure your scaling is right. Check your colliders on everything. Use capsules and boxes where possible they calculate faster, I have never needed to use mesh colliders (unless you want to count navmesh which is different), the only reason I could think of for using one is if maybe you wanted to have some soft ground that gave to your footprints when you walked, but if you want that kind of realism you will pay the cost in performance (or start hooking into gpu processes like a pro ). Generally speaking avoid mesh colliders at all costs, you can use 50 box colliders and position them around something complex for 10% if not less what 1 mesh collider would cost you. Boxes and Capsules are your friend!

 

Now im gonna download this and look, i bet im on point, scaled mesh physics collision data, you are scaling something up with a mesh collider, lemme see if I am right

 

I think you're on point
I'm using Mesh Colliders for my coins(If you are downloading it), so that could be one of the issues.
I probably have scaled some of the GameObjects, I'm quite sure.

But is it really true that these two things can make things that bad for such a small game?

And thank you for this great and thorough comment

 

Now I've tried to remove the Mesh Collider on my Bouncy Coins, and it worked!
But sadly it's not enough, there's still some stuttering when I play for longer than 30 seconds. I don't know if that could have something to do with the Bouncy Coins is scaled to 0.4 times the original size?

 

yep i just did that after finally finding that one little bugger, not a bit of spikes now on my profiler. All i did was removed the mesh renderer from the coin and bam.
https://imgur.com/a/D2kMS

Note scaling down usually isn't an issue, scaling up tends to make trouble.

I noticed in my profiler that the vsync was causing spikes just waiting for target fps ><

 

There is *always* stuttering in the Unity editor because it is generating garbage whenever you move the mouse and redrawing all it's ui elements as you do so. In addition the profiler and everything else also causes stuttering.

So you can't use that as measurement. Only the profiler Always rely on ms and remove any GC alloc. Use primitive colliders where possible.

Sort by time ms for script performance, and sort by gc for allocation optimisation.

 

Yep, look at my album link after the first optimization the other 2 profiler images show the profiler eating 2x as much as the game.

Those 2 mesh colliders were hammering though.

 

AFAIK the colliders are regenerated each time the scale changes, so those coins must be pretty high poly. 12 physics primitives being scaled should have close to zero impact.

It's probably worth filing a bug for the performance issue on Physx if @yant thinks it's neccesary for the 44ms thing. Does still seem high.

 

Its more of they are spawning every couple of seconds so those mesh renderers had to be rebaked everytime since its just the rollerball tutorial stuff its not optimized at all, no spawn pooling or anything. It really wasn't bad performance but he was targeting webgl so you gotta squeeze everything out. I mean yeah it showed 94% on that mesh calc but it was still like nothing desktop wise lol.

on a side note, if you wanna be evil, go in and change the chase script, remove the Time.deltatime from the transform and laugh while players get instakilled

I say that cause it is funny but also to encourage you to look into other options on things like that as well, you can use smoothDamp and things like that to give a more realistic chase, in a game like rollerball it encourages players to really consider their movement, since the chasers will never overshoot, but follow at a nice smooth gaining on ya pace. I never really liked Time.deltatime because it relies on last frame differential, theres no control, you stutter it stutters, kinda lame.

 

I know that. My comment is with that in mind.

 

I know you do Was elaborating more for his benefit

 

Prompted a worthwhile investigation sir. Working as intended I believe....Mesh Collider is a known beast that should be avoided, but in the case of a coin yeah so I looked.... 744 faces. Thatll do it.

 

Oh, man guys. So much great information!
I had never believed that I would get this response out of my Post

That mesh collider was really "The one". But the build has also a lot to say or how does that work?

Will it be beneficial to turn V-sync off?

I also said that I had stuttering still after about 30 seconds, but hippocoder you're saying that it probably will go away when I make the build?

Again, Thank you so much for the answers!

 

the vsync thing will stop cpu processing spikes for "wait for target fps" its not huge but itll make the profiler look nice. I should also make you aware however, moreso on mobile and webgl builds than anything else, vsync will help keep from having screen tearing and strange screen edge artifacts while playing. The tradeoff is maybe a small 10-20ms spike every second or so, not sure it is worth it to be honest, but I like playing with things. Thats how you see what does work and what doesn't. You have that profiler up, that will cause some stuttering, plus you are running unity editor in the same thread so theres some more hiccups. A build should certainly smooth it out, give it a try, shouldnt take but a minute.

Thats the best thing about Unity, large helpful community, welcoming to new programmers. You won't find that on ANY other engine, and yes I tinker with a lot of them (Unreal, Jmonkey, Game-Guru). Unity can be powerful, takes a bit more work out of the box than Unreal looks when you first open it, but you have support, assets, imo it is not only a great place for AAA companies to make games, it is the perfect place for a new developer to get started.

 

Okay, I think I'll keep the V-Sync on then
I made a build and it ran waaay better than before! The Game/Prototype is actually playable now.

Yeah, this is definitely much better answers on this post than I ever expected.
And when you're on my level, it probably also makes the most sense to use the Engine with the better community, so you build a good foundation

 

One little thing that made a big impact on my android builds, simple, often overlooked,

Application.targetFrameRate = 60;
put it in the awake or start of your game script.

and use a spawn pool : Free!!

good luck
p-

 

Oh okay, I will try to take a look at the targetFrameRate

You're mentioning Spawn pool. I haven't learned what that's yet, can you explain?

 

A pool is what you call it when you keep a "long term" collection of something, either gameobjects, script instances, variables... something that there will be a lot of, that might get reused many times. Think of things like bullets, or enemies (who respawn somewhere else after dying) or even vehicles (think city games where cars dissapear far away and spawn coming towards the player).

What the idea is, that instead of "creating" these objects/variables every single time they are needed (every time they are "spawned" or go to be used) that you instead "take from the pool" of already spawned/initialized objects, and this is to improve performance.

A simple example might be to have "Bullet0, Bullet1, ..." and up to say, 10 bullets. Then when the player pulls out the rocket launcher, and goes to fire a rocket, instead of Instantiating that rocket prefab object every single time, instead 10 were already instantiated and "pooled" (which basically means disabled and hidden from view), and one of those ten are selected (the first that isn't already in use) and is moved into position (in front of the rocket launcher) and then enabled (has its renderer turned on, scripts triggered to start flying away).

Hope that helps explain object pooling a bit, but there are far better info's online with a quick google search I'm sure

 

Ah okay, that was actually a good description. Thank you very much!
Then I guess I'll need to make a script, which will move one of the unused pooled objects and make it visible?

 

Just FYI, for the "scaling mesh colliders = heavy" thing, Unity 2017.3 introduces new options for convex mesh colliders that can immensely speed up the baking of the collider geometry (basically you'll be removing safety checks and it'll be 10x faster, supposedly)

But yeah, it's still much better to pool them anyway.

 

I just took a look. Those options are awesome. I would like docs.