18-02-2022, 09:18 AM
(This post was last modified: 18-02-2022, 09:49 AM by josemendez.)
(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.
It is normal for the amount of cell spans to be larger than the amount of active colliders, in fact this will very often be the case. The collision detection broad phase uses a multilevel grid (a 4-D regular grid, x,y,z being spatial coordinates and w being level), each collider is inserted in the grid and its cell span is the min and max cells overlapped by it.
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):
Code:
// if the collider is at the tail (removed), we will only remove it from its current cellspan.
// if the new cellspan and the current one are different, we must remove it from its current cellspan and add it to its new one.
if (i >= colliderCount || cellIndices[i] != newSpan)
So this is not the source of the problem, although it could be related. Something certainly smells fishy around there. 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.
kind regards,