I struggle to describe Fluoddity. Think somewhere between interactive lava lamp and evolvable ant farm. Sometimes I'll see a roiling ocean, a jellyfish, or a tree. Sometimes it's more like looking under a microscope as little amoebas devour each other and break apart. And sometimes, it's stranger than all that.
Fluoddity3D is the 3d extension of Fluoddity, A physarum-like particle simulation designed for realtime exploration. The original (2d) Fluoddity is a generalization of this excellent Sage Jenson page about physarum transport models: https://cargocollective.com/sagejenson/physarum I strongly recommend reading at least the first few paragraphs if you want to understand how this project works.
The generalization to 3d is accomplished by adding a dimension to the trail map (pixels->voxels), particle state variables (position and velocity), and the trail vectors themselves. For years I've struggled with lifting the Fluoddity algorithm into the 3rd dimension. In retrospect I wasn't doing anything particularly wrong, I mostly just lacked the tooling and the persistence to find any interesting specimina. Some advice and a link to a paper from Sage Jenson got me to a working system, and from there I branched out and did some experimenting. Ultimately, the monte-carlo approach was very useful in getting started, but it imposed a strict radial symmetry that I didn't want.
Any advice or criticism is welcome. This is a toy I made for myself and I am more artist than engineer.
- "physics sliders" to customize simulation parameters.
- particle selection/mutation to customize particle behavior
- Save/load system for physics + behavior
- save strings with copy/paste from clipboard
- Save/load system for editor/rendering configuration
- parameter sweeps mode allows varying physics sliders across the canvas. X and Y sweeps for exploring 2d parameter space.
- variable physics frequency with motion blur
- Opengl GLSL renderer with volumetric path-tracing
- Optix CUDA renderer with realtime path-tracing and denoiser for RTX hardware
- Gamepad controls for first person style camera navigation
- Stereogram mode for cross-eye/wall-eye viewing
- ffmpeg based video recording with save/load system for batch-rendering
Particles in Fluoddity have no direct interactions with each-other. Instead, they leave trails as they move. These trails decay and diffuse over time. Particles respond to the density and direction of trails around them. There is no fixed rule that determines how particles respond to their senses. Instead, each particle has a simple neural-net like brain with just 120 parameters. These parameters are randomized on startup, and then mutated as the user selects which lineages to explore.
Fluoddity generalizes the traditional physarum model in a couple ways.
Particle trails have a velocity/flow vector which records the net "current" of particles. Thus, particle trails can interfere, and the trails from an equal number of particles flowing in opposite directions will cancel out.
Particle behavior is governed by a somewhat arbitrary black box function called a 'Rule'. I use a simple sum of sin waves because i wanted smooth, periodic noise. Trail sensor values are fed into this noise function, and the outputs are used to accelerate and reposition the particle.
In addition to forces causing acceleration, each paricle has a limited ability to "strafe", changing position independently from velocity. This is the least "principled" of my generalizations, but it is incredibly simple and enables some really beautiful patterns. Strafe allows particles to leave velocity trails which disagree with their direction of travel, enabling things like "swimming upstream" without turning around or "sidle to the left" without losing track of which way is "forward".
The move from 2D->3D introduces a complication: Each particle only stores a single 3-vector for its velocity. A "forward" vector in 2d reduces the set of possible orientations to 2: left handed and right handed. 2D Fluoddity runs the physics in both chiralities and averages the result. But in 3D, a forward vector affords a continuous ring of possible orientations instead of just 2. Thus, particles in Fluoddity3D read the trail at their position and use this 'environment vector' to reduce the set of orientations back to 2.
- Where are all the crystals? Fluoddity(2D) is full of structures like crystals, pellets and membranes. Pellets and membranes are plentiful in 3D, but virtually no crystals. Why?
- Extra particle state encoding a full orientation frame, eliminating the environment vector
- Audio synthesis based on the particle simulation
- Trail diffusion step replaced with arbitrary continuous cellular automata. wave equation or advection along flow lines could be interesting
- More than just two sensors.
- Disentangle "local orientation" from "particle velocity". Strafe mechanic hints at this being worthwhile.
- Particle internal state/ memory. Current particle behavior is memoryless aside from velocity persistence.
- Trails need not correspond to particle velocity. "Trail vector" could be just another output of the Rule function. Trail dimensionality could be increased.
- A more universal framework for describing these kinds of systems. One could generalize all the way to continuous cellular automata + continuous turmites.
- Python 3.x
- NVIDIA graphics card
- Optional Optix rendering backend requires RTX hardware
- Clone this repository
- Install dependencies:
pip install -r requirements.txt
- Optionally install Optix sdk 9.1:Optix SDK link and CUDA toolkit 13.3: CUDA toolkit link
Sync this repository, install the requirements, then run from source:
pip install -r requirements.txt
python main.pyThe app runs from source — there is no standalone build. Run main.py from the
repo root so shader and config paths resolve correctly.
This project is licensed under the MIT License - see the LICENSE file for details.