Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Obi Collider Performance
#9
(01-08-2019, 01:29 AM)HenryChinaski Wrote: 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.
Reply


Messages In This Thread
Obi Collider Performance - by HenryChinaski - 30-07-2019, 02:26 PM
RE: Obi Collider Performance - by josemendez - 30-07-2019, 02:51 PM
RE: Obi Collider Performance - by HenryChinaski - 30-07-2019, 05:08 PM
RE: Obi Collider Performance - by HenryChinaski - 30-07-2019, 09:36 PM
RE: Obi Collider Performance - by josemendez - 31-07-2019, 06:57 AM
RE: Obi Collider Performance - by HenryChinaski - 31-07-2019, 04:16 PM
RE: Obi Collider Performance - by josemendez - 31-07-2019, 06:21 PM
RE: Obi Collider Performance - by HenryChinaski - 01-08-2019, 01:29 AM
RE: Obi Collider Performance - by josemendez - 01-08-2019, 07:58 AM
RE: Obi Collider Performance - by HenryChinaski - 05-08-2019, 01:40 PM