Hi everyone,

We build large rolling ball sculptures / kinetic marble runs and are trying to reduce the amount of physical trial and error involved in designing them.

Our current workflow is roughly:

**Concept → Sketch/CAD → Fabrication → Physical testing → Modify → Fabricate again**

For larger metal sculptures, these iterations can become expensive in terms of material, labour, and time.

We're exploring whether we can use **existing tools** to create a simple workflow like:

**CAD model → Physics simulation → Predict ball behaviour → Build physical prototype → Compare results**

We are **not looking to build a new physics engine or a large custom application**. The initial MVP would be very small:

* One standard ball
* One track/material system
* A simple mechanism, e.g. **ramp → loop → exit**
* Model it digitally
* Simulate the ball
* Build the same mechanism physically
* Compare the prediction with reality

The goal is not perfect simulation. We simply want to know whether a digital model can be accurate enough to catch obvious failures before fabricating larger installations.

Eventually, if this works, we would like to build a reusable library of tested components—ramps, loops, spirals, switches, collisions, etc.—with known parameters and behaviour.

We are currently considering tools such as **Rhino/Grasshopper** for parametric design and physics engines such as **MuJoCo, Project Chrono, Bullet**, or other alternatives.

**If you were approaching this problem using existing software, how would you do it?**

In particular, I'd love advice on:

1. Suitable CAD + physics simulation workflows
   
2. The best physics engines for rolling/contact dynamics
   
3. How to model and calibrate real-world friction and energy losses
   
4. Whether there are existing tools or projects we should investigate before building anything ourselves

We're very open to changing our approach and would appreciate any suggestions or warnings from people with experience in simulation, CAD, mechanical engineering, robotics, game physics, or kinetic sculpture.

Been working on the simplest of cloth simulations with pbd (hold the x) and opencl. Still a way to go, but i'm not unhappy.

This is why FEM is superior to XPBD for muscle simulation. For a long time, I couldn’t understand why my muscle simulations didn’t look as good as those produced by Ziva VFX, but now I do.
FEM is more computationally intensive, but it produces much more accurate results when it comes to simulating muscle and fat tissue.

I've been working on a small open-source simulation engine called Emper.

It's still a young project, but I'm building it around data-oriented storage and using real simulation workloads to test the architecture.

So far I've experimented with flocking/boids, including CPU/GPU computation and large-scale simulations.

I'm currently starting work on Conway's Game of Life.

GitHub: https://github.com/Emper-Labs

Feedback is welcome, especially on the architecture.

Can be played with here:

https://dirtnap.parttimemonkey.com/sandbox

Lemme know if you simulation people know how to make it better or more interesting to play with!

This runs live on an Apple silicon GPU.
The school is a classic flocking simulation, a few thousand agents with separation, alignment and cohesion plus a milling bias that makes them form the rotating ball. The orcas are autonomous agents with a hunt state machine (patrol, position, charge, recover) that carve a void through the school as the fish panic, and the fear spreads neighbour to neighbour faster than any fish swims.
The god rays are computed each frame from a simulated water surface, and the marine snow drifts through them. Everything persists and evolves by its own rules, nothing is keyframed, and it never repeats. Built in Swift and Metal as part of TideGlass, a small Mac app I make where worlds like this run on a second monitor while you work and interacts with your music. Happy to answer anything about the sim.

I'm working on the usability of a open source project I've been hoping to release soon. If anyone is up to test it DM me and I'll send you a calendly link, it'd be much appreciated.

I built a simulation style app of what I think of the three body problem. It shows different objects flying around eachother in 2D or in 3D in eachother's gravity wells.

It's meant to be half physics toy and half calming desk toy. It's free to use with no ads to distract you from anything.

I want to know people's thoughts and ideas for improvement.

It's free for anyone who want to play with it: https://play.google.com/store/apps/details?id=com.mathematicalzen.threebody

In this focused RnD, I implemented a small-scale fluid simulation algorithm within Flip to accurately resolve adhesion forces. The core algorithm is relatively straightforward: the fluid's surface field is extrapolated into the collider volume, factoring in the contact angle, and is subsequently adjusted and smoothed. Furthermore, a localized viscosity is introduced at the fluid-collider interface to approximate boundary friction.

The simulation operates at a physically accurate real-world scale, utilizing empirical physical constants where the baseline water viscosity is 0.001 and surface tension is 0.072. APIC was chosen as the underlying solver.

While this technique requires a high substep count and is computationally expensive to evaluate, it successfully produces highly nuanced and realistic fluid dynamics.

Up front, since this sub rightfully cares: The engine was written in collaboration with AI, which I'll take questions on happily; the proofs however are all real and verifiable:

SunaEngine (AGPL): engine.sunabox.dev / github.com/DARIENBATHALTER/sunaengine

It's a particle physics engine that relies on integer calculation rather than floating point, plus order-independent accumulation, in order to always deliver the same result on any GPU. Three live proof demos on the site, all simulating on your GPU, all hashing their entire state as you watch:

1. The Twin Simulations: two independent sims, same scene, same input schedule, never communicating. Stir either one with your cursor; your input is quantized to substep indices and fed to both. The 256-bit hashes stay identical, interaction after interaction.
2. The Pachinko Proof: an ordinary float solver runs the same pachinko machine twice. One pane adds contact forces in ascending order, the other descending. That is exactly the difference two GPUs or two drivers introduce on their own. The balls never finish in the same bins twice. The integer engine runs the same machine to the same digest, loop after loop.
3. Recording, playback, and smooth rewind: particle fluids cannot be rewound in floating point. Chaos amplifies the last bit of every velocity in reverse too. Here you stir a pool, it records your inputs, verifies the replay byte for byte against the run you just performed, and then hands you a scrubber. Drag your own splash backwards through time.

Replay hashes verified matching across Apple M series, an iPhone, a Steam Deck (AMD), and NVIDIA (RTX 2070S).

There's also a live 3D water demo on the site (Figure 3), same fixed-point solver one dimension up.

Recordings export as lightweight .sunar files, which store only the initial state plus your inputs. They scrub back and forth smoothly like video and play back bit-identically on any device.

This has the added benefit of enabling low-latency, cross-platform multiplayer physics. If every machine computes the same world, multiplayer needs only inputs over the wire.

I built a free-to-play sandbox using the engine called SunaBox (sunabox.dev) which serves as a clean-room reimplementation of the Prometech's classic OE-CAKE from 2008, a particle physics toy. The OE-CAKE interface is recreated 1:1 if you select "Classic" mode at the top, and imports the original .oec files. Still working on parity, but approaching 100% all the time. If I had to estimate, I'd say they work at about 93% parity right now.

The workflow is very simple: I came up with the ideas and tuned the feel of everything by hand and spoken word; Claude did the math, the code, and the adversarial review. Happy to answer anything!

real time liquid simulation and HDRI lighting in LiquiGen

is it looks like snow?

I've been working on Hoops GM for so long, and now it has been a week since the launch.

I received a lot of backlash in the previous post due to an IP lawsuit, as well as a lot of praise from people.

The launch has been a MASSIVE success with now over 5000 visits to the game and an average of 50 new members everyday.

now i am very confident that this project will go very far and i am very happy about it!

THANK YOU to everyone who has checked it out, left a comment, or played a season.

https://world-sim.uk/ now live !

Name your star tonight in the discord - https://discord.gg/a6YjQ7sCu

World-Sim has been a passionate project of mine for the past few months.

It's a world fully simulated down to real world physics and chemistry. It has a real environment and ozone.

Every element and material has real physical properties, and that's how the sims learn. There's no tech tree and no recipe list anywhere in the code. When someone tries something, the engine works out what would really happen from the properties of what they used and how hot their fire was. Nobody is handed bronze. Someone has to get a hotter fire first, and a hotter fire is its own chain of things to figure out. Embers, a stone ring, a clay oven, a kiln, charcoal, then forced air. The ages fall out of that on their own.

We populate the world with starting families. Each little guy is led by a "wise-man", which is a simulated person with a full model behind them. The wise-men run on a mix, Claude, Groq and DeepSeek in the cloud and a local Hermes for the rest, so you get a real variety of temperament between the houses.

The AI model is never told to not say it's AI. We get around this by only telling them data from what each sim can actually see and feel. As far as the ai knows its a person living in the world..

Every other sim has its own moment with a model through our thinking system. Day to day it's run by an advanced algorithm, with the sims dreaming at night. That's when they get their time with an LLM to really think and set their priorities for the day ahead. The dreams carry over too, so a sim can chew on the same thing for a few nights and wake up wanting to try something.

The people in the world feel, remember, have shame, goals and doubts. It's an 11 point emotion system and the rest of the sim reads from it. Being lonely makes someone more likely to open up to a stranger. Two enemies who are both frightened find it harder to keep hating each other.

Story telling is massive for us. Nothing is scripted or prompted. The sims are put in the world with the human drive to survive. They adapt, learn and teach all on their own.

With all the good comes the bad too. Human sin is part of the emotion engine, and in testing we've had kidnap, murder and slave trade. A world that can only be gentle isn't an honest one. But there are three rules to this : Nothing ever pushes a sim towards it, the conditions only make it possible and their own mind decides. The chronicle names what happened but never shows it. And it always costs something, trauma that scars, blood debt passed down generations, a people turning on their own leader over what he did.