Precomputed Deformable Assets Make Game Physics Up to 170 Times Faster

Károly Zsolnai-Fehér presents the new method as a way to simulate deformable objects—“squishy things”—at scales that are usually associated with painful compute times: cloth wrinkling over a helicopter, elastic ships bending between walls, stacked soft letters collapsing under their own weight, skeletons and vines tangling into cactus-like geometry, and millions of jack-o’-lanterns burying a tree inside a glass cylinder.

The headline result is not merely that these scenes run. It is that they run with large element counts, short simulation times per step, and, in some cases, interactive or near-interactive performance. The jack-o’-lantern scene is shown with 6.7 million elements, 5.7 million degrees of freedom, a 1/120-second time step, and about 753 milliseconds of simulation time. A cloth-over-helicopter example is shown with 2 million elements and 3 million degrees of freedom. A cactus scene is shown with 1.2 million elements, 1 million degrees of freedom, and about 171 milliseconds of simulation time.

The benchmark comparison is against Vertex Block Descent, or VBD. Zsolnai-Fehér says the new method is “about 30 to 170 times faster than VBD,” while also noting that earlier methods already had impressive real-time-looking demonstrations. The distinction he draws is speed on difficult deformable-body scenes, plus cases where the newer method completes simulations that the previous method fails to converge on.

The on-screen Lan et al. 2025 benchmark table is dense: scene name, element count, degrees of freedom, time step, parallelism method, collision type, iteration count, pre-computation time, simulation time, and reported speedup. A selection of the rows most directly discussed or shown in the presentation captures the range from interactive assets to multi-million-element contact scenes.

The strongest single real-time claim concerns a dragon made from 100,000 elements. Zsolnai-Fehér says the dragon experiment “runs easily in real-time,” and the shown interaction supports the point: a cursor grabs and drags the deformable dragon around rods while the body squashes and responds fluidly. For larger scenes, the claim is more modest but still unusual: five barbarian ships, totaling 2.5 million elements, are said to run at 3 frames per second, enough that “you can actually see it in motion as you compute it.” The frame also notes that this barbarian-ship result is an off-line rendering.

The simplified problem statement is: the input is a set of shapes and forces; the output is the new position of every small point describing those shapes. Károly Zsolnai-Fehér stresses that “every tiny point affects every other point,” and that scenes can contain millions of them. A small numerical mistake can propagate through the mesh and break the entire simulation.

That creates the long-standing tradeoff he sketches with fluid examples: fast simulations that are visibly wrong, or accurate simulations that are painfully slow. In the shown water-channel comparison, the faster version takes 30 minutes and appears blockier and less realistic; the more detailed turbulent version is labeled as taking 5 days.

The method’s target is not fluid simulation in that example, but the same computational tension: fidelity versus time. For deformable graphics, one attractive route is to divide the scene into smaller pieces and solve those pieces in parallel. GPUs are good at that kind of work. The desirable setup is not solving slice 1, then slice 2, then slice 1000, but giving the GPU all 1000 slices and solving them “in one go.”

The obstacle is that naive slicing damages the solve. Previous techniques, in his explanation, split the problem into small pieces that “ignore each other” and cause overshoot. Overshoot means a local correction in one region makes the larger object worse: the mesh wobbles, slows down, or can even “explode.” The accompanying visual shows a partitioned mesh deforming into jagged overlaps under the label “Previous techniques.”

That is the bottleneck the new method is said to attack. It keeps the parallel structure that GPUs can exploit, but adds information about how a local change affects the rest of the object.

The technical phrase shown on screen is “pre-computing a co-rotated local perturbation subspace.” Károly Zsolnai-Fehér translates that as each slice being able to tell how its own movement will stretch and pull the rest of the object before it moves. In other words, the local solve no longer behaves as if the rest of the mesh were irrelevant.

The visual explanation uses a twisting column of connected blocks. A highlighted local block rotates, and the diagram indicates how that perturbation propagates through the structure. The contrast with the previous-technique visual is stability: the “New technique” mesh deforms in a smooth, continuous wave-like way rather than breaking apart or overlapping along partition lines.

This is why the method can be both fast and stable in the demonstrations. It preserves the possibility of a parallel solve while accounting for global consequences of local motion. Zsolnai-Fehér calls this “magic,” but the explanation is specific: the method predicts how small changes affect the whole project.

The benchmark table also shows that the method is not a single-mode trick. The scenes use different parallelism methods and collision treatments. Some rows list Jacobi; others list Gauss-Seidel. Collision types include penalty and IPC. The examples range from 80,000 degrees of freedom for the dragon to 5.7 million for the jack-o’-lantern scene.

The most unusual speedup number in the table is “∞×” for the teaser row. Zsolnai-Fehér immediately qualifies it: it does not mean a time machine. It refers to cases where the previous VBD method fails to converge at all. In the shown “Animal crossing” failure, the squishy figures get stuck in mid-air instead of settling into the container. The new technique is then shown resolving the same kind of scene smoothly, with the figures falling, compressing, and piling up.

The limitation is explicit: the method has a pre-computation step. Before the simulation starts, it must run calculations. For the dragon, Károly Zsolnai-Fehér says this takes about 7 minutes. For huge scenes, he gives a figure of 67 minutes.

That precomputation is part of the method’s cost profile. The interactive dragon runs in real time once prepared, and the benchmark table lists preparation separately from simulation time. The table’s “Pre. time” column includes 1 minute for the house of cards and cloth, 7 minutes for the dragon, 45 minutes for the barbarian ships, and 67 minutes for the squeezed puffer ball.

Zsolnai-Fehér’s reading of the paper is that the precomputed object is the rest-shape Hessian matrix per deformable asset. The implication he draws for games is bounded but important: this work can be done before shipping a game. If that interpretation holds for an asset, the user would not wait through the setup calculation; they would see the fast simulation after the precomputation has already been paid.

That is the sense in which the work is presented as relevant to games: precompute per deformable asset before shipping, then use the prepared asset for fast runtime simulation.

The method changes what looks practical for prepared high-detail deformable scenes: millions of elements, stable contact-heavy motion, and simulation times that can be viewed interactively or near-interactively after precomputation. Károly Zsolnai-Fehér also emphasizes that the work is open science.

The useful distinction is between three claims. First, the method can run some prepared deformable scenes in real time, as with the 100,000-element dragon. Second, it can run much larger scenes fast enough to inspect as they compute, as with the 2.5-million-element barbarian ships at 3 frames per second. Third, in the examples shown, it reports large speedups over VBD—30× to 170× in Zsolnai-Fehér’s summary—and in some cases avoids convergence failures where VBD does not finish.