First of all , please introduce yourself to the community.
My name is Matt. I’m 35 and I live in San Diego, California, United States with my wife. I graduated with a Bachelor’s degree in computer science in 2001 and have been working ever since writing software. This project was done outside of my full-time job as a senior software developer.
And, of course, tell us about your software.
My project has several pieces and can be found here:github.com/mfeemster/fractoriu…
Before I give the details, I’d like to preface it by saying this is beta software, so you might find bugs or things that you don’t like. Rather than reject it, I would really appreciate feedback so I can incorporate good ideas into future releases.
With that out of the way, here it is:
- Ember - A rewrite and redesign of the original flam3 code in C++. In addition to the rewrite, several bug fixes, optimizations and new features were included.
- EmberCL - A library that uses Ember, but does the rendering on the GPU using OpenCL. Currently, AMD and nVidia cards are supported.
- EmberRender, EmberAnimate, EmberGenome - Command line programs that use Ember and EmberCL to render still images, animations, and perform operations on parameter files. These are the equivalent of flam3-render, flam3-animate and flam3-genome. In addition to the rewrite and GPU support, these include the ability to pass command line arguments, whereas the original only used environment variables.
- Fractorium - A graphical desktop application that uses Ember and EmberCL which allows the user to edit fractal flames using either the CPU or GPU. It aims to be a competitor/replacement for Apophysis. It more easily exposes some features that allow the user to fine tune parameters.
All of these are only available for 64-bit Windows OS at the moment.
There is extensive documentation on the project page and I would encourage all users to read it.
What is its standout feature or quality?
From a user perspective, the main feature is that while you can get reasonable realtime editing feedback with a CPU, you can get phenomenal feedback when using the GPU. There currently exists no other Windows program which implements every aspect of the flam3 algorithm, and supports the number of variations/plugins that my project does.
User interface is a subjective thing, but I find Apophysis nearly impossible to use. In my opinion, I believe Fractorium is far more intuitive and easier to use. But that is all opinion, different users will have different preferences. As time goes on, I will do my best to incorporate users’ suggestions.
Regarding the GPU algorithm, I borrowed the core of the rendering loop from a project named cuburn whose focus was extreme GPU speed. This results in performance that exceeds any other editor around at the moment. Unfortunately, the fastest implementation only applies when not using xaos, but xaos is still reasonably fast.
Both CPU and GPU rendering can be done in either single or double precision math. Single is less precise, but faster and is good for preview editing. Double is very precise, but slower, especially on the GPU. Some flames are more sensitive to precision, so using double is appropriate there. Fractorium allows the user to choose, which no other implementation currently allows.
In addition to being more efficient, it’s also more intelligent when doing interactive rendering. Adjusting fields like brightness, gamma and vibrancy only affect the final stages of rendering. So Fractorium will only do the minimum amount of processing needed for each parameter that is adjusted. This allows a user to perform fine tweaks to the final output without having to restart the entire render process.
This type of intelligence is also used with the quality field. If an interactive render completes, and the user does nothing but increase the quality, the iterations pick up where they left off.
From a coding perspective, this is a complete restructuring of the design of the codebase from the bottom up. Substantial time was spent on the design to break it into logically structured pieces that are easy to follow. It uses modern coding practices, clean threading design, many optimizations and is well documented. It also seamlessly integrates the GPU portion into the design without being clumsy. Compared to the original flam3 codebase, Ember and Fractorium are a world apart.
For plugins/variations, I borrowed a technique seen in some of Xyrus02’s plugins to allow for the easy creation of pre and post variations. So most variations in Fractorium have all three; pre, regular and post. Also, a number of Apophysis plugins have math bugs in them, they are fixed in Fractorium.
In addition to algorithm performance and design, I have documentation on the project page that explains in detail what the algorithm is actually doing. When initially researching this, I had such a hard time understanding Scott Draves’ flam3 paper. So once I finally understood what was going on, I wrote a lengthy description of what the algorithm was doing in plain English, rather than using cryptic theoretical math notation. The idea was that nobody should have to suffer through what I did just to know what is going on, so I encourage all users to read it.
If thats ok to share, what are the future plans?
My list of ideas is never ending. I’ll probably be on my death bed murmuring “but… one… more… feature”. Here are some that I have on the back burner.
- I’ve implemented most of the popular Apophysis plugins, but still have a few more to do.
- While Fractorium exposes most options for rendering, there are still some that the user cannot change. I’d like to experiment with allowing the user to change iteration and fuse depths, which can impact the look of the final image.
- Present xaos to the user as a matrix, rather than a single column for each xform. This will allow them to see all xaos values for all xforms at once.
- Implement some of the final functionality from Apophysis that I’m missing, such as color curves and loading user gradients/palettes.
- A supersampling method that does not require more memory.
- An animation editor. I’ve always intended to do this, but needed to get the still image rendering and editing solid first, so it has taken a back seat.
- A standalone real-time GPU visualizer that cycles through parameter files, similar to Milkdrop for Winamp. I’m unsure if such a thing is even possible, but I’d really like to investigate it.
- An advanced randomizer. The current one just does what flam3 did and is sorely lacking. I’d like to create one that gives the user fine control over which random flames to create.
- Further investigation of 3D rendering. I’ve got some ideas that I’ve not fully pursued, but look very promising.
- Alternative rendering methods. These have been proposed in various papers, I’d like to at least see if they are doable or not.
- A benchmarking suite. This algorithm really stresses the CPU and GPU. I’d like to create a way for users to test the performance of their system with regard to fractal flame rendering.
- Produce writeups detailing the performance and quality effects from using various optimization techniques. Much discussion has been had on this subject, but no formal papers/pages have been released. I’d like to work with others on this.
- Some threading optimization techniques to make the UI be more responsive. Multi-threaded UI programming when using the GPU is extremely hard, if not impossible. I have it in a state that is usable for the time being, but not ideal.
- The current builds are for Windows only. I’d like to release versions for Mac and Linux.
- The current GPU hardware is for modern Nvidia and AMD cards only. I’d like to add support for AMD and Intel APUs as well.
- A legitimate website, I currently only have the project page. I have preliminary help from someone on this at the moment.
- A YouTube tutorial.
You have any other projects you are willing to share with the community?
I have no other projects. This has consumed almost 100% of my free time on nights and weekends over the last 2 years.
Do you create any fractal art yourself?
Not much. I always had hopes of going through the numerous tutorials on DA and really learning how to properly use this algorithm. I’ve just never had the time. I am always impressed by what the artists are able to produce, I absolutely love it. I can only dream of making such art myself some day. If anyone wants to teach me, I’d love to listen. In the meantime, I’ll stick with what I know, which is programming.
Why did you start working on fractal software?
It’s an interesting story. I was watching a documentary about DMT on Netflix in early 2012 and it had incredibly stunning graphics. I’d been a long time user of the Winamp visualization plugin, Milkdrop, but had never seen anything as stunning as the animations in that documentary. So I was determined to find out how they were made.
I looked on the credits, and it mentioned Electric Sheep. I began reading about flam3 and eventually Apophysis. I was fascinated by what could be done, although I was kicking myself for not finding out about it earlier. Here I was coming upon a community 10 years too late.
I had a hard time understanding much of Scott Draves’ flam3 paper, so I decided to dig into the code to see what I could find. After spending a few months analyzing it in depth, I thought that I could rewrite it to be faster and more readable.
Given the slow performance of fractal algorithms in general, I thought it might be time to give the GPU a try. I had never done GPU programming, so I figured this would be a good way to learn.
I spent months researching what had already been done on the GPU and realized that while there were several attempts, none were a complete solution. Once I noticed these holes in the marketplace, I knew what my project would be. I had never started or contributed to an open source project before, so this was a perfect place to start.
The next two years were spent investigating flam3, Apophysis, and various GPU implementations in extreme detail. This included reading the code as well as exchanging numerous lengthy emails with the authors. Then implementing the required functionality first on the CPU, learning GPU programming via OpenCL, then implementing portions of the algorithm on the GPU. Next it was all tied together in both the command line programs and the Fractorium editor. For Fractorium, I had to learn Qt, and for the installer, it was Wix. Finally, a project page was created and full documentation was added.
It’s been a long road that has completely consumed my mind and I’m very happy with where it is, but must hang up development for several months. I need to rest as well as focus on some other things. I hope to return to this effort in 2015.
In the meantime, I welcome any and all feedback from both users and developers: email@example.com
A little render test
Matt nicely provided some render stats
CrystalCavern by StuKarver.
Devices: GPU - R9 280x and CPU - AMD 955 4-Core
CPU to GPU improvement:
For single precision, the GPU render is about 96 times faster, while for double precision, GPU render is 34 times faster than CPU.
Render time CPU (double precision): 26sec
Render time GPU (double precision): 13min 40sec
Those values, of course, depend of your hardware and also of your parameters. For example, the CPU to GPU improvement for double precision ranged from 9x to 84x
And, of course, users oppinion
NightmareTF nicely shared his experience with Fractorium.
I've been using Fractorium since the beginning of this year basically. I remember finding Fractorium on Google while looking for other fractal software besides the usual Apophysis and such. The thing that struck me as most interesting was the ability to use the GPU for rendering. Though when I thought I could only use the amount of memory my videocard had, I contacted the developer (Matt) to ask if there was a way around this. Matt kindly explained to me that I could use the commandline to split the image in parts, so I could produce larger images. He also plans to add this feature to the GUI in the near future.
Since then I have been using Fractorium a lot for the great renderspeed it offers, which is specially useful while tweaking fractals. Combined with the clear and intuitive interface it offers, Fractorium has passed Apophysis for me.
Matt is really dedicated about Fractorium, and it really shows in the software. He has also implemented a huge amount of extra variations (popular Apophysis plugins and pre/post/dc versions of other variations, just to name a few) in one of the previous updates, making Fractorium even more interesting to use. I personally hope that this dedication doesn't fade with time, because the features he has in mind would be well worth the wait!
Fractorium is definitely one to watch, and absolutely deserves a lot more attention than it currently gets!