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.

Chris Hecker and Jon Blow (among others) wrote good math and physics content for Game Developer Magazine, but the one I most associate with it is Jeff Lander. He's got copies of the articles he wrote throughout the years hosted on his website here: http://www.darwin3d.com/gamedev.htm

According to Wikipedia, 43% of the sun's energy at the surface of the earth is visible light (https://en.m.wikipedia.org/wiki/Sunlight#Measurement). So just blocking the other wavelengths would help, but I'm not sure it would be a "night and day" difference, so to speak. Daylight is several orders of magnitude brighter than normal indoor lighting, so I bet you could block 80-90% of visible light, as well, and it would still look really bright out while heating the inside significantly less.

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.

Realtime fluid sim is making lots of progress, though full 3D sims still appear to be computationally out of reach, at least for games that aren't focused exclusively on them. Here are some fun fluid sim examples from members of the Ten Minute Physics discord:

https://twitter.com/Michael_Moroz_/status/159507609967093350...

https://twitter.com/MytinoGames/status/1600278137564184579

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.

Thanks for the link.

By my reading, of the 8 incidents reported in the last 10 days for Airbus and Boeing aircraft, 7 were collisions with birds and one was:

> AIRCRAFT LANDED AND POST FLIGHT INSPECTION REVEALED DAMAGE TO RIGHT LANDING GEAR AND FLAPS, HOUSTON, TX.

Nothing about two planes colliding on a runway.

Games generally don't use copy on write, but they do often explicitly pipeline processing to happen across multiple frames (usually by manually copying the necessary data from sim "owned" memory to render "owned" memory, but varying amounts of double buffering is also used). This was especially true after the transition to multi-core but before the many-core regime of today. Transitioning from a single threaded engine, it was easier to run effectively a single-threaded simulation frame and a single-threaded render frame in parallel than to fully multithread everything. Graphics APIs took a while to support multithreading, as well.

These days game programmers have gotten experienced enough to get closer to fully saturating all cores in both the simulation and render steps, so you sometimes no longer see the two full frames of latency there.

> 16.6 (GPU is rendering the previous frame, current frame is cached)

Not entirely sure what this is about. Maybe some sort of triple buffering is being employed as a way to reduce hitches? If you push the engine really close to the 16 ms limit for each stage of your pipeline, sometimes something out of you control, like the OS deciding to do some heavy background work, will push you over your limit. Without the extra buffer, you will miss your vsync and the user will perceive a very disturbing judder.

I believe all the major browser vendors now support the notion of "secure context," where you need to use TLS, <Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp> headers, and maybe a couple more requirements. They say you regain access to high precision timers, as well as SharedArrayBuffers and anything else that got lost during the Spectre/Meltdown mitigations. It appears to work in my limited testing.

This secure context makes it harder to support various random ad networks, but if you're deploying your app via the web and don't need to monetize it by ads, it's a way forward.

Having worked on a fairly popular .io game mostly played by kids on phones and chromebooks over wifi, I concur with everything you said.

1) We updated around 60Hz, and bandwidth was never an issue (everything was binary encoded and many values were hand compressed to the number of bits they needed, but we didn't run any additional compression or ever feel the need to optimize further, and these were games with 100 players in an instance).

2) Probably the biggest key to success was global server placement. That mattered most, and we ended up renting servers in 10-20 regions around the globe to keep latency down for players. I didn't work on this part, but I know it was quite a bit of work, and also very experimental. Physical proximity of servers didn't always translate to lower latencies. Country borders could by surprisingly laggy, in certain cases.

3) This is the one that really shocked me. As I said, players were engaging with the game in almost the worst conditions imaginable, weak chromebooks over wifi and all communication was over websockets (which basically behave like TCP). Still, packet loss was not an issue. We prioritized low-latency over smoothness, so our sever just blasted out the latest state to the client ~60 times a second, and the client would display mostly like a dumb terminal. This is approximately how you're supposed to do it with UDP, but dropped packets and resends are supposed to make it unworkable over TCP. But we just YOLO'd it with TCP and it worked great! I'm sure at some point in the past before internet infrastructure got so good, it would have been a disaster, but seems like, for most players, we've advanced past that.

Now, I know partially this just weeded out the people with bad connections, but I really don't think it was that many. Certainly my own experiments taking my laptop and checking out various wifi spots around town with wireshark indicated that modern infrastructure is just that good.

(Actually, in terms of improving latency, beyond making sure people were playing on local severs, the next biggest thing was just optimizing javascipt. Both the client and server were written in it, and GC stalls were a huge problem. The eventually solution was to rewrite the server to not generate that much garbage in the first place and then just disable the GC. Reboot the server process after ~10 minutes between games. Another big js issue was code getting de/reoptimized continually. The biggest issue was inconsistent numerical literals between float and integer. Once we figured out it was an issue, we became very disciplined about that.)

As a longtime C++ programmer, my view is that that manual memory management is a discipline that you can learn somewhat easily and then you don't spend a lot of time thinking about it.* <-- Big Asterisk

For many applications, allocations fall into two categories: One, temporary allocations that work well with a stack allocator (which is often going to be the main stack where the allocations and deallocations are handled automatically, but sometimes it's useful to have secondary stacks with different lifetimes). And two, larger allocation categories where you can pre-plan access. Many many things can just be allocated statically, others can be allocated from simple pools, and maybe a few things will need complex pools, or even compacting allocators where you end up using smart pointers or smart handles to track them. Once you're used to programming this way, figuring out allocators usually isn't where you spend most of your time. (And as others have said in this thread, if performance is a concern, you spend the same amount of time thinking about this stuff in managed languages, as well.)

* The Big Asterisk is that it's hard to program this way 100% correctly. While it's not hard to get code that works 99.999% of the time for normal usage, it's very hard to make sure nothing in your manually memory managed code is exploitable. Rust, for instance, adds a bunch of language features to fix this issue, and that's one interesting way to go. I do wonder, however, if for many applications it won't turn out that the sandboxing model of something like WASM is more productive. You can still code everything in good ol' C++, but the worst an exploiter can do is hit the edge of the sandbox and crash your application, instead of pwning the user's system.

Throwing in my data: for physics simulation code, WASM vs native was identical, provided the native code was compiled with automatic SIMD optimizations disabled. On the one hand, that speaks well of the idea of web assembly, on the other, disabling SIMD is highly artificial. It's good to see basic SIMD being made standard, though the 256-bit wide SIMD instructions are still being finalized, and those will be necessary to really have a chance at evening out performance vs. native.

Nvidia DLSS is an important part of how they achieved 30Hz at 4k resolution, but that's more of a shading assist and doesn't affect the animation. The facial animation will be compressed with Ziva's ML solution.

The geometry is fully pre-baked, but wrinkle and blood details respond in realtime to the pre-baked geometry.

Unity recently acquired Ziva, which specializes in the detailed animation of humans and other animals. They were known for their (not realtime) physics-based solutions, but now they have an ML model for faces, apparently. As far as I know, it's still in beta and not widely available. Unity says they will re-release this demo with the Ziva face in a matter of weeks and the quality will be even higher. And possibly allowing interactivity as well?? I guess we'll see in a few weeks.

This is indeed rendered in realtime, but one thing to note is it's a "4D" capture, more-or-less meaning each frame of the animation is its own asset. This makes it possible to reproduce subtle physics like the lips sticking together slightly when the actor opens her mouth. The amount of storage space, alone, makes this impractical for anything other than demos. Unity claims they will be able to achieve this level of fidelity using a deep learning-based compression that will allow stuff like this to appear in game cutscenes, but all the movements will still be pre-baked. The only interaction possible will be moving the camera. At that point the technology will be very useful, but it's still a ways away from having such a realistic character that can react to you dynamically.

(Though whether that's just a couple years of software technology progress, or a decade+ for hardware progress, who can say?)

I wonder if that's actually true. I mean, is the value of a Rolex retained in a world with true perfect replicas (like we can get with digital goods)? Right now, a good fake Rolex is still hundreds of dollars, and if someone does spot the difference you just look like a poser who's down $500, so why bother.

The existence of the fashion cycle feels like an argument against NFTs. Yes, people like to signal with exclusive things, so influencers seek out new, exclusive fashions. Most of the time these styles are fairly easy to copy, though, and so the followers start wearing them and the influencers need to move on to the next thing. Eventually, anyone left wearing the old fashion looks kind of laughable.

Yes, the actual NFT token always remains exclusive, but is that really something you can signal with on a human level? Or do too many right clickers eventually cause bored apes to go out of style and become laughable?

Seems like the page background and text invert for OS dark mode, but the drawings don't.

I think your first point gets to the heart of it. Yes, I'd be happy to be able to live to 5000, but there are also plenty of other people in the world I'm truly glad don't get to live much past 90. Until we figure out a societal system capable of reining in the extreme will to power present in some of the population, the dragon taking those people out makes me feel like he's on my side, even if I eventually have to pay the price, as well.

So, it's not that I don't wish for society to eventually conquer the dragon of death, but not until we conquer some of the even more pernicious social dragons that are currently being held in check by it.

It's still an interesting paper, but I was disappointed they were "just" concatenating an imagine generator with a language model. I'm really excited for when someone figures out concurrently trained models, say, alternating between training passes of GPT-3 and iGPT, such that the very same attention layers deal with both language and and visual/spatial conceptualization. I expect common sense reasoning capabilities to take a huge leap, at that point.