koobas.hobune.stream
Why am I getting terrible performance on devices with > 120 game objects?
This is only my third day learning Unity, so please bear with me if this is a really silly question, but why am I getting such terrible performance on my very simple game? Here's a screenshot: 
My game is a simple coin pusher game, the "push bar," aka the raised bit in the center channel, will periodically move back and forth, and if a coin is pushed off the edge, then it is destroyed, and the player's score and available coins goes up. I'm not doing anything fancy, as you can see, there are about 100 "coins" currently on the screen, but even this number starts to bog down the game on android devices. At ~120 coins, the game is completely unplayable. I don't quite understand why my performance is so bad.
Each coin is a cylinder with a mesh collider. Using the standard capsule collider is not an option because of how thin each coin is. If the height is less than the radius, the collision box just becomes a sphere, which makes them stack very strangely. As such, each coin is ~80 verts and tris. I do have shadows turned off for all dynamic objects, and the update for everything but the touchManager is empty. The touchManager checks for a touch or a mouse click, and if and only if there is one, continue with more logic. Even when not touching the screen, the game is very slow, so I don't think that that is the problem. In fact, the slowdown only really happens with the pushbar approaches the coins, which made me think there was something wrong with the coins.
However, the coins don't even have a script associated with them, so it can't be performance from the script causing this bog down. I handle collisions in the "floor" object (doesn't have a mesh renderer, so you can't see it, but it's about 10 units below the visible screen), so that shouldn't be causing issues unless there are coins near it.
The only thing I can think of is that this number of rigidbodies is somehow causing terrible performance, but 120 doesn't even seem like that many... Can anyone help me out?
Each coin is a cylinder with a mesh collider.
Why a $$anonymous$$esh collider?, and not a cylinder collider.. $$anonymous$$esh colliders are way more expensive than cylinder colliders.
Unless I'm completely blind, there's no such thing as a cylinder collider, they just map a capsule onto a cylinder. Which is passable if your cylinder is taller than it is wide, like a barrel, but as I mention, my coins are very thin compared to their radius (scale: 1, 0.05, 1).
@$$anonymous$$pjComp - this is nonsense. There is no cylinder collider. And here's why: http://forum.unity3d.com/threads/why-cylinder-collider-doesnt-exist.63967/#post-408699
Yes, my mistake.. I was thinking capsule. There is a Wheel collider the help says it can be used for other things other than wheels, so hopefully will work with coins. If not another idea is to use multiple colliders.. The cheapest colliders in 3d are sphere colliders so you could maybe place a few of them around the coin, and maybe some flattened box colliders in the middle. Should give you better performance than a mesh collider. You could still even use a $$anonymous$$esh collider, but you will want to simplify it first.
@tanoshimi, thanks for pointing out my nonsense that I pointed out about 6 $$anonymous$$utes before you pointed this out. :)
120 rigidbodies with mesh colliders (the most expensive collision type) is a lot, especially on a mobile device. 120 objects x 80 verts, checking for collisions against 119 other objects x 80 verts, every frame, is a lot of calculations...
Assuming you don't have Unity Pro (and therefore can't use the profiler) we can only speculate, but your main thread is taking up a lot of time which is consistent with your slowdown being caused by physics calculations.
You might want to rethink your design - given that your objects are very specific, consistent shape, you could write your own physics/collision handling functions tailored to dealing with collisions between thin cylindrical objects.
The only other thing I can suggest you look at is the VSync count in your Editor Quality settings - is it set to Don't Sync?
I don't know exactly how Unity handles collision detection (quad trees, surely?), but when I changed it back to capsule, it still generated the same number of tris and verts, according to the stats tab of the game player.
I'm genuinely curious, if 120 is considered a lot, how is collision detection normally handled in mobile games? Surely not everyone writes their own physics engine. There are plenty of games like the one I'm making, and none of the ones I've seen have any noticeable slowdown, even with a comparable number of objects. I could see for a bullet hell type game just individual checks of bullets vs destroyable objects (that is, there is no need to check for collision between bullets), but I would think that the built in physics engine would be good enough to not check every object against every other object. Isn't that the whole point of things like quad trees?
Changing collider types to capsule won't affect tris/verts in the stats window - that's the count of how many are being rendered by the GPU - totally unrelated to physics calculations.
From personal experience, the only times I'd use mesh colliders are on characters or terrain. For "objects" - buildings, items etc. you'd use a combination of box or sphere colliders. For bullets, you'd use raycasting not continuous collision detection.
I've never played nor designed a game similar to what you're proposing, so there may be some standard tricks to which I'm unaware (perhaps disabling physics on all objects not near the edge and combining them into a single mesh that you move kinematically? Then reactivate the rigidbody when close to the edge) but I think the problem is that your game is not as "simple" as you thought it was...
"good enough to not check every object against every other object" Looking at your coin game it looks like all the coins are touching each other, in that case there is very little it can do to optimise, as one coin at one end can have a physical effect on a coin at the other end (chain reaction). Like I pointed out most games will do what I just said, use either multiple simple colliders, or a more simplified mesh.
I see. That would make sense why the tri/verts didn't change then, I'm still using the same mesh render :P.
Sure would be helpful to have a greater insight into how collision detection actually works... For bullets in FPS style games, I could see raycasting, but surely [touhou style "bullet hells" don't use raycasting (unless I misunderstand raycasting).
I just tried a combination of a wheel collider (which appears to check collisions around the rounded edge) plus a cube collider, even just the cube collider, and I got the same slowdown at around the same time (maybe up to 130-140 objects, but same order of magnitude). Is that level of slowdown normal, even with cube colliders?
@kpjcomp $$anonymous$$y background is not in game design, though I think know enough about quad trees to know that it shouldn't be checking every coin against every coin, though I don't know how far down Unity divides it's quad trees. For example, the coins that are being pushed directly by the pusher should not be checked against the ones about to fall (in theory, anyway). Yes, some coins will touch some coins, but not all coins are touching each other, and some are far enough away that one check should be sufficient, not checking every vertex of coin A against every vertex of coin B.
