Hacker News Reader

Comment by ghusbands | Hacker News Reader

Is anyone out there working on continuous physics engines? This, like most any physics library I can find, uses the fix-after-intersecting fixed-time-step model, which makes everything act like a stiff sponge, even if you greatly increase the number of iterations per frame.

Carmageddon 2 (as the last example I can think of) instead found out when the next intersection would happen, precisely, moved time forward exactly that far and then resolved the collision using impulses and would then repeat until it reached a frame's worth of time. In pathological cases, this resulted in a frame taking nearly a second, but that was rare and the physics were much less spongey and more realistic.

View on HN

It does CCD: https://nphysics.org/continuous_collision_detection/

Not sure if that is what you had in mind. Also, intersections / collisions aren't the only dynamic in such a simulation.

> It does CCD

Intersection and post-correction still seems to be present (and the sponge/spring behaviour) in demos even when you increase CCD steps and enable sub-stepping. Look at how much the bottom cubes/spheres intersect when the stack lands. (It's hard to tell what the demo called CCD is demonstrating.)

> intersections / collisions aren't the only dynamic in such a simulation.

Fair. (Contact points and friction also seemed more stable/realistic in Carmageddon 2 than in most physics libraries.)

There are two separate things here, interpenetration due how contacts/constraints are solved, and whether you do continuous collision sub-stepping or not.

For stability and performance reasons physics engines usually have parameters that soften or add compliance to contacts/constraints. A bit of compliance is almost always better than infinitely stiff collisions/constraints. There are cases where infinitely stiff systems either have no solution, are very expensive to solve, or would produce very extreme impulses (causing things to explode). Including some compliance fixes these issues. It is also often required to produces more realistic looking results since objects in real life aren't infinitely stiff, they either flex or break.

For performance reasons most physics engines also do not completely solve their constraints. They either use a fixed number of iterations (most common, including the demos here) or solve up to some specified error threshold. This tends to add some additional compliance to complex scenes (stacks/piles of objects for example).

With the right parameters a good rigid body physics engine should be able to prevent noticeable interpenetration in most situations, though the performance cost may not be worth it. In these demos if you max out Position iterations, velocity iterations, and frequency you should see significantly less interpenetration.

As for continuous collision detection/sub-stepping, this is a very common feature to prevent fast moving objects from clipping into or tunneling through other objects. However resting/continuous contact cannot be handled by stepping to the next intersection time and so have to be handled differently. Also multiple simultaneous or near simultaneous collisions can grind things to a halt in degenerate cases (such as multiple stacked objects that are almost, but not quite in resting contact). This is why physics engines that support continuous collision usually let you set a maximum number of sub-steps.

Yeah, I have. I’ve implemented all of the primitives I could find and then created novel algorithms for primitives I could not find algorithms for. You can find my work here, although I don’t recommend using the library itself: https://github.com/maplant/mgf

Continuous collision detection is great if you only need spheres, capsules, or some combination for moving objects and all of your static objects are triangles. EPA algorithms are far less accurate than exact algorithms, plus the continuous algorithms are faster and give you the contact normal for free (I.e, the problem of determining which direction the objects need to be pushed is trivial, as the objects aren’t overlapping to begin with).

If you only have one moving object that interacts with static objects only, it is possible to prevent overlap as you described.

However, if you have a complex system, you can’t just stop an object before it overlaps. The best thing to do is to move the objects the remaining part of the time step, converting the contact information from the TOI collision to one where the contact points have traveled and the geometries are overlapping.

So really, I would say the primary benefit of continuous collision detection routines are supplemental to a good collision/contact generation routine, and they don’t really affect the physics simulation in very many meaningful ways, unless your engine uses it in extremely specific situations

>In pathological cases, this resulted in a frame taking nearly a second

I wonder if someone uses a hybrid approach of CCD with a constrained time budget, meaning you will use CCD until the budget is exhausted, after which simulation will jump to the next frame time.

Do you have any links to a description of the Carma 2 physics engine?

Reply on news.ycombinator.com