I’m trying to optimize a physics in a physics heavy game I am creating. It involves demolishing buildings. So far, the only thing I found that would speed up the physics simulation on the iphone is setting time settings to this:
Fixed Timestep 0.06
Time Scale 0.75
I’ve found that setting the timestep any higher causes this “bouncy building” effect and the entire building just collapses on itself. Not leaving the timestep to .02 also makes it that higher buildings are not stable and the building collapses on itself due to bouncyness (it’s stable when it’s at .01/.02). Even if I mess with the physics thresholds (like the the bounce threshold) the building still bounces around and collapses when put on higher timesteps.
Messing with the physics settings doesn’t really change anything performance wise. Every object is a box collider.
Anybody have any ideas to make things faster or more stable during higher timesteps?
Also, how do you save the changed positions when you run the game in unity?
171255–6159–$physics_testunity_169.zip (16.6 KB)
There probably isn’t much you can do. Having that many objects is going to result in a lot of draw calls which is going to severely hurt performance. On top of that the iPhone CPU probably isn’t well suited to doing anything as physics heavy as you’re wanting to do.
The number of drawcalls required to run the simulation pictured may be more of a performance bottleneck than the actual physics. A quick test would be to disable the rendering and just observe the performance of the physics simulation. You could also look into leveraging sprites to reduce the number of drawcalls. In addition, you should check out this thread, http://forum.unity3d.com/viewtopic.php?t=23900&start=0, where PirateNinjaAlliance has an excellent suggestion for reducing the number of drawcalls for separate objects.
I’m guessing you stop rendering by deleting the camera, but how do I measure physics performance then?
Stop rendering by A) turning off the renderers, or B) point the camera somewhere else…
–Eric
With Unity iPhone 1.1 then, the drawcall part should be “self solving” in such a scenario.
Also there is an easy way to find out what is the bottleneck: use the profiler data
Thanks for the tips people. The profiler revealed that it was about half physics and half rendering/drawcalls
iPhone Unity internal profiler stats:
cpu-player> min: 28.9 max: 57.6 avg: 50.6
cpu-ogles-drv> min: 7.6 max: 12.0 avg: 9.2
cpu-present> min: 1.5 max: 2.8 avg: 1.7
frametime> min: 49.5 max: 116.8 avg: 68.9
draw-call #> min: 77 max: 79 avg: 78
tris #> min: 1180 max: 1204 avg: 1199
verts #> min: 2045 max: 2093 avg: 2083
player-detail> physx: 24.3 animation: 0.0 skinning: 0.0 render: 26.0 fixed-update-count: 0 … 1
mono-scripts> update: 0.0 fixedUpdate: 0.0 coroutines: 0.0
mono-memory> used heap: 98304 allocated heap: 131072
When I moved the camera off scene turned up the step time to .025 (more physics) I got this at the highest point:
iPhone Unity internal profiler stats:
cpu-player> min: 42.3 max: 130.6 avg: 64.8
cpu-ogles-drv> min: 0.2 max: 1.6 avg: 0.3
cpu-present> min: 1.2 max: 4.4 avg: 1.6
frametime> min: 59.8 max: 166.7 avg: 83.2
draw-call #> min: 1 max: 1 avg: 1
tris #> min: 200 max: 200 avg: 200
verts #> min: 121 max: 121 avg: 121
player-detail> physx: 60.6 animation: 0.0 skinning: 0.0 render: 2.0 fixed-update-count: 2 … 5
mono-scripts> update: 0.0 fixedUpdate: 0.1 coroutines: 0.1
mono-memory> used heap: 102400 allocated heap: 131072
I’m going to try that “combine into one mesh and boneify” optimization to reduce the drawcalls later on (although the fact that I shouldn’t be doing this is a bit annoying). Any other tips would be appreciated!
combine will not work with physics interaction against the object (only object against the rest)
Additionally you would require polygon collision to do any physics at all anymore, which is completely out of question if you deform the mesh all the time.
But you will have to work on the physics end anyway, because it is just as heavy as the rendering timewise.
You just have too many physically interacting objects.
He said he was going to combine and use bones, which will work.
I wouldn’t say that you “shouldn’t” be doing that. Even when Unity iPhone 1.1 is out, which has automatic batching, that’s still not free, it’s just easy. Combining will always be the fastest.
–Eric
A while back, I did a prototype test of a game that had about 50 spheres falling down and bouncing against each other. It got about 1 to 2 frames per second on the iPhone… until I combined all the spheres into a single mesh (resulting in one draw call) and then the performance went up to something like 15 fps. IT MADE A HUGE DIFFERENCE.
I have discovered that Cheetah 3D is a great tool for combining meshes and assigning joints “a.k.a bones”. I could give list out the steps involved, if anyone is interested.
You are right, but only for the basic collision shapes and if one of them is assigned for each of the “boned” objects.
As for the performance: We will see with 1.1 which one is faster and how much if at all.
What is definitely clear is that the autobatching is worlds simpler than the bone workaround to use and does not have its restrictions and shortcommings.
Not sure what you mean by “basic collision shapes” since you can use whatever colliders you like for the bones. Obviously in this case you would be using box colliders, which is no different from what you’d be doing normally anyway.
They’ve already said which is faster, particularly since skinned meshes will also be getting a pretty significant speedup.
–Eric
Thats what I meant by basic collision shapes.
Or basically: no polygon collision
As for the speed: I’ve learned my lesson from Torque and DBP. I don’t believe what I’ve not seen in action.
VFP is nice but the VFP also applies to regular object transformation, not only the bone one, so they will be seeing a gain too.
And if the batcher is smart then it does not recreate the vertexarray if the content of the batch hasn’t changed.
To me it does not make a difference if bones would be 5% faster as the flexibility I lose with them (or the requirement to precreate just too much stuff) makes them an undesireable option to me.