Quote:So just to rule this out: Is there any known limit on the number of active Obi colliders / rigidbodies with the Burst backend?

(17-02-2022, 07:24 PM)pdinklag Wrote: As mentioned in the corresponding thread regarding libOni, I decided to switch back to Burst in the hope to be able to debug this somehow using the source code.
Luckily, this was as easy as commenting the BurstCompile attribute for IdentifyMovingColliders and provoke the crash in the Editor (which I still don't know how to do deterministically, but least I got the means to make it happen within few minutes).

I got it down to this (Obi 6.4):

Code:

IndexOutOfRangeException: Index 0 is out of range of '0' Length.
Unity.Collections.NativeArray`1[T].FailOutOfRangeError (System.Int32 index) (at <ad50157ee00e45cdb3c8bd67012f8804>:0)
Unity.Collections.NativeArray`1[T].CheckElementReadAccess (System.Int32 index) (at <ad50157ee00e45cdb3c8bd67012f8804>:0)
Unity.Collections.NativeArray`1[T].get_Item (System.Int32 index) (at <ad50157ee00e45cdb3c8bd67012f8804>:0)
Obi.BurstColliderWorld+IdentifyMovingColliders.Execute (System.Int32 i) (at Assets/Plugins/Obi/Scripts/Common/Backends/Burst/Collisions/BurstColliderWorld.cs:154)
Unity.Jobs.IJobParallelForExtensions+ParallelForJobStruct`1[T].Execute (T& jobData, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at <ad50157ee00e45cdb3c8bd67012f8804>:0)
Unity.Jobs.JobHandle:ScheduleBatchedJobsAndComplete(JobHandle&)
Unity.Jobs.JobHandle:Complete()
Obi.BurstColliderWorld:UpdateWorld(Single) (at Assets/Plugins/Obi/Scripts/Common/Backends/Burst/Collisions/BurstColliderWorld.cs:117)
Obi.ObiColliderWorld:UpdateWorld(Single) (at Assets/Plugins/Obi/Scripts/Common/Collisions/ObiColliderWorld.cs:397)
Obi.ObiUpdater:BeginStep(Single) (at Assets/Plugins/Obi/Scripts/Common/Updaters/ObiUpdater.cs:56)
Obi.ObiFixedUpdater:FixedUpdate() (at Assets/Plugins/Obi/Scripts/Common/Updaters/ObiFixedUpdater.cs:46)

Looks like it's trying to access collisionMaterials at index 0 when the array is empty. Indeed, it seems as though it's always empty.

I'm not sure what to make of this, and I can't find any code that constructs a BurstColliderShape so I can't find out what's slipping a 0 as its materialIndex.
But I hope this helps!

(18-02-2022, 08:58 AM)pdinklag Wrote: More news:

Code:

var identifyMoving = new IdentifyMovingColliders
{
    movingColliders = movingColliders.AsParallelWriter(),
    shapes = world.colliderShapes.AsNativeArray<BurstColliderShape>(cellSpans.count),
    rigidbodies = world.rigidbodies.AsNativeArray<BurstRigidbody>(),
    collisionMaterials = world.collisionMaterials.AsNativeArray<BurstCollisionMaterial>(),
    bounds = world.colliderAabbs.AsNativeArray<BurstAabb>(cellSpans.count),
    cellIndices = cellSpans.AsNativeArray<BurstCellSpan>(),
    colliderCount = colliderCount,
    dt = deltaTime
};
JobHandle movingHandle = identifyMoving.Schedule(cellSpans.count, 128);

I added the following line before this happens:

Code:

if(cellSpans.count > world.colliderShapes.count) {
    Debug.LogErrorFormat("BurstColliderWorld: cellSpans.count={0}, world.colliderShapes.count={1}",
        cellSpans.count, world.colliderShapes.count);
}

And this is logged rather often, not just when crashing, which means that the cell spans array is oftentimes larger than the collider shapes array, thus resulting in plenty of bad accesses on the shapes array in the job (because it's a parallel for over cellSpans.count items)

I'm honestly not sure what these cell spans are, but if their number is supposed to be synchronized to the number of colliders, that's where I'd look.

(18-02-2022, 09:18 AM)josemendez Wrote: When colliders are disabled / removed, they're moved to the end of the colliders list. Then, colliderShapes.count is reduced, however cellSpans.count is not. This is the mechanism used to identify disabled colliders and remove them from the grid: being lists, the backing arrays for both cellSpans and colliderShapes still have the same size. IdentifyMoving colliders will access colliders past colliderShapes.count, and identify that they're disabled precisely because they're past the amount of cells (line 173 of BurstColliderWorld):

Quote:Would it be possible for me to take a look at your project, or at least get my hands on a simplified scene that reproduces the issue? This way I can join you more effectively on debugging.

(18-02-2022, 11:41 AM)pdinklag Wrote: IMO, the real issue here is that the materialIndex of a collider shape is (auto-)initialized as zero - a completely invalid value in my case where I don't use Obi collision materials - when it should be -1 to indicate "none (yet)". This can easily be fixed in ObiColliderHandle.CreateCollider. I just tried this and was unable to provoke the error again, so that may be the simple solution. I'll do a longer playtest in a build later.

Code:

colliderShapes.Add(new ColliderShape() { materialIndex = -1 });

(24-04-2022, 08:51 AM)pdinklag Wrote: It's been quite a while now and I have never experienced this crash again, so this actually seems to have been the problem. It also explains why both Burst and libOni were affected. Luckily, the fix is that easy and you may want to incorporate this into Obi. Thanks for the hints to get to the bottom of this!