Indigo's physics engine currently looks for groups of colliders that have ..collided.. and attempts to resolve them. This works, but isn't how other physics engines solve the problem. Other engines look for pairs of colliders that have collided, and just solve those.
The ask in this ticket is to move to this more standard approach of solving pairs. It's unclear to me what the implications are for the current solution, but I suspect this will be more scalable and work better when we look at implementing separating axis theorem for detecting collisions.
Original issue description:
This might be a duplicate issue, but I couldn't quickly see another. I've definitely considered this before and I think it's the right thing to do. (I also suspect it's the standard thing to do...)
Additionally it should allow for an interesting possibility mentioned by @JPonte in another context, for using functions that say (ball, cube) => ??? on collision rather than two function for each colliding with the other, which should be more intuitive to use.
Indigo's physics engine currently looks for groups of colliders that have ..collided.. and attempts to resolve them. This works, but isn't how other physics engines solve the problem. Other engines look for pairs of colliders that have collided, and just solve those.
The ask in this ticket is to move to this more standard approach of solving pairs. It's unclear to me what the implications are for the current solution, but I suspect this will be more scalable and work better when we look at implementing separating axis theorem for detecting collisions.
Original issue description:
This might be a duplicate issue, but I couldn't quickly see another. I've definitely considered this before and I think it's the right thing to do. (I also suspect it's the standard thing to do...)
Additionally it should allow for an interesting possibility mentioned by @JPonte in another context, for using functions that say
(ball, cube) => ???on collision rather than two function for each colliding with the other, which should be more intuitive to use.