Unity ECS performance is very low when there are many physics collisions

[hoangvanthang23091998]

Hello everyone, I’m building an ECS system for my game and facing a major performance issue on a Galaxy A12 mobile device. When I move a sphere collider that collides with about 200 other objects and pulls them toward its center, everything runs fine in the editor. However, the profiler on the device shows that each frame takes around 600ms.

[hoangvanthang23091998]

I checked the profiler and my jobs are working fine with time <= 1.01ms however NarrowPhase:ParallelCreateContantsJob is taking 724.36ms. Is this a system bug of Unity physics ECS? How can I solve it?

[apkdev]

Hint 1:

Hint 2:

Check the profiler’s timeline view

Hint 3 so I’m a little more useful:

@MelvMay

Let’s take this to the extreme which I think helps clarify what’s really going on. Let’s say you’ve asked for the fixed-update to happen at 60hz (1/60 sec) or 16.6667ms . Let’s say the first frame that renders takes a crazy amount of time, say, 10 seconds! What this means then is that the fixed-update time is actually at least 10 seconds behind “game time”. What then needs to happen is for the fixed-update to be called many times until it has caught up with “game time”. In this case it’ll result in 60 * 10 seconds = 600 calls to fixed-update happening. Anything hooked into that would be called this many times so physics would perform a simualtion step of (1/60) but 600 times. By the end of that, you’d end up with the same result even if it had called that over a real-time period of 10 seconds and this is the point of fixed-update, at least for physics; ensure that the same results occur even if real-time is delayed, typically by rendering or by user-scripts.

The major problem here then is that you took 10 seconds to render a frame but because of that you then had to perform 600 fixed-update step which itself takes a lot of time and puts itself even further behind “game time”. This is a spiral of death that cannot be recovered from.

The Maximum Allowed Timestep is a limit that stops extreme situations like this from causing serious problems. I mean 10 seconds delay is unrealistic and certainly an extreme case but this is why the maximum allowed time-step is 0.1 so 1/10th second (100ms). If you hit this maximum threshold then the excess time is ignored and effectively lost. The price is lost time for the benefit of not dragging everything down into a spiral loop of death.

[Laicasaane]

Please show the Profiler in Timeline view, not Hierarchy view.

[hoangvanthang23091998]

This is Profiler in Timeline view. I still haven’t found the cause of this bottleneck.

[apkdev]

Here’s what I think is happening:

• The game slows down (probably because of the large collision count)
• Because the previous frame took a long time, in the next frame the game needs to run physics systems multiple times to “catch up”
• Because the physics update had to be run multiple times, the frame took even longer to calculate, which means the next “catch up” will take even longer

In other words, your mobile device isn’t fast enough to run this. I would try to optimize the physics simulation. Colliding with 200 objects doesn’t sound like a great idea, can it be avoided? Maybe use a faster collider type if possible (e.g. avoid mesh colliders)? Are there physics settings you can tweak?

[hoangvanthang23091998]

My collisions are all necessary. This is my current setting, and I have also tried changing various other settings, but none of them worked well.

I have an idea: instead of checking for physical collisions, I will write a system to check the positions of objects within the radius of a sphere collider and handle them manually. I think this will help me reduce unnecessary collisions.

[hoangvanthang23091998]

After some testing i found out that my game is slowing down due to the layer transfer function of entities every time there is a collision. i need to change the layer of entities to change the way they collide with the environment. however i have not found any documentation that guides how to change the layer of entities in an optimal way. Below is my layer change function

[BurstCompile]
private static unsafe void UpdateColliderFilter(ref ComponentLookup<PhysicsCollider> colliderLookupLocal,
                                                  in EntityCommandBuffer.ParallelWriter ecb,
                                                  Entity entity, int entityInQueryIndex,
                                                  uint newLayer, uint colliderWith)
{
    var collider = colliderLookupLocal[entity];
    if (!collider.Value.IsCreated)
        return;

    int size = collider.Value.Value.MemorySize;
    var newColliderPtr = (Unity.Physics.Collider*)Unity.Collections.LowLevel.Unsafe.UnsafeUtility.Malloc(size, 16, Allocator.Temp);
    Unity.Collections.LowLevel.Unsafe.UnsafeUtility.MemCpy(newColliderPtr, collider.Value.GetUnsafePtr(), size);

    var newFilter = newColliderPtr->GetCollisionFilter();
    newFilter.BelongsTo = newLayer;
    newFilter.CollidesWith = colliderWith;
    newColliderPtr->SetCollisionFilter(newFilter);

    var newCollider = BlobAssetReference<Unity.Physics.Collider>.Create(newColliderPtr, size);
    Unity.Collections.LowLevel.Unsafe.UnsafeUtility.Free(newColliderPtr, Allocator.Temp);
    collider.Value = newCollider;
    ecb.SetComponent(entityInQueryIndex, entity, collider);
}

[apkdev]

Looks like you’re creating a new collider every time you want to change the collision filter. (It’s a bit unfortunate that the collision filter is stored in the collider blob asset, hopefully this improves in the future.)

Instead of instantiating the colliders you can try forcing them to be unique so they’re baked separately:

@PhilSA

If I’m not mistaken, in the PhysicsShape component, you can enable “Force Unique” and that’ll make your colliders independent from each other.

Now you should be able to modify the collision filter directly without copying the blob asset:

@teasully

This seems to do the trick:

static void SetCollisionFilter(Entity entity, uint belongsTo, uint collidesWith)
{
  var collider = EntityManager.GetComponentData<PhysicsCollider>(entity);
  Assert.IsTrue(collider.Value.Value.CollisionType == CollisionType.Convex);

  unsafe
  {
    var header = (ConvexCollider*)collider.ColliderPtr;
    var filter = header->Filter;

    filter.BelongsTo = belongsTo;
    filter.CollidesWith = collidesWith;

    header->Filter = filter;
  }
}

[hoangvanthang23091998]

Thank you very much. i will try it

[hoangvanthang23091998]

i tried the code you mentioned but it seems it no longer works in entities version 1.3.10

[daniel-holz]

What is the error? You should be able to do something very similar with the latest version of Unity Physics.

For some useful info on how layers and collision filters work in Unity Physics, have a look at the documentation:

The PhysicsCollider component | Unity Physics | 1.4.0-pre.3

Also, you could check out relevant sample scenes in the PhysicsSamples project:

EntityComponentSystemSamples/PhysicsSamples at master ·...

The sample scene “5g4. Runtime Collision Filter Modification.unity” demonstrates how to modify collision filters at runtime, which seems to be what you are looking for:

[Silrider]

Thank you! for the share how to change collision filter in runtime!