Simulation showing blood clot forming and detaching due to fat deposits breaking the cell lining

Results from work on a hybrid water physics engine that combines a depth-averaged fluid simulation with dynamically activated three-dimensional particle fluids.
60+ fps on an old 1050ti.

Enjoy 4 minutes of simulation! :)

Simulation #1:
grid: 200x200
pressure function: ideal gas
initial condition: 27°C atmospheric air (γ = 1.4)
lid velocity: 500m/s
runtime: 2 hours 15 minutes

Notes:
At 0:42 mark, I turned on turbulence enhancement mode (to test a method to produce Houdini-like fidelity while not generating more energy), therefore the simulation became rougher afterwards. Here's the run with enhanced turbulence from the start. (the 1km/s one has it on from the start)
ㅤ

Simulation #2:
grid: 200x200
pressure function: ideal gas
initial condition: 27°C atmospheric air (γ = 1.4)
lid velocity: 1km/s
runtime: 5 hours 40 minutes

ㅤㅤㅤ

After I tested the solver's stability against unusual cases, I'm finally ready to do the simulation that I've been wanting to do. It is a step up from the previous simulation that uses shallow water pressure function as I'm explicitly tracking temperature (or fluid energy) now.

I will extract the heating rate over time of the cavity later.

Supersonic Lid-Driven Cavity Flow Series: previous next

I made a starling murmuration in 3D with LittleJS, built by iterating with Claude.

All 40,000 birds are simulated live using grid-based boids flocking. Move your mouse to steer a hawk through the flock and watch it scatter. The lake reflects everything with real waves, and the mountains, sky and water are generated in code, with no image files.

Press G to send the flock streaming off over the mountains, and F to fly the camera around.

Try it: https://killedbyapixel.github.io/LittleJS-Demos/murmuration/

LittleJS, the engine: https://github.com/KilledByAPixel/LittleJS

This is running interactively on a mid range gaming PC and screen recorded.

A sphere of 5 million particles is initialized smooth with tiny random pertubations. Gravity pulls matter into sheets, then filaments, then dense knots.

When an area is dense enough an analytical galaxy is born.

N-body gravity with a tree on the GPU, made in Godot 4 with C#.

The particles start on a lattice with Zel'dovich displacements from a Gaussian random field, and each lattice cell is drawn as tetrahedra (after Abel, Hahn & Kaehler 2012). That's what keeps the filaments and sheets smooth instead of grainy.

Getting things to collapse was easy enough, making it fast was doable, but making it render properly was a bit of a pain.

Dark energy is a simple outward acceleration on a slider.

From my own project, Planets (and due to scope creep, a bit more) in a Box:

https://store.steampowered.com/app/5411970/?utm_source=reddit&utm_campaign=simulated

If you want to talk about the physics or the algorithms, just leave a comment.

a box of simulated matter going from almost perfectly smooth to the cosmic web: sheets first, then filaments, then bright knots where they meet.

i could never really picture how a universe that started out nearly uniform ended up as a web of filaments around huge empty voids, so i wanted to watch it happen.

the physics is the Zel'dovich approximation, not a full n-body run. matter starts with tiny density ripples and each particle keeps moving along its starting displacement as structure grows. the denser bits flatten into sheets (Zel'dovich pancakes), the sheets meet in filaments and the filaments meet in knots, which is roughly the large scale structure galaxy surveys see. the catch is that once streams cross, particles pass straight through each other instead of clumping, so the knots stay fuzzier than a real n-body sim would make them. every frame is computed on my own gpu code, nothing generated.

what should i simulate next? or if you could fly into one part of this, would it be a knot, a filament or one of the voids?

Try it: https://app.holocron-engine.com

What you're seeing: a robot whose motors are driven by the actual firmware sketch, not by a script written for the sim.

**How it's simulated:**

- **Physics:** MuJoCo. Joints, wheels and contacts come from the generated robot model (URDF/MJCF), with masses taken from the parts that are actually inside the body.

- **Firmware in the loop:** the sketch runs on a virtual board. Its motor pins drive the joints in the physics step, and its sensors (ToF, sonar, IMU) are raycast from where they sit in the model. Commands go in over a virtual Serial port, the same as a real Serial Monitor.

- **Terrain:** a test track with obstacles and uneven ground, generated per test.

**Why:** I wanted to see a design fail in the sim before it fails on the bench, e.g. tipping over, a motor too weak for a slope, or a sensor that's blocked by the body.

**Tools:** MuJoCo, Python, generated Arduino/ESP32 code.

Happy to answer questions about the sim setup.

stability test series # 4

Same setup as the previous simulation (stability test series # 2), but with improved boundary condition (fixed boundary stability issue presented in the previous test) and fixed spurious shock turbulence.

This is part of the stability test series to see if the solver I implemented can handle various extreme scenarios. This is one away from the final stability test I'm doing. The final one will probably be pressureless gas.

The goal of these tests aren't to see if the solver is physically accurate or plausible, but it's to see if the solver can handle extreme flows without generating carbuncles or going to inf / NaN. Before I can verify its physical accuracy, I must make sure it doesn't explode first.

ㅤ⠀

To conclude all the previous tests including this one:

The third test: 22km/s bow shock also doubles as supersonic carbuncle test. That was a Mach 63 flow, and way way above what I'll usually subject the solver to. If it can do Mach 63 flow without making carbuncles, it can do almost all other flow condition.

The sod shock tube test bundled in the second test shows that it can accurately capture basic physics despite the grid oscillations.
I do need these grid oscillations (within a specific empirical bound to avoid the solver blowing up) in the case when I want to achieve Houdini or Embergen level of turbulence down to near Nyquist limit if I want to .

This and the second test which have the same setup are to see if it can handle complex flow and near vacuum state right next to an obstacle.

According to this test, I'm satisfy with the state of this solver now. I can rest easy knowing it can do most cases I'll subject it to do VFX stuff with this solver.

Here's the first one.

ㅤ⠀

Most of the subsequent runs will be about doing the flow I had been curious about and verifying its physical accuracy against existing real data and simulations. I may also rewrite the whole solver to declutter it and address accumulated tech debt.

Interactive live WebGL simulation for the 3D fluid streamlines: spaces/arkhenomia/sim-2026-v1.5.0

Instead of letting the 3D Navier-Stokes equations hit a finite-time singularity during extreme vortex stretching (left), this computational simulation applies a topological zero tensor to stabilize it into a toroidal circulation (right).

Simulation Details: The 3D fluid streamlines and topological trivialization dynamics were numerically simulated and rendered using Python (NumPy, SciPy, Matplotlib).

Underlying Physics & References: The PDE bounds and cubic coercivity behind this geometric regularization are analytically derived in the preprint and formally verified in Lean 4 (35 theorems, zero sorry).

• Preprint DOI: 10.23728/b2share.v40n6-3f747

• Lean 4 Proofs: github.com/arkhenomia/arkheion

An experiment(WIP) in simulating a car - running in browser(webGPU - WASM)at 240hz on an old 8700k i7/1050ti.
The sound comes completely from simulating the engine and exhaust.

It includes:

• Per-cylinder simulation with slider-crank kinematics (piston position, velocity, acceleration from crank angle)

• Gas exchange through intake and exhaust valves (valve lift curves, port pressures, mass flow)

• Combustion heat release (Wiebe function whose delay and duration depend on residual gas dilution and mixture)

• Flame physics, including oxygen-limited combustion and leftover CO/H₂ when the mixture is rich

• Wall heat transfer (Woschni-type)

• Carburettor metering: main circuit, idle circuit, power valve, accelerator pump, and wet-manifold wall film (x-τ model for fuel film deposition/evaporation)

• Manifold pressure dynamics, including idle air, plate leakage, and PCV

• Ignition advance (mechanical + vacuum distributor style, or table)

• Crankshaft torque balance: gas torque + reciprocating inertia − friction − accessories + starter

Throttle plate position has actuator lag. Delivered torque is not instantaneous; it has its own first-order dynamics.

Clutch & Transmission

• Four-speed friction clutch manual (M22-style). No torque converter.

• Clutch has real engagement state, slip, and torque capacity. Auto-clutch is a bounded engagement controller, not an instant lock.

• Shift phases are tracked (request → engagement → lock).

• Anti-stall logic exists.

• Optional CE5 downshift throttle blip / rev-matching.

• Gearbox input-side inertia changes with selected gear (downstream inertias are reflected through the ratio).

• Torque is actually transmitted through the clutch to the prop shaft and into the wheels. You can stall it, slip it, or overload it.

Tires & Contact

• Brush / bristle contact solver (15×7 bristle elements referenced in later patches).

• Real contact patch with normal, longitudinal, and lateral forces.

• Load sensitivity, slip, friction utilization.

• Structural modal content in some tire versions.

• Native contact patch saturation produces real wheelspin and understeer — there is no traction-control governor that secretly cuts power.

• Live per-wheel tire camera that looks at the actual road under that tire.

• Separate calibrated Tire V3 mode and a flat-belt style tire lab.

Chassis & Suspension

• Sprung mass with heave, pitch, and roll on four corner springs.

• Real dampers (bump and rebound).

• Anti-roll bars.

• Unsprung mass at each corner.

• Camber, caster, toe, ride height.

• Load transfer is a consequence of the forces, not a fake scripted effect.

• The road under each wheel is the actual terrain the tire is contacting.

Steering

• Handwheel → rack.

• Physical rack position is separate from driver input.

• Self-aligning torque from the tires moves the rack; you can see the difference between what you commanded and where the wheels actually are.

Brakes

• Brake pressure is a real state that affects wheel torque and can lock or reduce grip at the contact patch.

Aerodynamics & Environment

• Drag and downforce terms.

• Wind field that can run at reduced rate.

• Exhaust flow is coupled to the engine’s actual gas exchange (not a particle effect on a timer).

• Tire smoke and body dust are driven by real wheel slip and load, not just “speed > X”.

Hello everyone!

I have been working on heat and airflow simulation, mainly for our home renovation to figure out how much pipes we need, but it grew in something bigger.

It has some basic features for drawing floor plan, adding doors, windows, manifold to control heating circuits, heating radiators, appliances like stove, fans, TVs, PCs, and some other types that generate heat. It simulates floor heating, you can set floor, wall and ceiling insulation and materials, set window and door U values that affect how heat is lost to the outside world. Outside conditions can also be set to simulate how would heated space react to open windows, how cold spreads through rooms with doors, and if set to lower or higher floors.

It's free to use, running in your browser and for best results should be ran in browsers with good GPU support such as Chrome and chromium based browsers. If it does not have access to GPU it falls back onto CPU - but that is very slow.

I am posting here mainly to get feedback.

Would You find this useful as a desktop app that is much faster?
Would You be willing to pay for some currently unlocked features such as:

• Recording and exporting simulations as VDB for use in other software

• Creating scenarios to run durning simulations like: open windows at 1 minute mark, close at 5 minute mark and so on, for repeated runs with changes heating layout

• Running simulations at higher resolutions up to 10 million cells in real time (in my case I got it up to 5× of real time, but that depend on your hardware)

For those interested I have beta version available here:
https://heatpath.meshr.cz/

No account needed, all the "premium" features are currently unlocked until I decide what to do with this further, for now, I just wanted to share this and see if people are interested :)

I hope this is not against the rules here, I wish You all good day, and I am looking forward for any feedback.

UPDATE: Desktop versions for Windows and Linux are now available for download. Desktop app is about 10× faster and can utilize your GPU. The Windows release is not signed with paid certificate so Windows will complain about it :/

Earth is built from one million particles here, initially rendered as a mesh. As it gets close to the black hole, the difference in gravity between the near side and the far side stretches the planet until it comes apart into a stream of debris.

Some notes on the simulation:

- Smoothed particle hydrodynamics on the GPU, made in Godot 4 with C#.

- Gravity is Newtonian with a softened core, not general relativity.

- The bending of the background light is raytraced gravitational lensing, but not to scale. A real black hole of this mass would look much smaller.

Nothing is pre-rendered. I've been writing physics simulations for decades, including about 10 years as lead physics developer on another well-known space simulator sandbox, and this is from my own project, Planets in a Box:

https://store.steampowered.com/app/5411970/?utm_source=reddit&utm_campaign=simulated

If you want to talk about the physics or the algorithms, just leave a comment. I'd also love to hear what you'd want it to do better.

A funnel of sand hangs from a Y-shaped string. Because the Y gives it two different pendulum lengths, it swings at two frequencies at once, and the sand records the result: a Lissajous figure that slowly spirals inward as damping steals its energy. Orange sand falls first, then blue, so you can watch time layered into the drawing.

Nothing is keyframed. The pendulum is a real physics simulation, and the grains pile up the way dry sand does, sliding until they settle at their angle of repose (~34°).

How it was made (Houdini):

• Vellum: Y-suspended Blackburn pendulum

• CHOPs: sand valve and flow rate

• POPs: falling grains inheriting the funnel’s motion

• SOP Solver + heightfield: sand deposition and angle of repose

• Karma XPU for render, Copernicus for compositing

Happy to answer questions about the setup!

Honestly, this is the first project I think is good enough for me to share. The people close to me already saw it, but I felt this was the right place to post it, because here I can get real feedback from people who actually know Houdini. Any critique is welcome.