#Unity Physics occasionally locks up when simulating complex scenes

1 messages · Page 1 of 1 (latest)

native trail
#

I've run into a very game-breaking issue that causes the entire Unity Editor to freeze indefinitely during my game. I have been trying to get a reproducible sample for a bug report without sharing all of my code, but I think the issue lies within Unity Physics' BVH generation so it's extremely difficult to create an abstract sample that crashes since the BVH changes with any added/removed objects. Essentially, my game consists of physics objects being split and separated into independent objects, leading to compound colliders interacting with each other. Unity Physics typically does a great job of handling this (generally less than 10ms for a large world of compound colliders), but sometimes will completely lock up (same symptoms as an infinite while loop). I have confirmed that nothing in my code is infinitely looping, so it seems that Unity Physics is the culprit. (There's no errors in the console or logs.)

I haven't seen anyone online with this issue and it's very difficult to predict or analyze the issue because Unity just locks up, but has anyone here ever encountered an issue like this or have any ideas as to how to work around it or track down its source? I've been working on this all day so I'll take any ideas you've got.

vapid dome
#

a lock up is nearly always an infinite loop

#

when you lock up attach your debugger

#

and force a break point

#

and you'll have to go through your threads to find where the code is looping

native trail
#

In this case I can't use the debugger because the infinite loop is inside Unity Physics' code, not mine.

vapid dome
#

i don't see why that stops you at all? break all will break in any code

#

i'm doubtful there is an infinite loop within physics without you corrupting it somehow

#

it could be possible to 'overwhelm' though

#

(side note, a lot of infinite loops in dots are generally caused by turning off safety and incorrectly using a hashmaps, or less commonly other containers)

native trail
#

It's interesting that you mention safety/hashmaps. This segment (in my code, oops lol) seems to be causing the issue:

            NativeHashMap<Entity, UnsafeHashSet<Entity>> meteorTriggers = new NativeHashMap<Entity, UnsafeHashSet<Entity>>(0, Allocator.Temp);
            foreach (TriggerEvent e in sim.TriggerEvents)
            {
                BlobAssetReference<Collider> colA = pworld.Bodies[e.BodyIndexA].Collider;
                BlobAssetReference<Collider> colB = pworld.Bodies[e.BodyIndexB].Collider;

                uint layerA = colA.Value.GetCollisionFilter().BelongsTo;
                uint layerB = colB.Value.GetCollisionFilter().BelongsTo;
                if ((layerA & GameLayers.METEOR) != 0)
                {
                    if (meteorTriggers.TryGetValue(e.EntityA, out UnsafeHashSet<Entity> voxelEntities))
                        voxelEntities.Add(e.EntityB);
                    else
                        meteorTriggers.Add(e.EntityA, new UnsafeHashSet<Entity>(1, Allocator.Temp) { e.EntityB });
                }
                else if ((layerB & GameLayers.METEOR) != 0)
                {
                    if (meteorTriggers.TryGetValue(e.EntityB, out UnsafeHashSet<Entity> voxelEntities))
                        voxelEntities.Add(e.EntityA);
                    else
                        meteorTriggers.Add(e.EntityB, new UnsafeHashSet<Entity>(1, Allocator.Temp) { e.EntityA });
                }
            }

Specifically, the voxelEntities.Add(e.EntityA/B) lines seem to be the culprit. Am I incorrectly using the hashmap or hashset here?

vapid dome
#

well this would be single threaded so it should be safe, though it looks kind of nasty

#

could this not just be solved easier with say a
NativeHashSet<(Entity, Entity)> map or something

native trail
#

I actually just finished implementing that! (using a custom EntityTuple struct because I was getting Burst errors with built-in tuples)

#

Thanks for all your help

vapid dome
#

normal tuples should be fine but you can't pass them in/out of burst