Obi Collider Performance

[HenryChinaski]

Hi,
I just bought Obi Softbody and the test scenes work great.
Unfortunately thoug I have a major problem with the general usability for our project. I was - after carefully reading the documentation - under the assumption, that the limiting performance factor of the asset are the quantity and quality of the softbodies on screen. I have a medium size free roamable world where I wanted to drop softbody phssics entities around. But even if I just drop a single softbody I still need to assign Obi Colliders to every collider in the scene that the softbody could come in contact with. This on the other hand lead to an immense drop in fps from 60 to 2 with not even any softbody in the scene. Am I missing something or is this a limitation? Did I miss it while reading the documentation?

Best regards,
Daniel

[josemendez]

Hi,
I just bought Obi Softbody and the test scenes work great.
Unfortunately thoug I have a major problem with the general usability for our project. I was - after carefully reading the documentation - under the assumption, that the limiting performance factor of the asset are the quantity and quality of the softbodies on screen. I have a medium size free roamable world where I wanted to drop softbody phssics entities around. But even if I just drop a single softbody I still need to assign Obi Colliders to every collider in the scene that the softbody could come in contact with. This on the other hand lead to an immense drop in fps from 60 to 2 with not even any softbody in the scene. Am I missing something or is this a limitation? Did I miss it while reading the documentation?

Best regards,
Daniel

Hi,

Unity does not allow for native code to interface directly with its own colliders. For that, having access to Unity's source code would be required. The next best thing is to have our own collider representation, and keep it in sync with Unity's. This is what the ObiCollider component does.

As long as a collider is static, the overhead of having a ObiCollider is zero. However if a collider moves around, ObiCollider must copy all collider properties (position,orientation,bounds,etc) to Obi's internal engine every time they change. While extremely cheap, the cost of this copy can add up if you have several hundreds/thousands of non static colliders moving every frame.

May I take a look at a profiler pic of your game?

kind regards,

[HenryChinaski]

Thanks for the quick and very relieving reply.
If you say that static Obi Colliders have zero overhead, then there must have been an error on our side. 
I will test a bit around and will send you screenshots if I should not be able to solve the problem.

[HenryChinaski]

Unfortunately I seem to oversee something.
I assigned couple hundreds Obi Colliders to static MeshColliders. There are no Soft Body Objects in the scene.
This is what the profiler shows about Obi.

[josemendez]

Unfortunately I seem to oversee something.
I assigned couple hundreds Obi Colliders to static MeshColliders. There are no Soft Body Objects in the scene.
This is what the profiler shows about Obi.

Hi,

For starters your FixedUpdate() is being called three times per frame. Make sure your max timestep is low enough to prevent spiraling.

Then, deep profile to determine what inside FixedUpdate() is taking up most of the time.

kind regards,

[HenryChinaski]

Hi,

For starters your FixedUpdate() is being called three times per frame. Make sure your max timestep is low enough to prevent spiraling.

Then, deep profile to determine what inside FixedUpdate() is taking up most of the time.

kind regards,

Thanks for the information. Could I ask you to elaborate shortly on the max timestep thing? Never changed that value. It is at the moment at 0.3333. I am targeting 30-45 fps. 

I also attach a screenshot of the deep profiling. When trying to click on the "Show related objects" button, Unity crashes.

[josemendez]

Thanks for the information. Could I ask you to elaborate shortly on the max timestep thing? Never changed that value. It is at the moment at 0.3333. I am targeting 30-45 fps. 

I also attach a screenshot of the deep profiling. When trying to click on the "Show related objects" button, Unity crashes.

Simply comparing two objects for equality is taking up 61 ms, because FixedUpdate is called 16 times per frame, for a total of +40.000 object comparisons per frame.

From the profiler numbers I calculate you have around 652 mesh colliders in your scene, is that correct? Maybe you can merge some of them together, use primitive colliders (which are always much, much cheaper than MeshColliders)), or add/remove ObiColliders dynamically.

Max timestep is a pretty critical setting, as it controls how many times is Unity allowed to recalculate physics per frame, when the frame rate suffers a hit for any reason. A too high value can quickly spiral out of control and make performance plummet, if the physics recalculation itself takes more wall-clock time than the game-time it is accounting for. Ideally it should be set to a multiple of the fixed timestep. Eg: If you want to allow a maximum of 2 physics steps per frame and your fixed timestep is 0.02, set max timestep to 0.04. A max timestep of 0.33 allows for 0.33/0.02 = 16.5 steps before Unity gives up and starts the next frame, which is exactly what's happening here.

[HenryChinaski]

Thank you very much for your extensive explanations that were very helpful for me.
I set the max timestep to 0.4 and changed half of the colliders to box colliders.
There is a very noticeable difference, but still, Obi Solver uses around 8% even with not a single SoftBody in the scene (One Obi Collider is on a Player Rigidbody).
I have an i7-6700k.

I suppose I misunderstood your "the overhead of having a ObiCollider is zero" with "there is no impact on performance"?
So, if you have a mid-large level consisting of tiles (therefore so many colliders), is it normal to have a constant performance decrease by Obi Solver?
Can I just turn ObiSolver off while there are no SoftBodies on screen?

Thanks again for you help.
In any case I will rate this asset great because it is.

[josemendez]

Thank you very much for your extensive explanations that were very helpful for me.
I set the max timestep to 0.4 and changed half of the colliders to box colliders.
There is a very noticeable difference, but still, Obi Solver uses around 8% even with not a single SoftBody in the scene (One Obi Collider is on a Player Rigidbody).
I have an i7-6700k.

I suppose I misunderstood your "the overhead of having a ObiCollider is zero" with "there is no impact on performance"?
So, if you have a mid-large level consisting of tiles (therefore so many colliders), is it normal to have a constant performance decrease by Obi Solver?
Can I just turn ObiSolver off while there are no SoftBodies on screen?

Thanks again for you help.
In any case I will rate this asset great because it is.

Hi!

Even when there's no actual work to do by the solver, it still has to manage internal state, and ObiColliders need to check whether anything has changed in their Collider alter-ego. Depending on the size of your scene and the maximum amount of particles that can be managed by the solver, the base cost could add up.

This is the actual code executed every FixedUpdate, for each ObiCollider:

Code:

if ((tracker != null && tracker.UpdateIfNeeded()) ||
    transform.hasChanged ||  
    dirty ||
    unityColliderEnabled != wasUnityColliderEnabled)
{
UpdateCollider();
}

The "tracker" is a small class that checks if the bounds (or shape, in the case of MeshColliders and DistanceFields) of the collider have changed since the last update. So, this code:

- Compares two Bounds to see if there's a difference.
- Checks if the transform has changed
- Checks if the "dirty" flag has been explicitly set.
- Checks if the collider has been enabled/disabled this last frame.

Only if any of these conditions is met, we do the heavier stuff  (copying collider data over to our physics engine) . So when I said "zero" overhead, I actually meant "as little as possible" or "close to zero", but still we still have to perform these checks every frame. Checking this for many hundreds of colliders probably won't be negligible, but it's the best we can do.

[HenryChinaski]

Thank you so much for your in-depth explanations.
Really valuable to understand the limits of an asset.
I played a bit more around and found two more beginner questions, that should be easy to answer.
I will make a separate thread for them though.