Welcome to Fractal Forums

"Real" 3D Mandelbrot attempt

(http://www.fractalforums.com/gallery/0/141_18_06_09_1_36_51.gif)

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=695

Created using Ultra Fractal.
A rotation around the largest minibrot located at around -1.76 on the real axis - showing the large Mandelbrot in the background.
Just z^2+c where z and c are 4D using the 4D ring I described in this thread:
http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/msg7235/#msg7235

excellent work !

this really comes close to what simple minds understand of a 3d mandelbrot :D

 :police: :police: :police: :alien: O0 O0 O0 O0

Cool, love to see higher res version...

Your wish is granted, see:

http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/msg7346/#msg7346 (http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/msg7346/#msg7346)

or:

http://makinmagic.deviantart.com/art/quot-Real-3D-quot-Minibrot-126708978 (http://makinmagic.deviantart.com/art/quot-Real-3D-quot-Minibrot-126708978)

Maybe post a sliced image, top half missing, to show the normal 2D M-set cross-section in context?

Will sort something out...
I wish I could get a few days off from "real" work to concentrate on 3D+ fractal rendering, I'm not progressing very fast on creating UF5 classes for general ray-tracing :(

Hi, in case you miss them:

http://www.fractalforums.com/gallery/?sa=view;id=700 (http://www.fractalforums.com/gallery/?sa=view;id=700)

http://www.fractalforums.com/gallery/?sa=view;id=701 (http://www.fractalforums.com/gallery/?sa=view;id=701)

One more, another cousin of the "True 3D" Mandy.
This one is very complicated in detail, I have a hunch that it's truly fractal in all dimensions :)
The small image in the bottom-right is the "full" Mandy, the red box showing the location of the full-view (same location and parameters as the other recent renders I've done of the minibrot).

(http://fc03.deviantart.com/fs46/f/2009/173/7/9/__Real_3D___Mandy_cousin_by_MakinMagic.jpg)

If the image above doesn't appear, go here:

http://makinmagic.deviantart.com/art/quot-Real-3D-quot-Mandy-cousin-126890045 (http://makinmagic.deviantart.com/art/quot-Real-3D-quot-Mandy-cousin-126890045)

Multiplication table for the unit vectors for this one:

* |  r   i   j   k
----------------
r |   r   i   j   k
i |   i  -r  -k -j
j |   j -k  -r  -i
k |  k -j  -i   r

those speckles are why i use a probabilistic ("cloud") intersection algorithm: there is essentially no surface there (i.e. there is no fixed step size that will give coherent results).

also, when doing a close-up zoom like this you'll want to use a much smaller step size to eliminate the "layering" artefacts.

I'd be interested to see what your algorithm makes of this one :)

I reduced the step-size by a factor of 10 on this one compared to the others, I didn't try reducing it further because even the render I did took 35mins at 640*480 ! (At the moment my step-size reduction algorithm isn't as "smart" as it should be - it reduces *all* step sizes when ideally it should only reduce them as the solid is approached, though actually for most of the errors I get with this algorithm I think that simply: for a given ray after calculating the next step size check that step size against the current minimum at that iteration depth, if it's larger than the current minimum for that iteration depth then step the current minimum instead, if it's smaller then update the current minimum).

Just to add that in the solid on iteration density algorithm then there is always a definable surface, as there is using distance estimator, or indeed plain solid on iteration - in all cases the surface is not the ultimate limit of iteration (which is truly undefinable) but a finite approximation.
The speckles and other errors appearing in the renders using my "solid on iteration density" algorithm are all down to errors in the calculation of the next step-size when ray-tracing.
Essentially the algorithm is flawed in that because it's using solid on iteration density the step sizes should actually be based on the iteration density density rather than just the iteration density itself which is the case at the moment.

hi there, i just want to say ....

would it be easier to perform ray intersection tests on an untransformed object ? i mean, wouldnt it be cooler
to generate a true 3d model of the formula by just tracing horizontal/vertikal/straight depth lines to create a
surface ? it could be done using a simple 3d value field, and then isocountouring the value field to extract a surface?
i know this method would result in large arrays, and poor 3d model resolutions, but if a little bit tweaked ( render sub blocks
extract geometry, render next block ) it could lead to good results ...   i just mean, that the ray tracing attempt
has similar disadvantages ( rough surface, even bigger errors when missing an "inside" volume element ) so that another
method could lead to better results ... the resulting iso-surface could then be "global" illuminated as usual ...

 O0 O0

You *can* do that - just use some of Terry Gintz software (e.g. QuaSZ) to render 3D fractals and then export them in the format you want for your preferred standard-3D rendering software such as Bryce or 3DSMax or Lightwave or Maya or whatever.
The drawbacks are that for the sort of resolution I'm attempting in UF the export objects would get very large indeed and of course you have to use more than one piece of software to produce the final result (though I expect you could perform the entire process in Maya) :)

On the subject of rendering and getting the surface - I sincerely hope this converts nicely to 3D from 2D.
In the other thread on the "True 3D" Mandy I mentioned the possibility of solving: z = p + a*d and |In(z = z^2+c)|=@bailout for "a" where p is our viewpoint, a is the distance to step, d is the unit direction vector for the viewing ray and In(z^2+c) is the iterate of z^2+c to a given iteration depth n, well here it is in 2D - note that it's fairly sensitive to the various values used so I'm not sure how well it will perform for fractals other than plain z^2+c.
Basically it's a directional distance estimator - note that I found I had to use cabs(In(z=z^2+c)) and the "correct" bailout value instead of the usual || and the squared bailout.
Unfortunately this method also requires the derivative, so at the moment I only know how to apply it to Julibrots, Quaternions and standard Hypercomplex.
Just copy and paste the whole thing into UF :)
Try it using a specified direction vector.
For comparison there's a (very slow) binary search alternative in the colouring formula.

At the limit of iteration, also just to add that rendered in a high enough resolution (or with large enough over/down-sampling), it would appear like fog anyway. Perhaps zooming in far enough (even if it takes 10^(10^(10^10)) etc. zooms) would show a clearly visible surface as well.

It would, provided that the algorithm for finding the surface works will enough at higher iterations.
Generally the problem is that to zoom into 3D fractal objects (accurately) increasing the detail shown proportionately requires say a minimum of time*8 for a doubling of the detail.

Wooo-hoooo boy does it work !!!

See my very first largish test render:

http://makinmagic.deviantart.com/art/Quat-Minibrot-test-render-127116649 (http://makinmagic.deviantart.com/art/Quat-Minibrot-test-render-127116649)

Now to impliment it for standard hypercomplex....unfortunately I suspect it won't work for Julibrots but I may be wrong.
Note that it doesn't allow low-iteration i.e. low detail rendering, you can control the detail but the minimum possible starts much higher than using other methods due to the nature of the algorithm.

OK so I haven't tried it on the hypercomplex version yet but I simplified and improved tthe method and now I'm seriously smug:

http://makinmagic.deviantart.com/art/Improved-Quat-Minibrot-127157826 (http://makinmagic.deviantart.com/art/Improved-Quat-Minibrot-127157826)

And finally....

(http://fc05.deviantart.com/fs46/f/2009/177/8/8/Final_Quat_Minibrot_by_MakinMagic.jpg)

If the image above doesn't appear then go here:

http://makinmagic.deviantart.com/art/Final-Quat-Minibrot-127356427 (http://makinmagic.deviantart.com/art/Final-Quat-Minibrot-127356427)

On further investigation I discovered that the algorithm I was trying for distance estimation was just the standard method in disguise - and the standard method works better :)
However I was tryng to find a better method because I wanted a method that allows you to render 3D/4D fractals such that the distance from the "inside" is fairly large and when using distance estimation this leads to visible "stepping" on the images.
In my iteration density method this issue was fixed by performing a binary search when solid is found to get the exact boundary and I'd previously tried implimenting this method for when using DE and failed to get it to work properly, however, convinced it *should* work I tried again and fixed the mistake I was making and this result was obtained using that method.

Cool shape generally, (and nice zoom in), though it does seem almost equivalent to the lathe / 'vase' version of the 2D mandelbrot spun round its own axis... (still, wouldn't mind seeing it raytraced)

Well that's exactly what quaternionic Mandelbrots produce :)
By raytraced I take it you mean either rendered to object format for use in a normal 3D renderer ? Or just with full ray-tracing including shadows and better lighting ? It is raytraced but only using plain diffuse lighting directionally from the viewpoint.

I've been trying to get a better algorithm for rendering the "Real 3D" Mandy based on DE but it's looking like the only way to do so is to correctly get and use the derivative and use full DE - using the directional density along the viewing ray does not work very well for various reasons, I managed to get it rendering a quaternion pretty accurately around 4* slower than using full DE but when I plug in the 4D maths for the "Real 3D" version instead it renders pretty accurately but takes 15 to 20 times longer than the quaternion version !! I guess that's an indication of the complexity of the maths involved in the "Real 3D" version as compared to quaternionic or hypercomplex maths i.e. it must fold/warp the 4D space in much more complex ways.

OK I now have two algorithms that work pretty well without requiring the derivative. They both work based on the directional iteration density at each step along the viewing ray, one based on the classic "s = u*t + 0.5*a*t^2" and the other loosely based on the Newton step i.e. f()/f'(). The problem with both methods was that a ray passing close to "solid" but missing would then give large values for the calculated step distances just after passing the solid - the solution (as I mentioned above) is to check each new step size against the minimum for the given iteration depth (for that ray) and if it's larger then use the step size for that depth instead, otherwise use the step distance *and* store it as the new minimum for that iteration depth - I also test and conditionally store it for the next 3 higher iteration levels.
Both these methods produce results comparable to full distance estimator and both are between 3.5 and 4 times slower than full DE when used on quaternionic or standard hypercomplex fractals *but* both methods will work when you can't efficiently get the derivative and also for Julibrots and similar formulas where DE has issues in any case. The method solving "s = u*t + 0.5*a*t^2" for t is probably slightly better overall and in that case you have to check for "a" being zero otherwise you get specks (even in the middle of enpty space) - use s=ut instead here :) However if the main iteration loop of the fractal is slow (e.g. involving transcendentals) then the f()/f'() method will be better since that only requires the single delta value not the double delta i.e. you only have to iterate at step and step + a bit rather than at step, step + a bit and step - a bit.
Note that 3.5 to 4 times slower (on quaternions and standard hypercomplex) than DE is still around 8.5 times faster than my old routine - though just out of interest I'm going to try the iteration depth limitation trick in that routine too and see how much it helps :)

I rendered the same place using my 3D engine. You're right, it's VERY complicated in detail!
(http://www.fractalforums.com/gallery/0/640_26_07_09_2_07_17.jpg)

how do you define the formulas ?
what if i would like to see sin(z^2)+c ?
:D

Ah, thanks !! I think that gives us more idea what it's really like - no wonder I was having problems rendering it :)

It looks like it may not be connected ? How to find out.... (beyond my math theory skills).

Errmmm - good luck on that ;D
I guess something *may* be possible ? I don't really know enough math theory.

Hi
I returned to Twenbee's calculation method, that is triginometric translations instead complex numbers. Look at results:
(http://www.fractalforums.com/gallery/0/640_29_08_09_8_17_22.jpg)
http://www.fractalforums.com/gallery/?sa=view;id=880
http://picasaweb.google.com/buddhi1980/Fraktale#5375450879366556658

Resolution: 1500x1500x1500
Multisampling: 2x
Maximum number of iterations: 256
Render time: approx. 20h

congratulations,  awesome object!  O0

Very nice render!
Is the fog around the object part of the calculation or simply a buddhabrot background?

On the background there is Buddhabrot fractal. Mandelbrot 3D has also some fog around which transparency is depended on iteration count. For reflections (environment mapping) I used the same bitmap as for background.

Reminds a little bit of Half-Life's Xen.

Wow, this is probably my fave one so far of the 3d brots. Congrats! The composition and lighting is superb (nice one for using two different colored light sources).

How long did it take to render? Did you use global illumination, and do you think a higher iteration would provide even more detail?

Hi
I use only one light source and colours are from simple reflections (environment mapping http://en.wikipedia.org/wiki/Reflection_mapping).

It took about 25 hours. 20 hours for rendering slices. I used 3D anti-aliasing (2xoversampling - 8 times more voxels to calculate) for achieve smother surfaces and trigonometric calculations are slow. 5 hours for 3D rendering with shading, lighting, reflections, and also anti-aliasing.

No, I didn't use global illumination. This algorithm should be to slow to render 3D fractals with transparent fog.

I used 256 iterations. Unfortunately algorithm for calculating normal vectors causes smoothing details.

Heh, i never tried to imagine the Mandelbrot in 3D form like this. This is pretty amazing.. 

Are you doing any more unit vector renders dave? I know the theory seems to be pulling away from a unit vector approach but i still think it will produce interesting results.

Yes, but trying new formulae is on hold at the moment, I'm currently optimising the formulas for Mandelbulb and Juliabulb and tidying up my wip3D formula generally - it started life as a 3D IFS formula and there's still junk left over from that use such as an option for colouring based on genetics which is obviously not applicable for normal escape-time fractals.

based on genetics?

As I said, it was for IFS and for IFS (using the deterministic method either convergent or divergent) you have a tree of transforms and the branches taken down the tree to reach a given point gives you a "genetic" code which my 3D IFS formula allowed you to use for colouring purposes.

ah, ok, IC :)