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 ):
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).
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.
Mesh colliders eat resources when moving, which is why you see most people using capsule colliders.
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).
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 :p). 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?
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.
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.
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.
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.
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
