I have two objects, both with rigidbody2Ds and both have continuous detection turned on. The square object is doing all of it’s movement by rigidbody2D.MovePosition(). However, at fast speeds I will still have issues with the object passing through another object.
If it’s relevant, they collide with each other using triggers that are on a child object (child objects do not have a rigidbody2D).
I’m hoping to solve this without doing my own BoxCast when I use MovePosition so hoping that I’m missing something or some setting.
Ok, no response :p. I’m trying to figure out if some of the Physics2DSettings can be tweaked to give me better results. However, I can’t really tell what they do. Position Iterations sounds plausible to something I might want to tweak but I see no difference regardless of what value I place.
I don’t see a hit in performance either so I’m not sure what it does.
I can resolve my paticular issue by increasing the fixed timestep to a much smaller number. This seems like a less ideal solution though. Is it a bug that my rigibodies are moving through each other even though both are set to continuous and are both only moved with rigidbody2D.MovePosition()?
I experimented around to try to determine exactly what was going on and I believe I have found the issue.
If I have two continuous detection objects with two non-trigger colliders then they appropriately collide when attempt to move fast past each other. However, if they are triggers instead, the trigger fails to detect. It’s only when moving fast, if I move them slowly into each other then the triggers do detect.
It looks like continuous detection only works for non-trigger colliders and is still discrete for trigger colliders. Is this by design or a bug?
I think people should be aware of the fact that this is a physics engine, designed for simulating a great variety of physical behaviours but still being limited. Collision detection on objects with high relative velocity have, afaik, always been troublesome and will still be present in PhysX 3.
Some brainstorming: instead of a trigger collider, cast a ray in the direction of your velocity, multiply that by an arbitrary number and you should get a much more stable collision detection.
If this does not give you the desired precision, you could try changing the trigger collider’s size based on your velocity vector. This should give your trigger collider a bigger timestamp to work with.
The issue appears to be that continuous detection works for colliders but not triggers.That looks like a bug to me Having a faster time step has fixed the issue for me without bring too much of a hit to my performance. If I end up not being able to rely on that then I imagine I can do my own box casting to get me a good enough solution.
Having a faster time step has fixed the issue for me without bring too much of a hit to my performance. If I end up not being able to rely on that then I imagine I can do my own box casting to get me a good enough solution.