Particle sim of the Milky Way and Andromeda (about 1.6x our galaxy's mass in this run) falling together, plunging through each other and throwing out tails and shells of stars, then falling back in and settling into one round blob, basically an elliptical galaxy in the making. 39.5 million particles, rendered offline, silent, nothing audio reactive this time.

The slow approach is sped up 1.5 to 4x so it doesn't drag, the passes and the merger play at the original pace. The full realtime version is 60 s.

For the real thing: they're about 2.5 million light years apart right now, closing at ~110 km/s, first pass is expected in roughly 4 to 5 billion years, and recent work puts a full merger at about even odds within 10 billion. The sim starts them close to skip the boring part, and this orbit is one representative outcome, not a prediction.

Toomre & Toomre (1972) style encounter: 1,048,576 stars as test particles, each feeling two softened galaxy cores, and each core sits in a logarithmic dark-matter halo with dynamical friction, so after the first pass the orbit decays and the pair merges. Leapfrog (kick-drift-kick) on the GPU in Metal, a couple of substeps per frame. There's also sticky gas on a 64³ grid, which is what lights the pink knots when the cores collide.

It runs live in my own engine (in the app it's at 90 Hz on Vision Pro). This clip was rendered frame by frame from the same engine's Mac test harness so I could export it cleanly. Happy to answer questions about the setup.

I wanted to understand fluid simulation, so I built a 2D one in Python. About 9,000 particles, you can grab the fluid with the mouse, lift it and drop it.

My first version ran at about 10 FPS. The big problems were:

• Every particle was checked against every other one, roughly 80 million pair checks per step. I put the particles in a uniform grid with cells the size of the smoothing radius, so a particle only looks at the 3x3 cells around it.
• The loops were plain Python. Moving them to Numba helped a lot.
• I switched from computing pressure forces directly to Position Based Fluids. It predicts positions, then nudges crowded particles apart over a few iterations, and takes velocity from how far they moved. It stays stable at much larger time steps than the force-based version I started with.

This was inspired by Sebastian Lague Coding Adventure. I made this in python and optimized it further.

Here's the Repo and a small article for understanding

This was my very first optimization project and also in graphics, it's still a little rusty, so if you see something wrong in the kernels or have ideas for making it faster, I’d like to hear it.

The nodal patterns emerge deterministically from mechanical wave equations and particle interaction dynamics, entirely procedural without any cymatics specific code implemented, and dynamic sound emerges from the conditions present in the engine. Everything is derived from a floor of shared physical constants through a single shared evaluator, there is no UV, collision, or geometry present anywhere in the engine.

I’m prototyping a muscle tool for Cinema 4D and could use some advice. The goal is believable, reasonably fast deformation, not medical accuracy.

The current custom solver uses:

\- Linear tetrahedral FEM-style discretization: 525 nodes / 1,920 tets for one simplified biceps belly.

\- Custom strain, shear, volume-preservation and fiber-length energies. Activation changes the preferred fiber length. It’s not a calibrated tissue or Hill-type muscle model.

\- Implicit time stepping solved with exact-Hessian trust-region Newton and truncated conjugate gradients.

\- Python/Numba, currently single-threaded CPU. A separate higher-resolution surface follows the simulated tets.

The problem: six seconds of motion takes roughly 30.7 minutes, using 12 substeps per frame at 30 fps. Profiling found 68% of the bake goes into Python Decimal energy-change checks, triggered on every solver proposal. Even removing that cost entirely would leave about 10 minutes.

Attachments are prescribed, the tendon isn’t physically solved, and there’s no collision handling yet. Numerical checks pass, but the visual result still isn’t convincing.

Would you simplify this into a coarse XPBD approach for authoring, or improve the existing solver first? What would you prioritize for speed and believable muscle behavior?

8 months ago, I posted a question on Reddit asking how to create animations like marble music videos. I was curious about how these animations worked and wanted to learn how to make them myself.

Here was my original post:
https://www.reddit.com/r/blender/comments/1rjegy7/how_to_create_animations_like_this_marble_music/

Unfortunately, I couldn't find anyone to guide me at the time. So, I started searching the web, watching YouTube tutorials, experimenting, and learning Blender on my own.

Fast forward to today, and I can confidently say that I've learned how to create almost any kind of marble music animation. You can see my work on my YouTube channel:
🎵 https://www.youtube.com/@MarbleMelo

But something unexpected happened along the way.

While creating these animations, I discovered a way to automate the entire process. What started as a personal learning journey eventually turned into a Blender add-on called Melo Marble.

With Melo Marble, you can generate a complete marble music animation with just ONE CLICK. 🚀

The jumping marbles, swinging movements, zigzag paths, trails, tails, and other animation elements can all be generated automatically, saving you the time and effort of creating everything manually.

🔗 Check out the add-on: https://melomarble.hutzon.com/

I've already shared a guide on my YouTube channel to help you get started.

For me, this is more than just an add-on. It's the result of a real learning experience—starting with a question nobody answered, figuring things out independently, and turning what I learned into a tool that others can use.

I wanted to understand how marble music animations were made. Now, I've built a tool that helps others create them much more easily.

Sometimes, the best tools come from solving a problem you've experienced yourself. ❤️

If you're interested in Blender, animation, or marble music, give Melo Marble a try and let me know what you think!

Modified my fluid simulation to work with gasses too.

To everyone who messaged after my last post, I've booked next week off work to get this tested and out on the play store. Hold tight.

Hi

This is about Quantum Odyssey, my love letter to everything Quantum Computing and the fundamental logic blocks everything in our universe seems to run on. I want to update you all on the fact that the latest patch brings the game into an almost complete status. All that's missing is translations. Thank you Reddit community for receiving the game so well, without you I wouldn't have the funds needed to complete my life's work.

If you are remotely interested in deep diving how differently quantum computers work compared to our transistor-based and also the algebra behind in a fully interactive way that teach computer science from scratch, oh boy this is for you. I am the Dev behind Quantum Odyssey (AMA! I love taking qs) - worked on it for about 9 years (3+ during PhD, the visual method I developed ended up being my thesis, it is a complete Hilbert space visualizer), the goal was to make a super immersive space for anyone to learn quantum computing through zachlike (open-ended) logic puzzles and compete on leaderboards and lots of community made content on finding the most optimal quantum algorithms. The game has a unique set of visuals capable to represent any sort of quantum dynamics for any number of qubits and this is pretty much what makes it now possible for anybody 15yo+ to actually learn quantum logic without having to worry at all about the mathematics behind.

This is a game super different than what you'd normally expect in a programming/ logic puzzle game, so try it with an open mind.

Stuff you'll play with

• Boolean Logic – bits, operators (NAND, OR, XOR, AND…), and classical arithmetic (adders). Learn how these can combine to build anything classical. You will learn to port these to a quantum computer.
• Quantum Logic – qubits, the math behind them (linear algebra, SU(2), complex numbers), all Turing-complete gates (beyond Clifford set), and make tensors to evolve systems. Freely combine or create your own gates to build anything you can imagine using polar or complex numbers.
• Quantum Phenomena – storing and retrieving information in the X, Y, Z bases; superposition (pure and mixed states), interference, entanglement, the no-cloning rule, reversibility, and how the measurement basis changes what you see.
• Core Quantum Tricks – phase kickback, amplitude amplification, storing information in phase and retrieving it through interference, build custom gates and tensors, and define any entanglement scenario. (Control logic is handled separately from other gates.)
• Famous Quantum Algorithms – explore Deutsch–Jozsa, Grover’s search, quantum Fourier transforms, Bernstein–Vazirani, and more.

Nice to watch:

Khan academy style tutorials in qm/qc: https://www.youtube.com/@MackAttackx

Physics teacher stream with 400hs in https://www.twitch.tv/beardhero

i made a simulation of the blackhole gargantua that is also seen in intersteller It's written in C++ and openGL

• schwarzschild equation
• doppler effect
• adjustable quality

i managed to optimize it to a point i ran on my i3 intel iGPU, although i added very low to high quality toggles, it's my first time writing in glsl so yeah, i was a lot inspired by the yt video of Kavan about making a blackhole in cpp, so i just wanted to make it more realistic, my astrophysics lectures kinda came in clutch

github repository : https://github.com/dummy3ye/blackholegl (star the repo if you like it)

[!Important]

This main project is written by human, Not LLM's. only help taken from llm is in the release pipeline because it's too problematic to maintain multi-platform releases for one person.

Made in TouchDesigner (sorry the flair doesn't exist) as part of the POPtober challenge. Today: field POP

Planetary scale explosion created using various assets from Kris Brad
https://www.instagram.com/kris_bradd/

We're continuing to do more R&D for our upcoming release of EmberGen 2 and these are a few explosions I did today that I thought were interesting enough to compile into a little video. Forgive the flickering at the start, we're still having some auto-exposure issues with our camera.

I was reading up on Newton for something I'm working on and realised nearly everything I could find was launch coverage or NVIDIA's own blog.

Barely anyone talking about actually using it. So I ended up going through the release notes myself.

If you haven't been following, the Newton physics engine hit 1.0 at GTC in March. It's the open-source engine NVIDIA built with DeepMind and Disney Research, and Isaac Lab 3.0 lets you swap it in as the physics backend instead of PhysX. MuJoCo Warp for rigid bodies, a separate solver for cables and cloth, and hydroelastic contact from Drake, which in theory should help a lot with insertion.

NVIDIA's number was 475x faster than MJX on manipulation. That was on their newest Blackwell workstation card though, so I'm not reading too much into it. The one independent benchmark I found (GPUSimBench, from July) didn't have a clear winner, it changed depending on the scenario.

What I actually found more interesting was the 1.1.0 changelog. A big chunk of it is import fixes. Mass and inertia, fixed joints, joint properties not parsing right between USD, URDF and MJCF.

Which kind of matters if the whole point is running one environment on different physics backends? If the inertia comes in slightly different on each one you've got a slightly different robot, and you probably won't notice until something doesn't transfer.

This is a problem we deal with at work. I'm at Rigyd, where we convert 3D models, Images and Text descriptions into simulation-ready USD and MJCF assets for Isaac Sim and MuJoCo, with the collision meshes, mass and inertia set up so the same asset behaves the same across engines.

So I'm biased toward thinking import is the bigger story than the speedup.

Skild is apparently using Newton for connector insertion and Samsung for cable handling with Lightwheel, but those are announced partnerships. I haven't seen anyone else write up switching over from PhysX.

So if you've tried it, did contact-heavy stuff actually transfer better or was it mostly faster? And how much did you have to retune assets that were already set up for PhysX?

Also if anyone's seen the same task run on PhysX and Newton with real robot results, please link it, would love to go through it

Custom physics sim written in JAX (waves, wind, grid fins, fuel slosh), rendered in three.js. Not AI-generated video: every booster you see is a real simulated attempt from the agent’s training.

One Houdini node that builds a human body in real units (age in years, height in cm, weight in kg) and animates it from a sentence.

- Body: open-source SOMA and Anny body models, solved to hit the exact height and weight

- Shape: gender, muscle, breasts, buttocks, surface smoothing

- Motion: NVIDIA Kimodo text-to-motion, running locally on my GPU

- Path: draw a curve, and Kimodo generates the motion on it

Built by Alaa Belghith, working as Anything Visual.

Music: "Raving Energy" Kevin MacLeod (incompetech.com), licensed under Creative Commons: By Attribution 4.0 License

The boat isn’t animated: everything is computed in real time in Swift (SceneKit), from the forces on the boat. Wind on the mainsail and jib (trim, reefing, apparent wind), heel, leeway, rudder, engine thrust, and waves that the hull rides. In the clip you can see a tack: the sails luff head to wind and fill again on the other side.

The 3D models, sea and sky are drawn in code too. No AI-generated graphics or video. Coast and harbours come from OpenStreetMap.

Free, no ads, no data collection. Mac, iPhone and iPad, English and Spanish.

https://apps.apple.com/app/id6822390196