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

Hello,
I'm new here. I'm just playing arround with the renderer I've written. So 2D fractals and mandelbulb went fine. But when it comes to the mandelbox I don't know at which number I have breake the loop of iterating. Is there something like in the mandelbulbs if magnitude(v)>2 it diverges?

I've read something like that if it's a scale 2 fractal it diverges if magnitude(v)>6 and magnitude(v)>2 for fractals with negative scale. But that doesn't work for me. It only rendered a cloud of points. I had to put the limit to 11 (at scale 2) and it worked fine.

Is there any relation between the scale and the escape value? (some formula?)

Well, here go some pics:






A mandelbulb (cosine version)



And a test with environmentmapping



By the way, very nice forum! It helps me a lot!
(and sorry for my english, I hope you understand what I mean)

but you have to keep in mind that the mandelbox uses a bit greate value for deciding if the formula escapes,
the mandelbox is "bigger" than the mandelbrot, i think it covers -6 to 6, so checking for abs(z)>6 should do the trick

as a side note:

the bailout condition is always just an "optimisation" or "heuristic" it can be as big as you like,
the "inside" points will stay inside, regardless which bailout condition you take, and the others just
bailout a little later when using a bigger bailout value, so shifting of colors could occur, so, as a
general rule: "it doesnt matter how big your bailout value is, your inside/outside test will yield correct results, but keeping this
value as low as possible can dramatically decrease your rendering time!"



some coloring algorithms need BIG bailout conditions to look good

ah yes, its 3d
but all in all you are correct, you can experiment with it

Try with 60 iters and bail 1024, it should look perfect

I am not so expert of these details, ask Buddhi or Jesse ... Or look at Buddhi's source code it should be very handy

You need to implement some dynamic level of detail, depending on distance and projected on screen error.

That's what the raymarchers all do and how you get decent pictures from near to far without getting the pixie dust appearance for high iteration counts like you show earlier in this thread. Yet you want the high iteration count for detail nearby.

See for instance http://code.google.com/p/boxplorer2/source/browse/trunk/cfgs/menger.cfg.data/fragment.glsl#215
and how m_zoom gets used further down that main() to control the raymarching end condition.

In general, the simple .glsl fragments that implement some of the formulae are pretty instructive and self-contained. See source for boxplorer, boxplorer2, fragmentarium, http://fractal.io and various posts all over this forum.

Have fun!

Right, a proper distance estimation will give smaller and smaller estimates until you run out of numerical precision.


With the raymarching approaches you get occlusion culling for free and easy access to lots of raytracing techniques like reflection, refraction, shadowing etc. But you have to compute for every new view.

Keeping a voxel cloud of interesting detail in memory is going to be challenging real quick.

The distance estimation functions for the various fractals are hard to come up with and kind of magic at first.

If you are still interrested, here is the post where I have given the formula of the size of the mandelbox.