Welcome to Fractal Forums

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 (http://www.vectorizer.org/insideMandelbulb1HD.mp4) (30 megabytes)

A little bit dusty but beautiful hobold!
Wish I could do that...

A zoom in is always nice...  O0

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

I forgot to mention: 1000 iterations.

WOAH!  :o

Looks great :D
More cuts through the Mbulb like this one would be nice :D
They might help getting a better feeling for the internal structures...

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.

 :D
Often rendering time is compatible with my patience too...

I see a nice flight path right here... O0
( hard to see on the still, clear in your animation...  )

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.

A closer look on what I guess is the "tower". The apparent smoothness is somewhat deceptive; there are quite a few tunnels running below the surface. But the cracks are narrow, so they are hard to see.

http://www.vectorizer.org/tower2HD.mp4 (http://www.vectorizer.org/tower2HD.mp4) (40 megabytes)

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!

Great videos. From a technical view this are (up to now) the best movies to get an feeling on the "real" mandelbulb set (the set with infinite iterations).

There  seems to be at least 2 different types of towers (or spines) in the 8-Mandelbulb.

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.

Much luck with that, sounds good :D

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 :)

I don't have windows installed, so I can't play with your program, but the hints are very welcome! I am not really aiming for realtime rendering, let alone realtime sampling of the volume (I still have this crazy plan to go with very high iterations, and possibly very deep zooms later on with multiprecision arithmetic). But I am trying not to rule it out by a bad software design.

It seems as if I could store an octree node in just 32 bits (at least for the case of truly binary voxel data), and still do reasonably fast ray traversal. This is loosely inspired by the realtime ray tracer of Saarland University, the OpenRT project. Their publications are a good read.