END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

This is one octant of the power 8 Mandelbulb. Sampled on a 1280^3 grid, rendered in the usual ... ahem ... quality.

http://www.vectorizer.org/insideMandelbulb1HD.mp4 (30 megabytes)

Very nice, and organic too! Reminds me of Mole's house in Wind in the Willows!

WOAH! 

I used the non-trigonometric formula. And modern computers are really fast; I remember when an eight bit machine took a week to compute a 2D Mandelbrot image. Nowadays, we can go hunting for three dimensional fractals, and render them with sophisticated simulations of the physics of light, all for animations rather than still images.

Modern computers are fast, really. I made no effort to tune the code, because it was already compatible with my patience.

My current renderer is limited by the amount of main memory. Some of the animations you saw would not have been possible to do on a 32 bit machine. Flight paths close to the surface are especially demanding: you need to sample the traversed space at a fairly high voxel resolution to be able to see details of the surface. But the flight path's relative length (in terms of how many voxels seen in total) increases, too, with proximity to the surface. Both effects combined quickly lead to huge volume data sets.

Rendering algorithms that produce each frame of an animation individually eventually have an advantage, even when they do not try to re-use information from other frames.


I am tinkering with other approaches, but it might be a while before I get a grip. Some of the things I learned from my first attempt at rendering 3D fractals are:

1.
Euclidean distance transform is not really required, because "iso"-surfaces at larger distances are neither smooth nor informative. It suffices to know "exact" distances no more than a single voxel away from the surface. This means the "Sum of Absolute Differences" is really enough (when you are just one voxel away from the feature voxel, SAD is equal to squared Euclidean distance). Computing the distance transform for that metric is much faster (even massively parallel if you do it right). You can still use inbounding spheres (which are then octahedra) with that distance metric.

2.
Storing uncompressed volumes with high voxel resolutions in main memory is just not a good idea. :-)


My next attempt will probably be based on an octree. It won't work as well as it does for the smooth surfaces of human designed geometry, but it should be worth trying even for fractals. The distant dream is to store a potentially very detailed volume on disk, and just pull in the few octree nodes that are needed for the current view point. Ideally, the octree would be refined on demand, and the new nodes added to the file.

nice! - I think a shallow rotating zoom in on a cut section could be good also, to see the detail change around the edges of the cut of the section!

You are too kind. "Technically best" is not a description I would use. I rather think of these as "better than nothing".

BTW, the octree approach still looks promising; I found good solutions to all the little conceptual problems that came up so far. In the process, I noticed that all the interior surfaces I presented here are slightly imprecise. Nothing major, but there is room for improvement.

And if I ever manage to find a good heuristic to skip sampling the boring empty space far from the surface, the octree approach should enable "unlimited" resolution together with adaptive level of detail. In other words, if I put in the effort to develop this, I should eventually be able to produce images that strike the perfect balance between noise and infinite fractal detail ... but it's going to take time.

If you are going to try an octtree and guessing you might want to check out my program at http://www.fractalforums.com/mandelbulb-implementation/yet-another-realtime-viewer/.

It does quite aggressive guessing which it then later repairs using information from neighbouring cubes when they get further subdivided. Basically it looks if all voxels in a small volume is of the same type and then sets the current one into that type, it stores info about guesses though so when something close by gets set to opposite value it can redo the guessed areas. Only its a more complicated and in several layers in order to actually be faster than calculating