News: Check out the originating "3d Mandelbulb" thread here

## The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!

 Pages: [1] 2   Go Down
 Author Topic: True 3D Julia  (Read 33524 times) Description: 0 Members and 1 Guest are viewing this topic.
Buddhi
Fractal Iambus

Posts: 895

 « on: July 11, 2009, 02:58:02 PM »

Hello!

It's my first attempt to render true 3D Julia Fractal. I used Quaternions to calculate fractal (like David Makin). Main formula is:
newx = x*x - y*y - z*z - w*w + julia_x;
newy = 2.0*x*y + 2.0*w*z + julia_y;
newz = 2.0*x*z + 2.0*y*w + julia_z;
neww = 2.0*x*w + 2.0*y*z + julia_w;

Julia coordinates:
julia_x = -1.47409435510635;
julia_y = -0.00043243408203125;
julia_z = 0.00043243408203125;
julia_w = 0;

http://www.fractalforums.com/gallery/?sa=view;id=733
 « Last Edit: July 11, 2009, 08:30:39 PM by Buddhi » Logged

Buddhi
Fractal Iambus

Posts: 895

 « Reply #1 on: July 11, 2009, 07:52:55 PM »

Another view and higher quality

http://www.fractalforums.com/gallery/?sa=view;id=734
 « Last Edit: July 11, 2009, 08:27:16 PM by Buddhi » Logged

cKleinhuis
Fractal Senior

Posts: 7044

formerly known as 'Trifox'

 « Reply #2 on: July 11, 2009, 08:22:40 PM »

phew this one is stunning somhow

 Logged

---

divide and conquer - iterate and rule - chaos is No random!
lycium
Fractal Supremo

Posts: 1158

 « Reply #3 on: July 12, 2009, 07:22:38 AM »

buddhi those are some pretty cool renders you've been posting!  i like the approach of pre-rendering to a large array first (good excuse to grab 12gb of ram!), and it allows the use of nice volumetric rendering techniques; might give that a crack at some stage.

keep up the interesting work
 Logged

Buddhi
Fractal Iambus

Posts: 895

 « Reply #4 on: July 12, 2009, 09:24:23 AM »

I will describe more precisely my fractal rendering technique.
Rendering process is divided into two main steps. In first step I render 3D array with fractal. My program renders it layer by layer (cross-sections) from z = z_min to z_max into sequence of JPEG images (quality 100%). When I want to render array of size 1500x1500x1500 pixels I have to render 1500 images with layers. I chose JPEG format because It takes less space in hard disk than BMP and with fast CPU it's faster to load (less amount data to transfer from hard disk).  Each layer is rendered in classic technique like 2D fractals. Pixels intensity are proportional to number of fractal iteration. When array is ready it's time for step 2.
It's difficult to visualise that big array 3D array on 2D screen. Fractals don't have surfaces and it's imposible to use standard 3D rendering techniques. It's not able (or I dont'y know how) to convert these arary of pixels to 3D triangles and calculate normal vectors of surfaces to calculate shades. I use completely anoder technique. It's something like raytracing but much more simple. From each pixel of 3D array where some details of fractal are present I send about 50 beams in nearly the same direction (45 degrees cone directed to light source) and analyse damping of light along beams. When beam is going through pilxels of higher values dumping is higher. In that way I acheve something like shading and shadows. When calculation of light intensity is done I put this pixel on screen with opacity proportional to numer of 3D pixel intensity (number of fractal iterations). Program has to do the same whith all of pixels of array where values are bigger than zero starting from bottom layer and back pixels. This alghotitm takes lots of memory. Memory cunsumption = array_width * array_height * array_depth when maximum number of iteration is 256 (only 8 bits per pixel). For example to render array of size 1500x1500x1500 program needs 3,3GB RAM memory. However this aghorithm is very fast because the slowest iteration calculations are made only one time. Of course to make this for example in C++ you need 64-bit compiler on 64-bit operating system because on 32-bit system there is limitation to allocate only 2GB of RAM by one process. One time rendered 3D array I can use to make many different vievs of the same fractal.

For writing my programs I use Eclipse SDK and I'm making everything in C or C++. Now I'm using Linux (Ubuntu) because only on Linux there is free 64-bit C++ IDE and this operating system is very good to operate with very large amount of memory. I have 4GB RAM in my computer and I tested this system with 11GB memory usage (virtual memory) and it works very well.
I each program I try to use all of four CPU cores by dividing rendering process into four threads. Sometimes it's very difficult to make but it's only way to achieve good deficiency on multi-core CPUs.
 Logged

David Makin
Global Moderator
Fractal Senior

Posts: 2286

 « Reply #5 on: July 12, 2009, 06:14:20 PM »

Fractals don't have surfaces and it's imposible to use standard 3D rendering techniques.

Just to point out that "Fractals don't have surfaces" is not strictly correct - they do have surfaces it's just that the true (infinite limit) surface is purely theoretical.
When rendering 3D/4D fractals the render always compromises by limiting the max. iteration depth and a given fractal formula at a given iteration depth does have a concrete, finite surface defined by |In(f(z))|=bailout i.e. the surface is where the magnitude of the nth iterate of f(z) is equal to the bailout value - the whole solid being defined by |In(f(z))|<=bailout.
As to ways of calculating the normals, I simply use the "found" surface adjacent "found" pixels method (or better still half-pixel offsets) that's good but doesn't show any sub-pixel detail - for that it's better to use a method such as the one you employ or to use the iteration density at pixel or sub-pixel offsets (or to find "solid" based on DE instead of iteration and do the same thing with the DE at pixel/sub-pixel offsets).

I'm still attempting to find a killer algorithm that will allow solid based on any colouring algorithm, see:

If no image above:

http://makinmagic.deviantart.com/art/Alien-Interface-ANIM-29854835

That's a Julibrot solid on orbit trapping but in order to get (almost) visually flawless results I had to severely limit the max. iteration count (<10), I want to develop an algorithm that will render something similar but at say 60 iterations or even higher visually "accurately" and in reasonable times but without having to use masses of memory.

These attempts at pure raycasting orbit-trap heightfields illustrate the problem:

http://makinmagic.deviantart.com/art/Orbit-Trap-Heightfield-128850151
http://makinmagic.deviantart.com/art/Orbit-Trap-Height-Detail-128912127
 « Last Edit: July 12, 2009, 06:16:02 PM by David Makin » Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
David Makin
Global Moderator
Fractal Senior

Posts: 2286

 « Reply #6 on: July 12, 2009, 09:40:43 PM »

Just to add that the problem here is that unlike using solid based on iteration/smooth iteration or solid based on Distance Estimation where there is a fairly smooth progression to "inside" in orbit trapping each separate orbit minimum is a hard break from the neighbouring minima (as can be seen in the detal version above).
 Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
Buddhi
Fractal Iambus

Posts: 895

 « Reply #7 on: July 12, 2009, 10:28:33 PM »

Some another examples of 3D Julia
Both of them has nearly the same coordinates. First is located on 2D surface (z=0) and second little below this surface. Second is much more transparent and has very thin contour.

coordinates:
first:
x = -0.817795
y = -0.2000035
z = 0
w = 0
256 iterations

second:
x = -0.817795
y = -0.2000035
z = -0.2000035
w = 0
256 iterations

When I optimise rendering code I will render some animation with morphing Julia fractal. Now I need about 1 hour to render one frame. I'd like to know what happen when move Julia point along fourth (w) dimension. Maybe somebody checked this?

About surfaces in fractals I'm agree with you that fractals has surfaces when we make calculation with some finite maximum number of iterations. But when iterations number is very high we have lots of separate points (when we have finite resolution of rendering) and edges are very irregular. Secondly I like to render 3D fractals with "fog" which density is proportional to iterations number similar to standard 2D Mandelbrot fractals. Sometimes it looks very interesting. Your method is also very good because you can add light reflections and I think needs less amount of memory to render. Could you write more details about finding normals? It's very interesting topic.

 Logged

lycium
Fractal Supremo

Posts: 1158

 « Reply #8 on: July 13, 2009, 12:39:21 AM »

for estimating the normal, you can use a central difference approximation to the grad of the potential function.
 Logged

David Makin
Global Moderator
Fractal Senior

Posts: 2286

 « Reply #9 on: July 13, 2009, 01:13:07 AM »

for estimating the normal, you can use a central difference approximation to the grad of the potential function.

Exactly - the only problem with this method is that at higher iteration levels it can lead to serious aliasing in areas where the iteration density changes are way sub-pixel.
It works much better for solid based on distance estimator than solid based on iteration - i.e. for DE use a central difference approximation of the gradient of the distance estimate.

 Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
lycium
Fractal Supremo

Posts: 1158

 « Reply #10 on: July 13, 2009, 01:17:47 AM »

on the other hand, buddhi has a perfect regularly-spaced potential function. this also serves to cap the variance of the normal estimate
 Logged

David Makin
Global Moderator
Fractal Senior

Posts: 2286

 « Reply #11 on: July 13, 2009, 01:31:31 AM »

on the other hand, buddhi has a perfect regularly-spaced potential function. this also serves to cap the variance of the normal estimate

That's interesting, I didn't realise that it would actually help that much, but then again I've never tried rendering them using a fixed grid - something which I now have an idea for in UF - at least for storing in a scanline format, for each zscan store distance to first solid, distance to first space, distance to next solid..... This would use massively less memory than rendering and storing whole 2D slices and I could probably do it in UF - even maybe saving a "whole" scanned object as a png image for import back into UF and rendering at any angle very quickly indeed.....
 Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
lycium
Fractal Supremo

Posts: 1158

 « Reply #12 on: July 13, 2009, 01:47:18 AM »

there are much more powerful optimisations you could make if you'd unshackle yourself from ultrafractal instead of rendering scanlines, if you render along vertical lines from bottom to top you can save a ton of traversal steps (draw it on paper and you'll see what i mean).

it's a bit of a mystery to me why choose to code in that hideous (and hideously slow) language, running the result on 32bit windows emulated on a true 64bit operating system!
 Logged

David Makin
Global Moderator
Fractal Senior

Posts: 2286

 « Reply #13 on: July 13, 2009, 02:21:15 AM »

there are much more powerful optimisations you could make if you'd unshackle yourself from ultrafractal instead of rendering scanlines, if you render along vertical lines from bottom to top you can save a ton of traversal steps (draw it on paper and you'll see what i mean).

it's a bit of a mystery to me why choose to code in that hideous (and hideously slow) language, running the result on 32bit windows emulated on a true 64bit operating system!

I hadn't considered along which 3D axis to do the scanlines
> hideously slow ?
Hmmm - I don't think that rendering a distance estimated 3D quat in under 5 secs (on this P4HT) at 640*480 is that slow....or a Menger sponge in 13.2 secs...
Example Quat (4.53 secs):

Also I can only do fractal stuff on this old P4HT or my core2duo laptop - the dual quadcore MacPro is the machine where I work - it's not mine unfortunately.
When I finally get a Mac I'll start writing some custom fractal software (Objective C/assembler), but I'm simply not prepared to use Microsoft development software anymore (unless payment is guaranteed) (same goes for Symbian)
 Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
David Makin
Global Moderator
Fractal Senior

Posts: 2286

 « Reply #14 on: July 13, 2009, 02:51:23 AM »

there are much more powerful optimisations you could make if you'd unshackle yourself from ultrafractal instead of rendering scanlines, if you render along vertical lines from bottom to top you can save a ton of traversal steps (draw it on paper and you'll see what i mean).

I hadn't considered along which 3D axis to do the scanlines

I meant I would render the step information to a 3D scanline buffer in the global section and then turn that buffer into an image for export - I didn't mean using UF's scanline loop section.
 Logged

The meaning and purpose of life is to give life purpose and meaning.

http://www.fractalgallery.co.uk/
"Makin' Magic Music" on Jango
 Pages: [1] 2   Go Down