Feedback Deleting collider invalidates collider id in ObiPinConstraintsBatch.colliderIndices

[nicity]

Thanks for the quick reply! I will take a look for ObiParticleAttachment's UpdateAttachment
Changed type of the thread to be "Feedback", as the observed behaviour is a bit unexpected, of course it is for the performance sake

Hi!

It's common for collider index to be >= shapes.Length, since colliders that need to be deleted are moved to the end of the shapes array and then its length reduced by 1 (while keeping its capacity intact).


Yes, this is the intended behavior: destroying a collider changes the index of both the collider being destroyed and of the collider at the end of the list at that moment, since we use a remove at swap back pattern for deletion (similar to this).

For this reason particle attachments check for changes to the handle's collider index and mark the constraint dirty in case it has changed, so that the collider index is updated in ObiPinConstraintsBatch. See ObiParticleAttachment's UpdateAttachment() method for reference:

Code:

// in case the handle has been updated/invalidated (for instance, when disabling the target collider) rebuild constraints:
if (attachedCollider != null &&
     attachedCollider.Handle != null &&
     attachedCollider.Handle.index != attachedColliderHandleIndex)
{
     attachedColliderHandleIndex = attachedCollider.Handle.index;
     m_Actor.SetConstraintsDirty(Oni.ConstraintType.Pin);
}

In case you're manually managing pin constraints, you must manually update their corresponding collider index when needed and set the constraints dirty (as you would when modifying any constraint data).

Remember that these are indices, not IDs, so they do not persist over time. The same applies to particle indices engine-wide. This is the reason ObiResourceHandle<T> and ObiColliderHandle exist - otherwise we could just work with a value type (a simple integer), instead of passing a reference type: by passing a class instance around the engine can modify its data and anyone holding a reference to it can immediately see it change, no need for the engine to know who is looking at the instance.

If you're encountering this issue when using particle attachments instead of manually managed pin constraints, would it be possible for you to share a project that reproduces the problem by sending it to support(at)virtualmethodstudio.com?

let me know if you need further help. kind regards,