- Software: GNU GPL v3.0
- Documentation: CC BY-SA 4.0
One code base, multiple platforms.
- Win, Mac, Linux
The following are Houdini versions where FLAM3H™ is fully functional, tested and supported.
- H22.0 CL*
- H21.0 CL
- H20.5 CL
- H19.0 to H20.0
(*) Indicate the version allowed to run on future Houdini releases.
The above fractal Flame image consist of 400M points and rendered with Houdini internal Karma renderer. Originally rendered at 7k resolution.
A huge special thanks and lots of gratitude toward my family who kept up with me for so long while I was inside the fractal Flame bubble!
One of the main missions was to pack the entire algorithm and functionalities I desired inside a tool using only Houdini out of the box. No HDK. As a result, it became a somewhat conservative implementation, it has everything but also some limits as I needed to cut corners everywhere, which became a daunting process to put into balance.
A big commitment I needed to honor was to learn how to do fractal art. Building a fractal art tool without knowing what a fractal artist needs and feels while doing it is kind of meaningless. And thus, while creating this tool, I engaged in so much fractal art with it that I unavoidably developed a love for the field. It was important, so I could shape and steer this tool in the right direction.
Beside being a long time user myself...
Following are just few of the advantages of being a Houdini resident:
-
Fractals Come Alive
Through this implementation, fractal Flames are now a real thing within a formal, procedural application, with all of its data accessible and available for any kind of modification. -
A New Format
They now exist in a new format that describes them in ways that were previously impossible, rather than being a rasterized 2D image. -
Decoupled Resolution
In point cloud format, the "quality" is defined by the number of samples rather than fixed pixels. You can generate a dense point cloud and later decide to render it at 1080p, 4K, or 8K. The point cloud acts as a high-fidelity "source" that preserves the attractor's information independently of the final output resolution. -
Expanding Creative Pathways
They can connect to any kind of input and spread that information throughout the generation process, opening up countless possibilities for creative and experimental endeavors. -
Structured USD Entities
They are divided into various entities by a hierarchy when inside the USD context. Point cloud, render properties, handles, shaders, and so on. These entities are all transferable, changeable, and accessible. -
Advanced Production Framework
They become part of a larger ecosystem and benefit from all of its features, including proceduralism, data handling, animations tools, shading networks, and access to high-end renderers, just to name a few. -
Distributed Rendering Capabilities
Fractal Flames can be computed on a single machine or expand in scope by sending them to larger render farms. -
Pipeline-Ready Assets
If version control and review systems are in place, they can be fed into a pipeline like any other piece of data. -
Democratized Code Access
Without having to go through the hassle of setting up a C/C++ compiler for every platform and Houdini version, something that is typically handled by a senior software engineer, technical directors (and technical artists) may view and modify the source code. -
Interactive Development Flow
The tool can be modified in-place without affecting the running environment, enabling anyone to add and change its data and toolkits while monitoring the results in real time and ensuring that the updated version will function properly on all platforms that Houdini is running on.
FLAM3H™ node OTL documentation
FLAM3H™ is a high performance implementation of the fractal Flame algorithm fully developed within the SideFX Houdini environment, no HDK.
-
Supported devices
It run on GPU(OpenCL) as well on CPU(Cvex). -
GPU availability
GPU mode is only available with FLAM3H™ for H20.5 and up. -
GPU OpenCL
OpenCL (-cl-std=CL1.2) has been used to implement the algorithm so it can fully run on the system GPU device. It makes real-time fractal Flame editing in Houdini possible by running billions of iterations per second on AMD and Nvidia GPUs.
At its current stage, the GPU implementation is intentionally general-purpose.
It lets you explore different combinations of variations and settings
without needing to compile a new kernel every time something changes.
Since it runs directly inside SideFX Houdini,
keeping this level of interactivity was an important part of the design.
You can experiment, tweak things, and follow an idea as it develops
without constantly stopping to wait for a new kernel to compile.
The goal is to keep the process fluid and preserve that state of flow while exploring.
The entire data and memory layout has also been designed from the ground up around this approach, with the goal of making the most of the GPU and squeezing every bit of performance possible out of the hardware. -
GPU performance
Depending on the GPU device being used in the system, the FLAM3H™ GPU mode (the default in H20.5 and up) can be hundreds of times quicker than the CPU (Cvex) mode. Tests using an Nvidia RTX 4090 device show throughput ranging from ~40 to ~140 billion iterations per second, which practically enables the creation of high-quality point clouds with hundreds of millions of points in seconds as well as real-time fractal Flame editing within Houdini. A range of Flame settings were tested across 500 million points at 1024 (the GPU mode iterations default) and 2048 iterations, respectively.
Simpler Flames like the Sierpiński triangle which features 3 xforms, weighted probability xform selection, color accumulation and output for position, color ramp lookup value, Alpha and point scale reached ~176 billions iterations per second with a 1 billions points cloud at 4096 iterations each on the same Nvidia RTX 4090 GPU device. -
CPU
CPU mode uses Houdini's Cvex (Callable vector expression language).
Although Cvex it's not a real-time thing, it will still be a lot of fun if you have a powerful CPU (two powerful CPUs are even better). -
Additionally
-
The code went up and down and finally settled on the most minimalistic version in favor of performance.
-
Part of the work is done inside the HDA in the Houdini environment like attribute binding, UI building, parameter creations, their visibility conditions, the final compile and much more.
-
Python has been used to enhance the user experience and add functionalities like:
- copy/paste iterator data
- load/save palette's libraries
- load/save Flame's file format
- responses/automations to user actions
- and much more...
-
FLAM3H™ generates a live point cloud of the fractal Flame being worked on, which is the actual render. From there to the final image, it is left to the users (aka points rendering). With Houdini integrated Karma renderer, you will be able to render the generated fractal Flames in nearly real time.
-
FLAM3H™ OpenCL Kernel: cl_flam3
Target Architecture: NVIDIA Ada Lovelace (sm_89 / RTX 40-Series)
Tested On: NVIDIA GeForce RTX 4090
NVIDIA Driver Version: 580.97
Compilation Context: Houdini OpenCL Runtime Code Cache
Work-Group size: 256
| Hardware Resource | Metric Value | Description |
|---|---|---|
Global Memory (gmem) |
0 bytes | Statically allocated global memory usage. |
| Stack Frame | 0 bytes | Per-thread stack memory allocation. |
| Spill Stores / Loads | 0 bytes / 0 bytes | Register spills caused by register pressure. |
| Registers Used | 48 registers | Number of 32-bit registers allocated per thread. |
| Execution Barriers | 1 barrier | Number of synchronization barrier instructions. |
Shared Memory (smem) |
16,400 bytes (16.4 KB) | Shared memory allocated per thread block. |
Constant Memory 0 (cmem[0]) |
872 bytes | Constant memory for kernel parameters and compiler-managed data. |
Constant Memory 2 (cmem[2]) |
4,120 bytes (~4.1 KB) | Constant memory for read-only data. |
| Instruction Class | Hardware Functions | Assembly Count | Description |
|---|---|---|---|
| ALU Core Math | FMA, FMUL, FADD |
15,960 | Floating-point arithmetic operations. |
| Special Functions | MUFU |
3,117 | Transcendental math functions (e.g., sin, cos, log). |
| Control Flow | BRA, BRX |
2,482 | Branching and loop control instructions. |
| LOP3.LUT instructions | LOP3.LUT |
2,709 | 3-input programmable bitwise logic instructions. |
| Integer & Indexing | IADD3, IMAD |
844 | Integer arithmetic and address calculations. |
| Shared Memory Cache | LDS, STS |
454 | Shared memory load and store operations. |
| Global Memory Bus | LDG, STG |
72 | Global memory load and store operations. |
| Thread Synchronization | BAR.SYNC |
1 | Thread block synchronization barrier. |
| Dependency Management | DEPBAR, LGWR |
0 | Instruction dependency management operations. |
You can review the FinalXForm(FF) kernel metrics at the link below:
From FLAM3H™ v1.8.98,
a new custom materialX Shader has been introduced to the FLAM3H™USD HDA to allow proper points color values accumulation. It will perfectly match what third-party implementations refer to as:
- "build a buffer with the histogram or summation/accumulation of every point in every pixel"
This custom shader will match the visual quality of the fractal Flames rendered with Apophysis, Fractorium and others. Fully available only with FLAM3H™USD HDA versions for Houdini H20.5 and up.
Karma interactive
Sphere Sugar Dragon - Author: Pillemaster
Karma interactive
Worlds - Author: Alessandro Nardini
Karma interactive
Its Pink - Author: Plangkye
My first curiosity with fractal Flames led me to download and experiment with Apophysis. Since I knew absolutely nothing about the topic, I gradually began to truly like the way its user interface and workflow process were crafted. Everything is accessible with a single click, and you get the impression that you can move through your Flame setup quickly and with clarity.
Even though I eventually went into Fractorium,
from the beginning, I intended to incorporate this into FLAM3H™.
Many Apophysis fractal Flames are available for download on the web, and you can load them inside FLAM3H™. Or you can use Apophysis or Fractorium to author your Flames first and load them back into FLAM3H™. But also the other way around, create your Flames in Houdini and render them inside other applications. You've got choices.
Download Apophysis 7x here: Apophysis 7x download
Download Fractorium here: Fractorium download
FLAM3H™ generate a live point cloud of the fractal Flame you are working on.
- Following are some screenshots showing it for a few different Flame presets.
Dancing Stars - Author: Alessandro Nardini
Cool EDisc - Author: Pillemaster
Crystal Eggs - Author: Alessandro Nardini
All the render settings required by third-party programs such as Apophysis and Fractorium are stored together with the fractal Flames when they are saved from FLAM3H™.
A portion of the render parameters deal with the camera and how the fractal Flame you just saved is framed.
The FLAM3H™ camera sensor will precisely display the image framing.
Once framed, you can save the Flame and be sure it will be framed the same in all other applications.
Camera sensor: FLAM3H™ to Fractorium
Camera sensor: FLAM3H™ to Fractorium
Following are some images showing FLAM3H™ rendering some of the Fractorium's example Flame files. Some have been modified to fit within the available variations. The screenshots show FLAM3H™ with Houdini Karma interactive on the left, and Fractorium with the same Flame file on the right.
Chocolate Scaffold in Too Many Dimensions by plangkye. Source: Fractorium
Mountain by tatasz. Source: Fractorium
Bipolar by tatasz. Source: Fractorium
Flipped Disk. Source: Fractorium
Note that all the followings, are also available as PRE_ and/or POST_ variations.
Arch Auger Bent Bent2 Bipolar Blade Blob Blur Boarders Bubble Butterfly Bwraps Cell Conic Cos Cosh Cosine Cot Coth Cpow Crop Cross Csc Csch Curl Curve Cylinder Diamond Disc Disc2 Edisc Elliptic Escher Ex Exp Exponential Eyefish Fan Fan2 Fisheye Flower Flux Foci Gaussian_blur Glynnia Handkerchief Heart Hemisphere Horseshoe Hyperbolic Julia JuliaN Juliascope Lazysusan Linear Log Loonie Mobius Modulus Ngon Noise Oscope Parabola Pdj Perspective Pie Point_symmetry Polar Polar2 Polynomial Popcorn Popcorn2 Power Pre_blur Radialblur Rays Rectangles Rings Rings2 Scry Sec Secant2 Sech Separation Sin Sinh Sinusoidal Spherical Spiral Split Splits Square Stripes Supershape Swirl Tan Tangent Tanh Twintrian Unpolar Waves Waves2 Wedge Wedgejulia Wedgesph Whorl
They are 106, if you were wondering...
This implementation initially concentrated only on the core algorithm. However, it gradually became apparent that a significant portion of the work needed to be focused on the user experience and how all the algorithm pieces are stitched together in a meaningful way for the user, making this part of the project very time consuming.
Because FLAM3H™ was designed with fractal artists in mind, many internal automation that could be done to provide a seamless and pleasurable experience has been completed.
FLAM3H™ prioritizes the user and their quality of life while using it, from completely automated Xaos and iterators/xforms handling to a slick, practical, and compact user interface.
The workflow is convenient and quick since data can be copied and pasted between iterators/xforms and between various FLAM3H™ nodes. Along with many other quality-of-life features inside the Houdini environment, third-party tools like Apophysis and Fractorium allow you to interchange data from and to FLAM3H™ simply by copying and pasting from the clipboard, making the process as smooth and comprehensive as possible.
It fully support the *.flame file format for maximun compatibility.
Python and the Houdini's HOM libraries have been used to achieve all of this.
Any parameter that is available in FLAM3H™ can be animated using any of the Houdini procedural paradigms and toolkits. These include but not limited to animation curves, expressions, and procedurally produced data from anywhere in Houdini, such as DOP Simulations, Particles data, CHOPS, and many more.
FLAM3H™ comes with a straightforward utility LOP node call FLAM3H™USD to makes it easier to move the fractal Flame point cloud into the USD context Solaris. This node allow to set up and render FLAM3H™ fractal Flames using Houdini's Karma renderer within a few clicks.
To finish, FLAM3H™ features a detailed documentation that is designed to provide you with all the informations you would need. This also extend to generous tooltips for each parameter in the FLAM3H™ Houdini user interface.
Given how expensive it is to compute fractal Flames, it is not surprising that GPUs have performed wonders in this area as well.
The main benefits of being inside Houdini are numerous. Consider the options available to you while animating those Flames with Houdini's procedural approach and toolsets. Additionally, the Python HOM libraries for Houdini can be used to build a pipeline around this tool.
Karma and the built-in Nvidia Optix denoiser make a fantastic combination for rendering fractal Flame images.
As far as I know, there are no switch/case constructors or other types of pointer functions in the CVEX language so far (up to H22). I connected hundreds of "if"/"else if" statements to arrive at the chosen variation. Despite my best efforts to partition them, this section ended up becoming somewhat of a bottleneck for the CPU(Cvex) implementation.
Python run single threaded here, now that this tool has lots of python code running or when many iterators are created, Houdini's FLAM3H™ user interface becames slow. I made some effort to make it better, and from v1.4.75 I was finally able to start improving the UI performance a fair bit.
All the python automations that are currently in place are really "nice to have" features that improve the workflow by a lot. There is also a big chunk of python code that deal with making the UI pretty and nice to look at, with lots of icons changing based on the user actions. A computer processor with strong single-threaded performance would be very helpful here.
Also, I used 128+ iterators in all of my stress tests. In reality, though, I've never used more than 20 iterators in any of the fractal Flames I've created thus far, nearly all of them used less than 10.
Almost all fractal Flame images on my website and instagram use an average of 64 iterations max, Some use less, and some use a bit more. A few exceptions went above 128 and up to 256/512.
Some Flames need truly an high number of iterations to be resolved correctly but with the GPU implementation in FLAM3H™ for H20.5 and up you can now run thousands of iterations per point with easy (assuming the system GPU device is powerful enough).
Listed below are presets from Chaotica software that were converted to FLAM3H™. They were chosen because some of them are very expensive to solve and because they make use of variations I've already implemented.
Some require thousands of iterations to show you the proper results; some of them require hundreds, and some others are really quick.
-
The following screenshots show FLAM3H™ with Houdini Karma interactive on the left, and Fractorium with the same Flame file on the right.
-
They were all computed using the CPU mode because, at the time, the GPU mode was not yet ready. Therefore, the number of iterations listed below represents the minimum number required to compute the Flame properly.
Iterations needed in FLAM3H™ to resolve: 1280
Ieddaka Gnarl. Author: zuek
Iterations needed in FLAM3H™ to resolve: 512
Blue Modulus. Author: tatasz
Lazyswirls. Author: meckie
Iterations needed in FLAM3H™ to resolve: 64
Majestic. Author: tatasz
Iterations needed in FLAM3H™ to resolve: 32
Blurry Splits. Author: tatasz
The following is another preset Chaotica software ship with I truly loved ported inside FLAM3H™ and rendered with Karma renderer.
Iterations needed in FLAM3H™ to resolve: 64
Golden Dragon - Author: meckie
You'll find other scenarios where your iterations number will need to rise up, especially when relying heavily on containers and such.
However, from all my tests, between 10 and 96 iterations will get you covered for almost all your needs. And don't forget, you can create some beautiful fractal Flames with just six iterations. Here is one I did:
Iterations needed in FLAM3H™ to resolve: 6
Knot Clusters - Author: Alessandro Nardini
I could add a lot more functionalities, but this project consumed me for a very long time ( years ).
Every aspect of this algorithm, once understood, looks simple on its own.
But the simplicity of the individual pieces is almost deceptive: once they are put together, their interactions turn them into a much more complex system-level problem.
It has been quite a crazy ride to pack everything into this implementation.
It is time to park this project for a little bit, but I really, really loved the long journey on this topic, and I will now forever love fractal Flames as a whole, they are awesome ( and addictive )!
Some of the example Flame files I'm using as a proof of correctness and shipped with this implementation were created or authored by some incredible fractal artists using a variety of open source and free apps like Apophysis and Fractorium among the most popular.
Please be sure to check out their gallery:
tatasz, plangkye, Pillemaster, Triptychaos, TyranWave, Zy0rg
Reference A: Github :: FLAM3 from Scott Draves and Erik Reckase
Reference B: Github :: Fractorium from Matt Feemster. Contributors: Michel Mastriani, Simon Detheridge
Reference C: Github :: Apophysis 7x from Mark Townsend, Ronald Hordijk, Peter Sdobnov, Piotr Borys, Georg Kiehne
Reference D: PDF :: The Fractal Flame Algorithm publication
Reference E: WEB :: A more accurate Elliptic variation from Claude Heiland-Allen
Reference F: WEB :: pseudorandom number generators (PRNGs) from David Blackman and Sebastiano Vigna
Reference H: WEB :: mwc64x is a 32-bit generator for 32-bit floating-point numbers created by David Thomas
Copyright (c) 2021 F stands for liFe