pistachiopro

Something that set Baba is You apart for me compared to any other puzzle game I can remember playing is the puzzles themselves were actually "funny." Not like Portal, where you solved puzzles alongside a funny narrative, but in the actually language of the puzzles themselves there are setups which get subverted in absurd and delightful ways, often in multiple layers, as you work your way through to a solution. Playing made me feel like the math part of my brain was laughing.

The game doesn't hold your hand, and I think it took about 10 hours for me to learn enough of the puzzle language for things to get really good (and then it started to descend into frustrating fiddliness in the deep endgame), but the middle 30 hours or so we're some of the most gratifying gameplay I've experienced.

It kind of felt like the anti-Witness. The Witness was fastidiously fair and so carefully constructed I can look back at it and marvel, but actually playing it was pretty formal and mirthless. Baba is You can be a little sloppy and unfair, but it's warm and fun and funny, and the actual craftsmanship of the puzzles themselves is still top tier, in it's own way.

Take a relatively simple large language model like Llama 1. It has a context of 2048 tokens and each token can be one of 32,000 values. So the lookup table would need 32,000^2048 entries. That's not just impractically large, that's larger than cosmically large. There are only estimated to be about 10^80 atoms in the visible universe. So while a 32,000^2048 lookup table might be a valid concept mathematically, it's not anything you can intuit physically, and therefore not something you can say is incapable of reason.

Practically all materials behave nonlinearly when stretched or compressed a visible amount. For certain structural applications, though, if that happens we've already failed. Linear models work really well for designing big concrete structures and certain metal structures. Sometimes we try to apply linear models to other things, but that's always kind of fishy.

LLMs are being trained on a smaller and smaller percentage of human prose. Right now it seems like code is the best source for the bulk of an LLM's diet, but it's also looking likely that synthetic math text will be even better. The structured reasoning of code and math seems to be what actually makes these big LLMs "smart." Once you've trained a smart LLM, it seems to take a relatively small amount of hand-curated human prose to fine tune it into talking like a human. Unfortunately this article feels like the wishful thinking of someone who is afraid of the changes LLMs are bringing and hasn't done much research.

You can publish an article with a title like this and probably not end up embarrassed. Room temperature and pressure super conductors seem hard enough to find that chances are any given paper claiming to have found one will end up with a more mundane explanation. And I do think the information about the phase change of Cu2S is highly relevant, as it points at a way the original researches my have fooled themselves.

The dismissal of the partial levitation as ferromagnetism, on the other hand, doesn't strike me as especially robust. Ferromagnetism explains the partial levitation of tiny fragments of material generated by people trying to reproduce LK-99. Very light and thin pieces of ferromagnetic material will align themselves with a magnetic field. For example, Andrew McCalip (who streamed himself attempting to reproduce the material in his rocket startup's lab) generated a partially levitating fragment and sent it into USC, where they determined it was ferromagnetic. But bulk pieces of ferromagnetic material will just stick to magnets (or if they are magnetized, they will stick to one side and be unstably repelled from the other).

Ferromagnetism doesn't explain the levitation demonstrated in the videos put out by the original researches, though. Barring fraud, the most likely explanation for that kind of levitation is diamagnetism. The article mentions Derrick van Gennep recreating the partial levitation video with a chunk of pyrolytic graphite (one of the most diamagnetic materials we know of, other than superconductors), supergluing iron filings to a corner of it to anchor it to the magnet. The levitation in that video comes from diamagnetism, not ferromagnetism. LK-99 is primarily made of lead, not graphite, which is 5-10 times denser, so the diamagnetic effect must be at least that much stronger than pure pyrolytic graphite. The thing is, as the rest of the article points out, the supposed main constituents of LK-99 have now been extensively studied, and none of them appear to be especially diamagnetic, so something in those samples the original team recorded must be extremely diamagnetic to make up for it!

Have you looked into Small Step XPBD (introduced in the paper "Small Steps in Physics Simulation ")? It's the most efficient nonlinear dynamics integrator/solver I've come across, and luckily one of the simplest, too! (Keeping in mind that simplest nonlinear solver is a relative metric.) I've been able to simulate very stiff materials like bone by updating the sim at 6000 steps/second. The exact number of steps/second you'll need will depend on both the desired spatial resolution and physical accuracy of your sails, but I wouldn't be surprised if 6000 steps/second is more than sufficient. And computers are fast enough where you could simulate quite a few large, detailed sails at that rate in realtime.

Right, so for his nondeterministic path:

  r(t) = 0              ; t <= T
  r(t) = (1/144)(t-T)^4 ; t >= T

We can see that r''''(T) is either 0 or 1/6, depending on if we go with the top or bottom equation. That does look like some sort of hidden state change, there.

Interestingly, the spherical dome he mentioned (which doesn't yield to this non-determinism) forces all derivatives of r(t) to be continuous ...

> That explains why XPDB moves away from "substepping" the physics

Interestingly, XPBD has moved back to substepping! The relatively recent "Small Steps in Physics Simulation" from Nvidia goes into it, but I can outline the reasoning briefly.

In a physics simulation, there are 2 main sources of error, the integrator and the solver. Breaking that down a bit:

The integrator is an algorithm to numerically integrate the equations of motion. Some possibly familiar integrators are Euler, Verlet and Runge-Kutta. Euler is a simple integrator which has a relatively high error (the error scales linear with timestep size). The most common version of Runge-Kutta is more complex, but scales error with the 4th power of the timestep.

The solver comes into play because the most stable flavors of integrator (so-called implicit or backwards integrators) spit out a nonlinear system of equations you need to solve each physics frame. Solving a nonlinear system to high accuracy is a difficult iterative process with its own zoo of algorithms.

XPBD uses an implicit Euler-esque integrator and a simple, but relatively inefficient, Projected Gauss-Seidel solver. For most games, the linear error from the integrator is ugly but acceptable when running at 60 or even 30 frames a second. Unfortunately, for the solver, you have to spend quite a bit of time iterating to get that error low enough. The big insight from the "Small Steps" paper is that the difficulty of the nonlinear equations spat out by the integrator scales with the square of timestep (more or less -- nonlinear analysis is complicated). So if you double your physics framerate, you only have to spend a quarter of the time per frame in the solver! It turns out generally the best thing to do is actually run a single measly iteration of the solver each physics frame, and just fill your performance budget by increasing your physics frames-per-second. This ends up reducing both integrator and solver errors at no extra cost.

I'm not familiar with the implementation of Quake's physics, but my recollection of the PBD paper was that it was basically a "mathing up" of what was already a fairly common way of handling physics in games. Thomas Jakobsen wrote a very influential paper in 2001 about the character physics in the original Hitman that popularized a lot of the same ideas later presented in the PBD paper.

What is really interesting to me is that later on in 2016 Miles Macklin et al. from Nvidia released the Extended Position Based Dynamics paper (the XPBD referenced in the article), which bridged the gap between hacky-gamey PBD and a principled fully physics-based derivation. The physical derivation was explored and refined further in Primal/Dual Descent Methods for Dynamics.

And finally most interesting was the Small Steps in Physics Simulation paper by the same Nvidia group that showed that a simplified variation of XPBD that got rid of iterative solving in order to increase the physics sim framerate is actually a state of the art dynamics solver. As in, many dynamics problems are currently solved most accurately/efficiently using this overgrown hacky algorithm game programmers came up with to make dragging around corpses look better.

Kind of parallels the whole graphics cards for gamers morphing into GPUs for AI transition, just in a more niche way.

Looks very interesting!

I've been having trouble getting good SIMD performance from WASM. Are there any benchmarks posted anywhere comparing Highway's performance on various native targets vs WASM?

I think your question speaks to something deep and interesting about XPBD.

All classical mechanics sims revolve on some level around "integrating" Newton's second law of motion: F=ma. Force equals mass times acceleration. XPBD constraints correspond directly to forces, and acceleration is the second time derivate of position. So to update positions every frame, which is what we want our physics sim to do, we need to integrate F=ma.

Usually we want to use an integrator in the family of "unconditionally stable" integrators. These integrators are guaranteed not to blow up, no matter what weird, difficult input the user gives to the simulation. In realtime physics sims we generally use one called "Implicit Euler." And Implicit Euler is the worst one! It's the least accurate and it adds huge amounts of artificial damping, but it has one really big thing going for it. It's the most resilient to "under-converged" solutions to the equations of motion.

So, like you pointed out in your question, if you resolve the constraints one after the other, constraints further down the list are likely to violate previous constraints. Most of the time you can mitigate this by running over the list of constraints multiple times, but you'd have to do that many many times for your constraints to perfectly "converge," such that they are all simultaneously satisfied.

The more accurate and energy preserving unconditionally stable integrators, like "Implicit Midpoint," require perfectly converged solutions. If you don't resolve your constraints perfectly, the "unconditionally stable" Implicit Midpoint will explode! But good ol' Implicit Euler is much less up tight. You can give it surprisingly under-converged solutions and it'll keep on trucking. The shortcomings of Implicit Euler are reduced by taking smaller timesteps between frames, so you generally get the best bang for your buck by investing compute time into more frames with a sloppy, non-converging solver, than using a better integrator that forces convergence.

At least that's what it looks like now. There's still tons of active research going on in these areas. Maybe someone will discover a faster solver that makes convergence easier, in which case we'll all switch over to move sophisticated integrators.

Ten Minute Physics is a great resource! Matthias Mueller makes concise demos and explains them really well. (Though I think it would take someone without existing familiarity with the subject matter a lot longer than 10 minutes to digest the results. Lots of rewatching!)

A really interesting results that's come out of Matthias and co.'s research in the last few years that is still percolating its way through the realtime physics community is the so called "small step" technique. Explained at a really high level: integrating a physical system requires solving large sparse systems of nonlinear equations. Traditionally, the equations would be solved once a frame with iterative methods (often with a fixed number of iterations, such as 10 or 20 per frame). It turns out it's massively more efficient for accurate results to just run a single iteration of the solver, but increase the physics framerate by 10 or 20 times (or actually, since there's a tiny bit of overhead to process a physics frame, for equivalent computational load, you can usually only increase the framerate 9-18 times). The intuition here is that even though 1 iteration of the solver is much less accurate than 20, by only taking a small step forward in time the error drift in the physical system is even lower. It's only somewhat handwavy to say solver iterations reduce error at a linear rate, but decreasing physics frame time reduces error at an O(n^2) rate.

While almost all engines have added an option to use the small step technique, one issue slowing down adoption is that it is too accurate! The old way of solving the nonlinear equations once a frame introduced a huge amount of numerical damping. That greatly reduced accuracy, but did serve to stabilize simulations, in a way. With the small step technique, numerical damping is greatly reduced, so intentional physical models of damping need to be added back in and tuned by hand. People aren't used to working this way, so designers are still toggling back to the "large step" method. It's likely once people figure out how to properly use this new technique, you'll see a noticeable uptick in the fidelity of physics in games.