Physics performance / issues on the iPhone?

I've made a small prototype utilizing physics (5-6 rigid bodies) but don't yet have a iPhone publishing license. Just wondering if anyone has done any heavy physics work yet w/the iPhone and if so, found any limitations, performance issues, etc.

Cheers!

-Tyler

 

Be carefull with mesh colliders. Take in mind you're programming to an iphone. If you can use only primitives better. Spheres is the most quick collider in performance.

Be aware in Time scale and Time fixed setting in your project. i'm using right now 1 - Time , 0.1 - Time fix

Read the docs "iphone dev" in unity iphone distribution.

About the use of rigidbodys, dont know if there's limitations but i'm sure lower = better. You're developing for an iphone not a Mac Pro.

I hope that helps!

 

Hi,

yeah, done a lot of heavy physics stuff on the iPhone. This game uses up to 40-50 rigidbody and it was a monster effort to get a decent framerate out of the iPhone. Finally I ended up with around 10-11 fps when the stack of bubbles is full, but it took me around 14 days evenings' work to get it playable at that rate. A lots of little "tricks" went into it. But as you see, it's possible. Although if you do some more advanced stuff in terms of models those numbers would vary a lot, so don't expect to have 10 full characters running around with physics and stuff, that would surely hit the bounds very soon. But as said, depends heavily on your game and what you want to do.

In an upcoming game I use car physics a lot. But that limits so much that I run currently only 1 car at all...

Martin

 

Thanks for the reply's! Yea, I'm looking at doing 5-10 rigid bodies on screen at once, however only 2-3 will be active at any given time, so hopefully the physics sleep will kick on the rest. Was really just curious to see if there were any gotchas (like maybe Ageia not working on iPhone at all )

Martin, were there any specific work arounds / fixes / low hanging fruit that drastically improved framerate for you?

Cheers,

Tyler

 

I think what you want is reasonable with 2-3 characters simultaneously on screen, should work.

Well, yes, a lot of. Trying to list them here as they come of my memory:

- The stats button in the game window in Unity is your friend. Watch there the draw calls. I found those as most limiting parameter for iPhone rendering.

- Even GUI stuff uses draw calls. Check if you can combine rendering of gui elements to save draw calls.

- Use the diffuse fast shader, not diffuse or vertex. Speeds up a lot! As test, enable the stats window, look at the draw calls. Now have your test model once use the diffuse shader and once the diffuse fast shader and watch the difference in draw calls.

- If you use JS, typing your variables is a must. Had some variables untyped which Unity did not complain about and those in an Update cylcle were heavy fps cost. So watch our _every_ variable you use if it is typed or not.

- Use #pragma strict in every JS script in the first line

- Put in every script that uses GUI stuff in the Awake() function this line: useGUILayout = false;

- For the game above I replaced all 3d spheres with 2d planes. Used not the Unity planes as those have too many polys. Used a simple one generated in Cinema 4D.

- For the bubbles I restricted the rigidbody to be fixed in the rotation axis. This is a checkbox you can activate in a rigidbody. Of course does not work for every kind of model, but for my spheres it worked.

- Removed the background and used a solid color for clearing the background. Reduces the draw calls from 6 to 1 if you used before a skybox.

- Try to increase the physics timing as much as possible. Depending on the project, I was able to go up to 0.038 as timing value and still had somewhat ok physics. Greatly affects framerate.

- Try to avoid lookups like GameObject.Find("Some GO"); If you can't avoid, do them one time in the Start() function, but not in update/fixedUpdate. Try to put in your script a variable to your objects you want to reference and assign them via the Unity editor. The best reference is the one statically linked!

- Don't do anywhere string comparisons inside Update or FixedUpdates. Ultra expensive. Use integers for comparisons.

- Don't use tags on gameObjects to compare something, same as above. Expensive!

- Try to find out if stuff in your Update/FixedUpdate _really_ needs to be calculated every frame. I had great success putting simple integer counters in and do some calculations only every n'th frame.

- Textures! Textures can be expensive. What I found as good way to work with textures is to not use the highest possible resolution at start, but use the lowerst possible resolution in the import settings with maximum compression and then watch in the game which textures _really_ need a higher resolution or less compression and which are ok if they're not super brilliant. Saves a lot of memory!

- Also watch the texture import settings of EVERY texture. Check if you can live with 2bits compression and only RGB instead of RGBA.

- Force audio files to be mono. Might save lots of memory.

- Having lots of audio sources in the game costs performance, at least my experience.

- Intro screns are cool, but not on the phone. Jumping between scene files takes time. So having an intro screen always there in one scene and then load the main game makes the customer unhappy as it takes everytime so much time to view the intro. For Bubble Bang I made the intro screen scripted in a way that it shows only the very first time exactly 1 time, then never again. Think of gamers on the phone want to start the game fast, not watch endless intros!

- Carefully think of your menues if they use lots of images. If they are in the same scene as your game, those images eat a lot of the very tiny ram of the iPhone. Might make sense to put the menu into a separate scene file, otherwise it could happen people complain your game quits unexpectly on their phones (often because of too less free memory available).

Well, that is what I could recall from memory. Will update this if I can think of more stuff I did.

Martin

Update:
- I used Application.callGarbageCollectorSomething but don't know if that really helps to free up stuff. (will check tonight the exact name of it)

- For the 2D bubble planes I attached to them 3D sphere colliders to get the visual effect of 3d bubbles although they're 2D.

- For the orientation of the 2D planes I used only one time a "face to camera" call in the Start() function because computing that every frame is really expensive for such an amount of bubbles.

Update 2:
- Try putting on group GO's the "Mesh Combine Children" script. Had great success with that!

 

Martin, thanks a ton for your detailed list. Although I haven´t started with unity yet I´ll print out your list and hang it above my bed :wink:

Your answer would also fit very well into this thread I started a couple of days ago:

http://forum.unity3d.com/viewtopic.php?t=16166

("Do"s and "Don´t"s of iPhone dev.)

Marco

 

Martin, thanks for that report - it's really helpful to get a real-world example of using physics on the iphone. It has been a concern of mine, and it's probably better to avoid relying on it too heavily on that platform.

 

Code (csharp):

1.  
2. - Intro screns are cool, but not on the phone. Jumping between scene files takes time. So having an intro screen always there in one scene and then load the main game makes the customer unhappy as it takes everytime so much time to view the intro. For Bubble Bang I made the intro screen scripted in a way that it shows only the very first time exactly 1 time, then never again. Think of gamers on the phone want to start the game fast, not watch endless intros!

Nice list Martin, some very good points! Although I think it IS important to always have an intro screen on the iPhone. Because Unity 'lazy loads' the first scene, and then 'eager loads' the second scene. So if you do not have an intro scene, your game will lag when it first tries to play a sound, because it would have to load the sound into memory when it is first played, as opposed to already having the sound loading in memory if the scene had been loaded AFTER the intro scene.

 

Hmm, haven't noticed what you describe there with the lazy/eager loading, interesting. Purely from the XCode console output my feeling is that Unity really loads the scene at the time I tell it "Load that scene", not doing eager loading in the meantime when the intro is shown.

Ah, but maybe we load scenes differently! Are you using loadSceneAdditive? I'm doing complete replacement loading of the scenes to free up memory and even call in the second scene (my "main" game scene) Application.DoCleanupGarbageSomething (can't remember off head) to force also a cleanup of unused stuff and hope that way to get rid of the memory that the intro scene used.

But in general I noticed - at least in my project - jumping between scenes takes a few seconds at least. So even if I use that technique in the intro level to check whether it has been already shown once and immediately tell Unity to load the next scene, it takes a few seconds then (off head: 3-4?) until the next scene shows up. But might be specific to my game that it happens there that way.

But interesting point you brought up!

 

Great tips here,
I would suggest another things that does wonders to the performance in my experience
Inside XCode I switch the accelerometer looping off by typing

Code (csharp):

1. #define kAccelerometerFrequency     0.0

inside Application.mm I get a division by 0 error but when I press "continue" all is good.
, tell me if it works for you.

When it comes to shaders , I use
UnlitAlpha , no Lighting , Alpha testing instead of blending .
I'll give the decal shader a check though.

and try to use triggers as much as you can instead of true colliders.

Hope this helps

 

ReJ,

Can you tell us which transparency shaders are using which tests?

EgG... Does the Normal Transparent/Diffuse shader use AlphaBlending or AlphaTest?

 

I don't know about that ,
according to :

this ppt - Harnessing the Horsepower of OpenGL ES Hardware Acceleration

Is this irrelevant to the iPhone?

* Edit : No, this is not relevant to the iPhone, according to this guide for the iPhone GPU alpha blending is better.

 

Thanks ReJ, I'll try to read them.

 

Some great tips here, how did I miss that?
Although I am not getting all the statistics that is noted :

all I am getting is :

How come I can't see the physics stats, co-routines etc.?

 

thanks its very helpful..