[IOS] Physics performance issues


I am having some performance issues with Sample 11 Physics on IOS. It is extremely slow compared to a quick test I did a while ago using Ogre3d and Bullet Physics. Is it possible that the entity system is causing the slowdown ? Is there a good way to do proper profiling ?



A profiler is built into the game engine by default (unless you have turned this build option off explicitly). In iOS sample app, you can turn on the profiler display output by pressing the Setting button (cogwheel) and then the HUD button.

If the physics sample seems exceedingly slow, you may be running it in debug mode. Turning off shadows will also help performance, but they shouldn’t kill it.

I have disabled shadows and shaders. And I am running in release mode. But still multiple active rigid bodies are spiking the CPU until they come to rest again. Is there a way to log the profiling to file so that I can post my results ?
I hope that SIMD is working properly on IOS . Do we have BT_USE_NEON enabled ?

I’m quite sure Neon is not enabled. Engine::DumpProfiler() writes accumulated profiler status to the log, but in iOS release mode logging is disabled, so it’s not directly available. The amount of objects in the example 11 is not high so we might have some “stupid” performance bug that has creeped in. I will be able to test this on Android first.

Thanks a lot. The last time I checked Neon for Bullet physics was available only for IOS . Not sure if it will work on Android but still might be a good test case. Let me know if you need me to test something on IOS device.

Testing the 11_Physics example on Android I saw a quite high usage of CPU time (about 20ms per frame, and even 40ms once there were more objects) when spawned boxes collided with the stack and made everything to wake up. Will have to see if this is an actual performance regression.

Did not find regressions or specific code hotspots that would have appeared. One thing I did (pushed to master) was to disable Bullet’s hierarchical profiling, as that causes system calls under the hood on Unix-like systems. Will test iOS later. On a slow CPU, physics is something you can easily make to “spiral to its death” due to physics & rendering load causing longer frame time deltas, which the physics needs to catch up by taking more internal simulation steps.

Is it currently exposed to tweak Bullet’s Broadphase schemes or substeps ?

Likely not to the degree you’d want. I recommend digging into the PhysicsWorld.cpp code, which does the Bullet world and collision setup.

Thanks I will take a look. Are you familiar with BtOgre : github.com/nikki93/btogre/tree/master
It was slightly more tweakable on the Bullet Physics side .

I took a peek but still I am not extremely familiar with the code I will need to test it although it might be a good idea to expose the numbers of substeps for Bullet Physics.
It seems by default it is trying to be adaptive based on fps. If maxSubSteps is exposed it will be really neat for greater control over the solver.

[code]void PhysicsWorld::Update(float timeStep)

float internalTimeStep = 1.0f / fps_;

if (interpolation_)
    int maxSubSteps = (int)(timeStep * fps_) + 1;
    world_->stepSimulation(timeStep, maxSubSteps, internalTimeStep);
if (manualSubstep)
    int maxSubSteps = 10;
    world_->stepSimulation(timeStep, maxSubSteps, internalTimeStep);
    timeAcc_ += timeStep;
    while (timeAcc_ >= internalTimeStep)
        world_->stepSimulation(internalTimeStep, 0, internalTimeStep);
        timeAcc_ -= internalTimeStep;

Currently we tick the physics at the same internal substep length (by default 60fps) and always try to cover all the passed time.

Allowing a cap for max substeps will lead to physics time slowing down, if it tries to cover too much time. This is probably still the better option than adapting the substep length on the fly, as that could actually cause differing physics behavior (constraint explosion, tunneling etc.)

Let say we want 1 substep for cheap approximation can we just compensate, maybe just using euler integrator would help ?

Unrelated, but i noticed that someone is talking about his “Release Build” of the engine for iOS. How do you guys do this, given the fact that generating a XCode project for compiling a iOS version gives a wrong target / action association pairs?


There is now a possibility to cap physics substeps or enable adaptive step (always 1 substep per rendering frame), see PhysicsWorld::SetMaxSubSteps(). Both have their problems, but should help to prevent the “spiral of death” issue.

Awesome thanks a lot :slight_smile:

Can we add BT_USE_NEON as default for mobile in the cmake ?

Looked into it further and what I said earlier may be incorrect. I’m not 100% sure whether all the conditionals within Bullet’s btScalar.h are triggered right, but URHO3D_SSE should be defined by default, which in turn should result in it being enabled. If you have time, please verify.

I can confirm that default Urho3d build has SIMD enabled by default on IOS devices.
I tested on IOS device and just to be sure I checked all the BT_USE_NEON conditionals and they all are set to 1 .