From ff343bda8663aa1d60ac888ca2b17be34c976991 Mon Sep 17 00:00:00 2001 From: Erin Catto Date: Wed, 7 Feb 2024 14:37:23 -0800 Subject: [PATCH] rebuilding site Wed, Feb 7, 2024 2:37:23 PM --- posts/2024/02/solver2d/index.html | 118 +++++++++++++++++++++++++++++- 1 file changed, 115 insertions(+), 3 deletions(-) diff --git a/posts/2024/02/solver2d/index.html b/posts/2024/02/solver2d/index.html index 4298fc1..f6a571e 100644 --- a/posts/2024/02/solver2d/index.html +++ b/posts/2024/02/solver2d/index.html @@ -284,14 +284,126 @@

Results

+

Update: Performance

+

Solver2D is not optimized, so it is not appropriate to compare absolute performance numbers for all the solvers. However, I think it is meaningful to compare the number of body and constraint traversals each solver must perform for the 4/2 iteration limits. The actual number of traversals in Solver2D may be higher as these numbers account for loops that could be easily merged. For example, constraint preparation can often be merged with warm starting, but I didn't write it that way in order to allow for more code sharing. There are some loops that could probably be merged with some extra effort, but that is not reflected in this table.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SolverBody LoopsConstraint Loops
PGS26
PGS NGS38
PGS NGS Block38
PGS Soft38
TGS Sticky118
TGS Soft910
TGS NGS910
XPBD910
+

Constraint loops are much more expensive than body loops. Constraints do more math and they also have more cache misses when a constraint accesses the connected bodies. So if we want to compare solvers at a somewhat equal performance level, I would add more primary iterations to solvers with lower constraint loop counts to bring them up to par. Here's what I suggest:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SolverAdded Primary IterationsTotal
PGS48
PGS NGS26
PGS NGS Block26
PGS Soft26
TGS Sticky26
TGS Soft04
TGS NGS04
XPBD04
+

Here's the result for the large pyramid test: + +

+ +
+

Future

There are certainly more solver variations than I've tried so far. Here are some future options to try:

  1. Shock propagation, from the paper “Nonconvex Rigid Bodies with Stacking”
  2. Conjugate residual method, from the paper “Non-Smooth Newton Methods for Deformable Multi-Body Dynamics”
    3. -
  3. A direct solver. I'm not sure what the state of the art is for direct solvers, so this would require more research. -I've also thought about adding a joint coordinate solver, like Featherstone's algorithm. However, this is not a complete solver because it does not address contact. Still it might be interesting to see it for ragdolls and other samples with joints.
    4. +
  4. A direct solver. I'm not sure what the state of the art is for direct solvers, so this would require more research.
    5. +
  5. GPU friendly solvers. Jacobi, mass-splitting, etc.
+

I've also thought about adding a joint coordinate solver, like Featherstone's algorithm. However, this is not a complete solver because it does not address contact. Still it might be interesting to see it for ragdolls and other samples with joints.

However, I should probably get back to finishing Box2D version 3.0!

@@ -301,7 +413,7 @@

Future

-

3632 words

+

3893 words

2024-02-04 16:00 -0800