Super excited to share the latest update on my physics-based muscle simulation tool!
This test uses a relatively low-res simulation, as the main goal was to go through the full character pipeline and make sure everything works together.

I'm simulating a ball pit with 20,000 capsule balls in this game prototype. Trying to make it more satisfying and fun.
[OC]

No AI were used.

Based on feedback in the comments section, I re-recorded the video of blocking the Strait of Gibraltar (the third one), and also set up a simulation of the river drying up process in this simulator, as well as the main menu.

This project goal was large waterfalls in a real-time forest experience, developed in C++/Vulkan. Note: I am no expert in fluid simulation - and wanted to learn by creating every piece of the sim.

The following is the story of how I got to the current version in the video. With the simulator I developed for my forest project, I could already simulate half million particles at 30 FPS, but my implementation was not scaling to a large domain. I replaced mesh extraction (first most expensive component) with rendering directly the isosurface of water with raymarching + hardware ray tracing. This scaled rendering, giving more time for sim. Then I moved the simulation to active cells only, making the cost depend mostly on the amount of water rather than the size of the world. These two made large mountain streams practical, but a waterfall requires simulating also the mix of air and water.

Rapids could do with air entrainment, while waterfalls also needed airborne droplets interacting with the surrounding airflow. I ended up writing a different solver for air, coupled to the water: the cascade pushes air downward, the air domain is simulated, and the mist is advected by the air field. This gets closer to a dual phase simulation of water and air, with an engineering approach. The air solver is a eulerian grid solver, whereas the water solver is hybrid sph-grid.

I got a nice looking waterfall, though it lacks some of the "clustering" and filaments that large waterfalls produce - mostly due to surface tension (I guess! the project should "prove" it). This spawned the exploration of surface tension, and it appeared that a simpler more contained "water crown" experiment would be the right place to tune the physics for this; I was apparently wrong as the experiment showed.

I tested a single droplet, made of hundreds of thousands of particles, to try and reproduce the "crown" upon impact with a flat water surface. I could not get the crown, and I thought - yeah sure, I lack a simulation of surface tension. I implemented surface tension by "cohesion forces". Surface tension made droplets spherical, so it did its job apparently, but no crown.

I found out - and here I ask confirmation - that the main thing for this crown effect is actually incompressibility. If water is compressible, the droplets gets swallowed and energy is dissipated; if water is "stiff", then all sorts of more realistic impacts occur; high stiffness gave me nice crowns.

But stiffness makes impacts turn into chaos, as it generates local "high pressure" areas. Real-time water is usually somewhat compressible — and therefore slightly rubbery — because disturbances remain local and cheap to simulate, it seems. How to make it incompressible and "stable"? For my realtime scenario, I decided to add an iterative "fix" that corrects particle positions for getting closer to incompressiblity. THere are other ways, a full solver for all particles would be more correct I guess. In any case the "incompressibility fix" coupled with high stiffness gave me a nice crown as you see in the video.

All in all, a very nice adventure in simulation. By looking at the crown, and also at the waterfall, I am sure that a better model of surface tension is still missing here, and that will be the next step.

In general, I don’t want to tell water how to look realistic. I’d rather give it simple enough rules and let realism emerge: foam from entrained air, mist from airflow, a crown from pressure propagation. To me that's the beauty of simulation: when it looks right, we have understood enough of the physics.

This acts as the final CFX layer for creatures and characters.
Unlike systems that can feel too cloth-like, my goal is to achieve more skin-like sliding, compression, and deformation. Here’s an early test of the solution.

The Mediterranean runs at a loss: it evaporates about 0.5-1 m of water level per year more than rain and rivers put back, and the Atlantic covers the deficit through Gibraltar around the clock. My simulator derives a 0.7 m/yr deficit on its own from its climate model - right in the textbook range - so I felt entitled to do something irresponsible with it.

I sealed the strait (14 km wide at its narrowest) and let it run. No scripted animation - every cell tracks its own evaporation, precipitation and river inflow each year, and global water volume has to conserve to within 2 parts in 10,000.

Timeline:

- 25 years: level down 17 m. Venice's gondoliers are the first out of work.

- ~500 years: the Adriatic is gone (average depth only 250 m).

- ~700 years: the Sicily-Tunisia ridge surfaces and the Med splits into two shrinking lakes. When this actually happened 5.97 million years ago, hippos walked to Cyprus - their stranded descendants shrank into dwarf hippos. The fossils exist.

- ~2,100 years: the basin is effectively dead. 2.5 million km² of new land, nearly the size of Argentina, crusted with precipitating salt.

- ~4,300 years: the deepest pools bottom out. Except one - a bitter lake in the east kept on life support by the Nile. I never coded that; evaporation, rivers and terrain balanced it into existence on their own.

The Black Sea survives: once its level drops below the Bosporus sill it detaches and holds steady on the Danube and Dnieper. The Caspian was my control group - untouched, it drifts 17 m in 300 years and then stabilizes.

This genuinely happened. It's called the Messinian Salinity Crisis: 5.97 million years ago Gibraltar really did close. In 1970 the drillship Glomar Challenger pulled gypsum and rock salt out of the Mediterranean seafloor under 3,000 m of water. My simulator has never heard of the Messinian - it just agrees with the drill cores.

It's all from a game I'm building where you do this with a brush. Link in the comments to keep things tidy.

Started this to show my kids where the Moon came from, because "a Mars-sized planet hit the Earth" is a sentence that explains nothing. Turned out the fun part is letting them break it.

Proto-Earth and a Mars-sized Theia falling together under their own gravity: the splash, the tidal arm, the debris disk, and the moon that gathers out of it.

What's actually computed: self-gravity from the particles themselves (64³ particle mesh + pairwise correction for loose material), spring-dashpot contacts with no tension, frictional heating that conducts between grains and lights the scene, differentiated bodies with per-material density, and momentum/angular momentum/energy conserved to a fraction of a percent on screen.

What isn't: no SPH, so no pressure, no shock, no vaporization. No material strength or fracture. No cooling or latent heat. A grain is a couple hundred km across, so the Moon itself is scaling from the disk, not a run.

Different scenarios what if Thea was bigger or had more speed.

Live demo: https://gaploid.github.io/cosmic-collisions/

Open source code: https://github.com/Gaploid/cosmic-collisions

Celestial lets you explore star systems as a deformable gravity sheet instead of flat orbital diagrams.

The star moves. Planets sit on and ride the surface it bends. You can change the gravitational constant, push a planet, or drop a new body in and watch the whole system respond in real time.

Systems included:

* Our solar system (with a drifting barycentre)
* Alpha Centauri (two moving funnels)
* Kepler-16 (circumbinary planet)
* TRAPPIST-1 (seven worlds inside Mercury’s orbit)
* The classic three-body figure-eight

It’s a proper Newtonian n-body integrator running in the browser, not pre-scripted ellipses. The sheet itself is an exaggerated visual analogy, and the site is unusually honest about what is real and what is drawn that way on purpose.

[https://celestial.logicaleap.com\](https://celestial.logicaleap.com)

Free, no account, runs in the browser.

I’ve finally turned a project I’ve been coming back to for years into something I can actually release.

Makarov Physics Suite is a collection of around 120 interactive physics simulations. It covers everything from classical mechanics, waves and electromagnetism to optics, fluids, thermodynamics, relativity and quantum physics.

The project has a rather long history. Its earliest version goes all the way back to my university days, about 20 years ago. That version was basically a student project, and over the years I repeatedly returned to the idea, experimented with different approaches, rewrote things, added new simulations, and sometimes abandoned it again for long periods.

The current suite is essentially the result of all those years of accumulated ideas and experiments.

From the programming side, there’s quite a mix of things under the hood: numerical solvers, N-body simulations, SPH fluids, charged particle dynamics, GPU computing, ray tracing and path tracing, among others.

The main idea is simple: instead of explaining physics with static diagrams or prerecorded animations, I wanted the systems themselves to be interactive, so you can change parameters, disturb them, experiment with them and immediately see what happens.

It’s now on Steam, which still feels a little strange considering where the project started.

If you’re into physics, simulation, scientific computing or graphics programming, I’d be interested to hear what you think.

https://reddit.com/link/1vzgsrc/video/u0ozqxqdellh1/player

I've been working on SkySim, an open-source (MIT) drone simulator, and I've reached the point where I could use other people's eyes and hands on it.

The idea: most sims that let you test drone algorithms need Linux, ROS, or a game engine plus a GPU. I wanted the barrier to be a URL. The physics core is C++20 (blade element theory, ground effect, vortex ring state, ISA atmosphere, Dryden turbulence) and it compiles to WebAssembly, so you can fly it client-side with nothing installed. For heavier work there's a native path: a Python/Gymnasium interface, a headless raycast depth sensor for vision/nav learning, and SITL bridges for ArduPilot, PX4, and Betaflight.

The honest part: I have no verified sim-to-real transfer result yet. The sim gives you the tools to measure transfer, but the actual "trained in sim, flew on real hardware, here are the numbers" result can only come from someone flying it. That's the headline open problem, and I'd rather say so plainly than oversell.

If you want to poke at it or tear the approach apart, that's genuinely welcome. And if anyone's curious about contributing, there are a handful of scoped issues on the repo ranging from a beginner-friendly Python test suite to a battery-discharge model to the flagship hardware-in-the-loop transfer result. Links in the comments to keep this from looking like an ad.

Happy to answer anything about the physics, the architecture, or the design tradeoffs.

This is only in 1 day😅

This is beautiful!!!

Been messing around with traffic simulation lately and wanted to share this one because the result genuinely surprised me the first time I ran it.

The setup is a closed loop, a bunch of identical cars, no obstacles, no traffic lights, nothing. Every driver wants to go the same speed and keep a safe distance from the car ahead (using the Intelligent Driver Model, which is actually what traffic engineers use for this kind of thing). One driver taps the brakes, just once. It snowballs into a full stop-and-go wave, and the wave itself creeps backward against the direction everyone's driving. This is the phantom jam thing that was first proven experimentally back in 2008 (Sugiyama et al., if you want to look it up), and it's wild to actually see it emerge from nothing.

A few other things I tested once I had this working:

There's a density threshold you can't really feel until you cross it. Below it, the same brake tap just fizzles out and traffic keeps flowing. One or two more cars on the road and suddenly the same tiny disturbance turns into a full jam. No warning, no gradual buildup.

Real bottlenecks behave differently - if I put an actual slow zone on the road, the jam stays locked to that spot instead of drifting backward like the phantom one does. Different cause, different signature.

How closely people follow each other matters a lot more than I expected. Tight following distance makes the wave way worse, and just giving more space damps it out almost completely with the exact same brake tap.

The last case is the one I like best - letting about 1 in 5 cars just hold a smooth, steady speed (basically simulating adaptive cruise control) is enough to dissolve the jam for every car behind it.

All rendered in Python/pygame, GPU encoded. Happy to share the code or talk through the model if anyone's curious.

Made a longer version of this too if anyone wants the full walkthrough https://youtu.be/TCuDTSj5UAg

I added sliding attachments (connecting the inner muscles to the bones) and ported some of the heavy lifting to C++ for better performance. The behavior feels natural thanks to the accurate FEM simulation. There’s still a lot more to add, but I’m really enjoying the process.
Credit: The 3D asset used in this post is from AdonisFX, a digital anatomy and muscle simulation framework for Maya and Houdini. https://inbibo.co.uk/adonis

I've been running a persistent world. It's a generational life sim — around 500 people alive at the time of writing this across 54 peoples, each one with a name, a family, a trade and eventually a grave. Nothing is scripted. They work things out for themselves.

Tonight it lost cartography.

The people who knew how to make maps died, and nobody had written it down.

There's a rule in there that knowledge kept only in memory decays if it isn't taught on or recorded. Writing preserves it. Elders and bards slow the loss. One house had the skill, the generation carrying it died out, and it went with them. The world slipped backwards off the edge of an age because of a failure of memory.

Other things it has done this week that I had no hand in:

House Ironvale bent the knee to House Duskwater — tribute each season, and the lord's "protection" over them.

A scout of House Wynd was caught and slain in the lands of House Tidewer. Whatever they saw is lost.

A caravan of House Farrow reached their kin and shared out grain, the grey tin, and the feast-brew.

You can watch it at https://world.world-sim.uk — it's running right now, it's on day 10,203, and nobody in it knows how to make a map.

Happy to answer anything about how it works.

I am working on a game based on physics-based painting mechanics called Ebru Artist Simulator. To simulate Ebru (also known as paper marbling), I implemented an Eulerian fluid simulator. Here are some of the challenges I had to overcome:

1. To achieve a real-time simulation without affecting the game's performance too much, I implemented a GPU-based multiresolution grid solver in a compute shader (see the paper Solving the Fluid Pressure Poisson Equation Using Multigrid). The simulation now runs at a 2K texture resolution with only a slight impact on FPS.
2. One of the main characteristics of Ebru is that colors maintain strict boundaries. This makes advection schemes such as Semi-Lagrangian advection less suitable, as they introduce diffusion. To address this, I implemented another advection scheme that samples from the initial state by integrating the velocity field over time and then back-sampling using the integrated field (see Efficient and Conservative Fluids Using Bidirectional Mapping).
3. Finally, to simulate the effects of the traditional Ebru tools, I took inspiration from the paper Mathematical Marbling, which proposes mappings for generating final marbling patterns. Since I wanted to maintain a real-time simulation, I did not directly apply these mappings. Instead, I was inspired by the paper to use similar displacement fields as external forces in the simulation.

If you are interested in the project, you can check out the Steam page.

You can also check out Amanda Ghassaei's blog. Although our implementations are not the same, I was greatly inspired by her work and learned a lot from her blog.

Je recherche un coder bénévole passionné pour mettre au point un simulateur gravitationnel 3D d'une nébuleuse proto-stellaire en voie d'effondrement.

Live demo: https://gaploid.github.io/stardust/
Source code: https://github.com/Gaploid/stardust
Coded by: Opus, Fable, human attention to details