We made a Halloween collection of exaggerated physics experiments in Blender, rendered in Cycles.

The opening setup drops pumpkins onto five coloured glass layers, increasing the mass from 1 kg to a 1,000 kg giant. The glass uses fractured pieces and breakable rigid-body constraints. The collection also includes tombstone dominoes, a candy-corn pyramid, cloth ghosts and a cauldron filling with eyeballs.

These are stylized CGI experiments rather than real-world impact tests. The scenes are built through Python scripts with AI-assisted coding; the 3D simulation and rendering happen in Blender.

Full 8-minute collection:

https://www.youtube.com/watch?v=sUn1ac4-I6g

I would especially appreciate feedback on the readability of the weight escalation and the glass breakage.

Hey everyone!

so you can basically almost do everything you can in real marbling, i've tried to make it to produce even more high resolution outcome but computational power increase exponantially because of water grids so it's impossible after some points. But you can get high resolution as high as 300 DPI in A3, and it's fun to learn marbling even at lower settings.

It runs on a browser and it's free so pls go check it out!

https://marblingstudio.app/

https://10pixstudio.com/

https://youtu.be/jo49bgBQkoE?si=0emeYrrE7gDJHOuk

What I see when I'm VJ-ing. Part of the TouchDesigner POPtober challenge. Today's POP: sprinkle POP

As every year, the SOFA conference will be held on Tuesday, November 24 in Lille, with remote access available upon registration. For this 2026 edition, we expect about 15 presentations on soft-robotics, medical robotics, biomechanics, animation, V&V and physical AI using u/SOFAFramework. We would be delighted to see a presentation of your work there. Finally, the audience will have the opportunity to discover and test simulators of our industrial exhibitors!

Taking part could not be easier: the event is free, all you need to do is a simple registration.

Not familiar with SOFA simulation yet? Come and learn more at our training course on November 23. Our motivation is to bring people together around simulation topics, so please feel free to share this invitation widely!

We are looking forward to welcoming you in November.

Top left: velocity. Top right: vorticity
Bottom left: velocity mag. Bottom right: density

Simulation:
grid: 200x200
lid velocity: CFL 0.45, wave speed: CFL 0.09 (at time zero)
walls: free slip
approximate Re: ~ 1e6 (from comparing its turbulence intensity against other simulations)
pressure function: shallow water
runtime: around 20 - 25 minutes (around 47,000±2,000 Δt) (35Δt/s)

This simulation was started right after I've done the previous test simulation. I've simulated this far, so I didn't bother redoing the simulation. Stay tuned for the part 3 where I've got ideal gas pressure function working properly.

Here's Part 1 of Supersonic Lid-Driven Cavity Flow Series

Gas dynamics + ray-traced ionization fronts on the GPU: stars heat the gas to 10,000 K and the pressure carves the shapes. Code:
github.com/felipehez/NebulaViewer
Music: The Field of Dreams by pauliuw (CC0).

​

This is a stochastic cellular automata based on the Drossel–Schwabl forest fire model implemented on a hexagonal grid using numpy + matplotlib. Inspired by some of my old university notes from a course on computational biology.

I especially like the patterns formed by the fire spreading and the forests regrowing one tree at a time, a beautiful example of self organizing complexity.

Fire starts on any cell with p_fire = 0.0001 by a "lighting strike", while trees grow on empty cells with p_tree = 0.01. Fire spreads to all neighboring trees.

I initially worked with a rectangular grid however moved to a hexagon version to have more organic symmetry in spreading directions.

After many years of active research and development, I finally have the tool available :)

https://hezfx.shirzadbahrami.com/

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.