Fractal Architect 3D - fractals done the Mac way!

[Far]

I suspect that the Chaotica renderer used a small Highlight Power setting for this fractal rendering. (This is a hunch, but let me show you why.)

No need to guess; I turned off highlight power entirely for my render. Being unsure what highlight power options FA had, I decided to go with the most basic/"raw" option of just not using it.

But I'm honestly not that concerned about exact color-matching; it is understood that different renderers will probably handle tonemapping slightly differently. And anyway, in practice, most chaotica users use the curves to drastically alter the colors of the render anyway, so a slight saturation difference between FA and Chaotica's renders is basically a non-issue to me.

To achieve thin - thin lines that are anti-aliased, its easy.
Render to 1600 x 1600. Reduce the image size to 800 x 800. Here I used Acorn with Lanczos scaling. No other changes made with Acorn.

This, however, is a much bigger deal. Having to render larger and downsample in a separate image processing problem just to get adequate clarity and fineness of details? No, this is something a fractal renderer should definitely be able to do out of the box!

If you study the mathematic logic used by all flame fractals renderers today, there are in fact two erroneous assumptions in the math formula used to convert a specific pixel's histogram value to the final pixel's RGBA color value.

[...]

The main effect of this error on the image is that the output image will be dimmer than it should be and color saturation be lower.

Uh, actually, apophysis has accounted for this for as long as I can remember (I've been using the program for nearly ten years). I don't think it is implemented quite the same as your adaptive gamma, but the end result is that there is no loss of brightness when, e.g, zooming a fractal in:



The zoom was the only thing changed between these renders; I did not have to manually edit the brightness or gamma.

I'm not sure what you mean when you say "Every point in the point pool is 100% fused." My understanding of this term is that the "fuse" consists of some initial iterations that are not displayed. So, either an iteration is part of this fuse and is discarded, or it is not part of the fuse, and it is displayed. It is a binary off/on thing; it wouldn't make sense to say an iteration was "20% fused" or whatever.

So, what I think you're getting at is that other renderers don't account for the discarded iterations when they are determining brightness, but I could be wrong because the phrasing was very unclear to me.

Also, I am skeptical that your "points retained" measurement is accurate. Chaotica also measures this (it calls it "efficiency") but it is giving a value of about 72%! It is possible there are some differences in, say, how many iterations are being discarded due to being in the fuse, but I would be surprised if the effect on the efficiency was THAT drastic. I would have to do some more investigation to come to a firm conclusion on what exactly is going on here... However, I will say that having designed the parameters in question, I think that 30% efficiency is probably low, considering how sparse the samples outside the frame are and the sheer density of hits on those thin, bright lines.

Re: tiled renders, I think a better question is how big the render has to be before tiling is a necessity. To get a rough idea of the values involved, I did a quick test and found that chaotica could go up to approximately 5000x5000 pixels (with a little bit of supersampling) or 6700x6700 pixels (with supersampling turned off entirely) while staying under a GB of RAM. Now, I am unsure how closely these values would translate over to rendering on a GPU... but it is a nice starting point to gauge where exactly the "tile threshold" is in the first place. I've rendered a lot of print-res images and never needed to use tiles; of course, I wasn't dealing with the memory restrictions of a GPU but I also didn't have much of an issue with the speed of the print renders either. So, to me, while tiles can be handy in some situations, more often they are just more trouble than they are worth.

Another potential factor, for truly huge renders, is: when does the speed penalty of needing to render multiple tiles due to limited GPU memory outweigh the speed increase from using the GPU? I don't even have an estimate for how big you'd have to render before using all your available memory to render one big tile on a CPU would be just as fast as rendering many tiles in sequence on a GPU but it is certainly interesting to think about!

---



Anyway, this has been a long post going over many topics. When it comes to the original issue of image quality in renders, the crux of this post is that I do not think a fractal renderer should rely on outside programs (even if it is "just" a resize) to achieve clarity of detail and avoid blurriness. I already have to do this when I use Ultra Fractal... I'm glad I don't have to do it for IFS too. Unfortunately, while the renders you posted are the best FA renders I've seen so far, I still find the slight blurriness of the aa and reliance on postwork for thin lines to be a barrier to truly stellar image quality. I also was not particularly fond of the look of the grain in the "thin" regions (like the orange spots just to the inside of the curve in the bottom right hand corner) although admittedly that is both subjective and subtle.

[sbrodheadsr]

I love Pharmagician's (on deviant art.com) term for many open source projects:  AbandonedWare

Flam4CUDA for Windows and Flam4Cuda for Mac are officially: AbandonedWare

No one is maintaining or enhancing those projects at the moment. You can look at the project page on SourceForge
and see that it has been a long time since either me or my son have worked on those projects. If you would like to work on that project I would be happy to
get you in contact with my son as he is the project administrator. Please send me a personal email with your contact info and I will pass it in turn to my son.

Flam4CUDA for Windows was written when CUDA version 1 and 2 were the current versions. Now its at version 6. There has been a LOT of changes of the CUDA runtime API which is most likely why Flam4CUDA for Windows crashes on a version 6 runtime. I vaguely remember having to make changes in
Fractal Architect 2 when either CUDA 4 or CUDA 5 was released (due to CUDA runtime API changes).
If you think you do want to work on the project, I would be happy to tell you what I had to change by looking back in my project's source code history.


Flam4CUDA (both platforms), Fractal Architect 2 OpenCL (older version of FA) renderers do not support Xaos.
Xaos is a table of conditional probability weights to be applied each iteration of the algorithm. Google for Apophysis and Xaos for many articles on the topic.

Fractal Architect version 3 and 3D do support Xaos. (The free version of Fractal Architect is a version 3 product but does not offer 3D fractal variation support.)

To get Xaos support, you must modify the CUDA kernels to support a different point pool design. My son and I call this "single point pool vs multiple point pools".

[mfeemster]

Thanks for the info Steve, I appreciate it.

[sbrodheadsr]

Tataz,
the issue you are talking about boils down to how all digital representations of mathematically continuous values (often loosely called "analog" values)
introduce a small amount of error that engineers and designers try very hard to make "invisible".

Mathematically, on this particular fractal, the thin line curves in fact have "zero" width and are similar to the Dirac Delta function used in theoretical physics, engineering, and mathematics. To see, this zoom in by 2x and re-render again. Do this multiple times. The width of the line will always be 1 single pixel wide regardless of how far you have zoomed into the picture.

The pixel layout of the histogram determines which pixels intersect the lines and which do not. Those pixels will be assigned a "hit" and will contribute to the final histogram used to create the fractal image.

Anti-aliasing is a processing step to eliminate the jagged appearance of a continuous curve on a finite resolution display. (if the resolution of your display is high enough - you can't see the jaggies at all at normal viewing distances. That's why Apple makes such a big deal about their "Retina" displays)

Anti-aliasing can be done at the histogram construction step or later when converting the histogram values to the final image (or both).

One very important side-effect of the core Chaos IFS algorithm that Scott Draves invented, is that you dont "know" where those lines are inside the render. You can only "infer" their position by the hits collected on the histogram. This is a very well researched field under the term "Statistical Sampling". At the level of a single pixel, there is significant aliasing error created by digitizing a continuous input function. But at normal viewing distances with a large enough grid resolution, this statistical sampling error vanishes to an invisibly slight noise - otherwise this would be a useless technology to create images with.

Anti-aliasing takes the individual pixel values and effectively "smears" the jagged line of pixels by smearing the luminosity of neighboring pixels across each other so the human eye sees a smoother curve. The side effect of this is that the line's apparent width increases.

The Fractal Architect renderer adds dithering noise to the image to reduce the appearance of aliasing. This totally counter-intuitive step
works quite well and is the "key" secret ingredient used by audio engineers to improve the the final mastering quality of audio CD's, DVD's, etc.
They add very low levels of almost inaudible random noise to a recording which actually makes the recording sound more like an analog recording.

So the width of curve 1 pixel wide will be increased to most likely 2 pixels approximately. If the renderer "knew" where the lines were it could reduce the anti-aliasing width increase to a small fractional increase over the original 1 pixel wide line.

There is a very important fundamental theorem called the Nyquist Sampling Theorem, which enters into play here too.

So how do renderers produce anti-aliased lines that are 1 pixel wide? They use super-sampling where by the image is rendered larger than required and anti-aliased at that higher resolution. Then you simply use image size reduction to get the final required image size. With 2X Supersampling, the 2 pixel wide anti-aliased lines are reduced to 1 pixel wide.

The problem with Supersampling is that it is very computationally expensive e.g. for 2X Supersampling, the render would take 4X as long to render.
Because of that performance penalty most exhibition renders don't use it, unless they want to display 1 pixel wide anti-aliased lines.

Supersampling has been around a long time. Its a Flam3 rendering parameter and that renderer dates back a decade or more to its origins.

Its easy to do supersampling with Fractal Architect too if you wish. (See post above)

[Far]

CPUs and GPUs are different devices with different strengths and weaknesses. But this has been very well documented elsewhere. You might go to anandtech.com

Xaos is a table of conditional probability weights to be applied each iteration of the algorithm. Google for Apophysis and Xaos for many articles on the topic.

Mathematically, on this particular fractal, the thin line curves in fact have "zero" width and are similar to the Dirac Delta function used in theoretical physics, engineering, and mathematics.

Dude, you have got to stop explaining things that are common knowledge as if you are the only one here that knows about them. It comes across really condescending.

Tatasz is currently pursuing a Master's Degree in statistics; when you tell her things like "This is a very well researched field under the term 'Statistical Sampling'" and "There is a very important fundamental theorem called the Nyquist Sampling Theorem" it just makes you look like a buffoon. How would you feel if I came up to you and went, "Now, this is the mouse, you can use it to click icons and control the computer..."? I don't expect you to know the full details of anybody's background but you can reasonably assume that the people in this thread are plenty tech-literate and math-literate already. You don't have to explain basic things. If we are unclear on something you are talking about, we'll just ask.

So basically tata knows full well why your lines are a bit fuzzy; what she's saying is essentially what I said: the lack of oversampling and need to do it in an outside program is a problem.

[tatasz]

Tataz,
the issue you are talking about boils down to how all digital representations of mathematically continuous values (often loosely called "analog" values)
introduce a small amount of error that engineers and designers try very hard to make "invisible".

Mathematically, on this particular fractal, the thin line curves in fact have "zero" width and are similar to the Dirac Delta function used in theoretical physics, engineering, and mathematics. To see, this zoom in by 2x and re-render again. Do this multiple times. The width of the line will always be 1 single pixel wide regardless of how far you have zoomed into the picture.

The pixel layout of the histogram determines which pixels intersect the lines and which do not. Those pixels will be assigned a "hit" and will contribute to the final histogram used to create the fractal image.

Anti-aliasing is a processing step to eliminate the jagged appearance of a continuous curve on a finite resolution display. (if the resolution of your display is high enough - you can't see the jaggies at all at normal viewing distances. That's why Apple makes such a big deal about their "Retina" displays)

Anti-aliasing can be done at the histogram construction step or later when converting the histogram values to the final image (or both).

One very important side-effect of the core Chaos IFS algorithm that Scott Draves invented, is that you dont "know" where those lines are inside the render. You can only "infer" their position by the hits collected on the histogram. This is a very well researched field under the term "Statistical Sampling". At the level of a single pixel, there is significant aliasing error created by digitizing a continuous input function. But at normal viewing distances with a large enough grid resolution, this statistical sampling error vanishes to an invisibly slight noise - otherwise this would be a useless technology to create images with.

Anti-aliasing takes the individual pixel values and effectively "smears" the jagged line of pixels by smearing the luminosity of neighboring pixels across each other so the human eye sees a smoother curve. The side effect of this is that the line's apparent width increases.

The Fractal Architect renderer adds dithering noise to the image to reduce the appearance of aliasing. This totally counter-intuitive step
works quite well and is the "key" secret ingredient used by audio engineers to improve the the final mastering quality of audio CD's, DVD's, etc.
They add very low levels of almost inaudible random noise to a recording which actually makes the recording sound more like an analog recording.

So the width of curve 1 pixel wide will be increased to most likely 2 pixels approximately. If the renderer "knew" where the lines were it could reduce the anti-aliasing width increase to a small fractional increase over the original 1 pixel wide line.

There is a very important fundamental theorem called the Nyquist Sampling Theorem, which enters into play here too.

So how do renderers produce anti-aliased lines that are 1 pixel wide? They use super-sampling where by the image is rendered larger than required and anti-aliased at that higher resolution. Then you simply use image size reduction to get the final required image size. With 2X Supersampling, the 2 pixel wide anti-aliased lines are reduced to 1 pixel wide.

The problem with Supersampling is that it is very computationally expensive e.g. for 2X Supersampling, the render would take 4X as long to render.
Because of that performance penalty most exhibition renders don't use it, unless they want to display 1 pixel wide anti-aliased lines.

Supersampling has been around a long time. Its a Flam3 rendering parameter and that renderer dates back a decade or more to its origins.

Its easy to do supersampling with Fractal Architect too if you wish. (See post above)

Hiya!

Well, I am a statistician and studied lots of math, and i know well what AA is, and also about some possible implementations.
Your render is excessively blurry. Also, i've seen a few comments from your beta tester stating that the images he shared were postworked to sharpen them. This leads me to conclude that its a generic characteristic.
While some blur is not always bad, at some situations, we artists may want a sharp, very sharp, render.

[lycium]

I feel semi-obliged to jump in here with a "me too" and mention that Glare Technologies' main software product is not Chaotica but Indigo Renderer, which is all about physics and statistics. Chaotica is the relaxing easy stuff to do after a day's work on real monte carlo methods

So yes it might be a bit premature to be pointing the audience ("viewers!") at wikipedia  

Edit: Also, even after all this talk and explanation, the folks at Orbit Trap took the opportunity to completely miss the point in a mini-review of Chaotica!  

[sbrodheadsr]

Far - some replies:

Percent retained:  Calculate the total number of iterations across all pixels. Call this TOTAL. Sum up the hits on the histogram. Call this HITS.
Percent retained = HITS / TOTAL

I have no idea what the Chaotica efficiency value indicates.

FA tracks the iteration history of every single point in the point pools. A point is not recorded on the histogram unless its iteration count is greater than the Fuse threshold. If due to the formula calculations, a point value becomes either Infinite (INF) or NAN, it is discarded and replaced with another random point, whose iteration count is reset to zero. That new point will not be recorded on the histogram until its iteration count exceeds the Fuse threshold.

I have also experimented with not replacing the points, and you end up with a much "thinner" histogram. The approach in current renderer seems to work better than the pure discard approach.

Fuse artifacts look like a fuzzy square pillow centered on your fractal.

Fuse % is the percent of all points in the point pool whose iteration count < Fuse threshold at the completion of the render.

I don't think I am the first person doing this stuff inside the core render kernels.
This is not Rocket Science. (Odd joke expression - since I am an ex-Rocket Scientist)

Tiling ====
Flam4CUDA for Windows was developed on a gaming PC with multiple top-of-the-line graphic cards (back in 2007/2008).

Porting it to the Mac in 2009 revealed:
1) It needed to be scaleable down to work as well with thumbnail sized images as well as it worked with large images.
2) It needed to work well with with the modest Nvidia laptop GPUs on the 2009 Macbook Pro and their 256 Mb of Vram.
    (Of which > 100mb would have been filled by the Operating system's textures after a fresh reboot.)
3) It needed to not hog the CPU processor, so you could surf the web while doing a big render, etc.

For item 2, the answer was tiling. The point I made in the contest post, was that tiling is for all practical purposes: invisible.
See for yourself! If they are so bad, then tell how many tiles you see and where they are !!!
So far no one has given the correct answer.

Would someone care to comment on how many tiles were used to render the Avatar movie to the Imax 5k resolution (I don't know the answer.)

There are two minor features which are in FA that are mostly for the developer's benefit and not the fractal artist.
1) You can force it to tile even when there is plenty of memory available. (You could use this to prevent FA from grabbing Vram needed by other programs.)
2) You have a Histogram viewer - which was built so I could see the histogram. It's useful for determining when to stop a render, when all areas in the fractal
     have adequate hits to eliminate noise in low density regions.

When is Tiling necessary =====

    // Note: formula for amount of memory is: 3 Mb  +  (36 * area / 1048576) Mb
    // or  max area is: (X - 3)*1048576/36 with X in Mb units
    //
    // so for 35 Mb total, the max area is: 932,068 pixels squared or about 1000x932 pixels
    // so for 45 Mb total, the max area is: 1,223,338 or about 1280x956  pixels
    // so for 90 Mb total, the max area is: 2,534,059 or about 2560x956 pixels
    // 1440x900 => 47.49 Mb, 1366x768 = 38.02 Mb, 1920x1280 = 86.375 Mb

So for 5000x5000, we need 858.3 Mb of Vram to render the image without needing to tile it.
My 2012 Macbook Pro has 1024 Mb of Vram.

The Mac Pro I have on order has 6144 Mb of Vram on each GPU.  It will be able to render an image
13,373 x 13373 without tiling.

In 2014, 2 Gb of Vram on a desktop GPU is commonplace.

It looks like our data structures used in the renderer are approximately the same size based on the numbers in your post.

Tiling Performance Cost ====
Lets say you have a 5000 x 5000 final image size. An 8 pixel overlap is needed to split this into two tiles. This will require two separate renders
of 2508X5000.
This is the same as a single render of 5016x5000. So the performance penalty is 0.32% which is totally negligible.

For larger images, the performance penalty percentage decreases exponentially.

[sbrodheadsr]

Tataz,
I am sorry. I had no idea what your education background or course of study was.

I was trying to summarize Statistical Sampling basics (and not very well I guess) for someone that has had absolutely no exposure
to Statistics. Its hard to do in a few paragraphs.

My own educational background is:
BS Chemical Engineering LSU - Magna Cum Laude - Top of Chemical Engineering class
Almost MS Electrical Engineering U of Texas Austin (I was transferred to a city far, far away by my employer and could not complete the degree in absentia.)
MBA concentration in Finance from University of Chicago. Graduated top 7%.
University of Chicago is widely recognized as the top university in the world for both Economics and Finance and has been for many decades.
See: http://www.uchicago.edu/about/accolades/22/

I received a good education. I am not a statistician. I am sure you know way more than I do about that field of study.
Its used heavily in the fields of Economics and Finance as I am sure you are well aware.

There are many people smarter than myself. I don't know and can't know everything.
My son knows way more about rendering and computer graphics algorithm than I do. He is smarter than I am for sure.

And I do wish you luck in the profession of your choice. Its an exciting world out there and there is so much to learn.
Learning is a life long process and won't stop after you leave graduate school.

Who knows? Maybe you will be authoring the next big Statistics textbooks!

[sbrodheadsr]

I concede that Supersampling needs to be supported in Fractal Architect, even though it is easy to do it yourself outside the product.
I will add Highlight power as a render parameter, just like Flam3. It is effectively set to a value of 1 right now.

As often happens, I awoke after a nap with fresh insights on AA (anti-aliasing). Combining an edge detection step with the anti-aliasing
might be a better way and may make costly supersampling unnecessary (maybe).
A quick Google search reveals I am not the only person who has thought of this. So in the coming weeks I will be experimenting with different anti-aliasing algorithms and lets just see what pops out!

Other experiments:
1) See affect on performance from using Chaotica's approach to making any variation type usable as a pre or post variation.
2) Provide an alternate kernel for fractal rendering where Xaos is not used. This should provide a good performance increase.
3) Revisit density estimation and see if this can be improved.
4) Drop the separate pre-fuse step and incorporate fusing it into the main render loop. This should help the problematic Intel OpenCL compiler handle
 bigger variation sets. Where the OpenCL compiles for the Intel CPU take a fraction of a second, compiles for the Intel Iris GPUs take over 2 minutes.
(What's going on Intel/Apple ??) I suspect the compiler is inlining the big IterateLoop with all the variation formulas in it.
5) Figure out how to do some of the recent JWidlfire innovations on this renderer.

[sbrodheadsr]

Apple released the bug fixes for Fractal Architect 3D as version 3.1.1 today.

The revised render performances for this version is posted here:  http://www.fractalforums.com/index.php?topic=18257.0
These render performance represent Apple laptop render speeds - not what a high end desktop can do.

Conclusion:
Just like for video gaming, it pays to get the best discrete GPU from either Nvidia or AMD.
In 2013, the Intel Iris integrated (HD 5000) GPUs are substantially slower for flame fractal rendering than a good discrete GPU from Nvidia or AMD.

Both the AMD and Nvidia GPUs beat the render times of their paired Intel i7 quad core CPUs by a factor of 3.6X (or 260%) - a whopping performance advantage.

These were measured on stock Macbook Pro's from 2011 and 2012.

[sbrodheadsr]

There were 7 tiles in the contest image. No one reported the correct number of tiles.

If you can't find the tiles in a rendered image, there can't be a quality issue from tiling.

The software allows you to restrict the amount of memory used to render an image, thus forcing tiling to occur.
It is a feature that is a handy tiling testing tool, but not really very useful for users - unless you want to run some other program
that needs a good amount of GPU video RAM.