3D fractals

[Duncan C]

I've finally gotten around to teaching my application, FractalWorks, to generate 3D fractals. I'm pretty happy with the early results. Here are a couple of samples:

(click the picture to see the larger "original" version on pbase.)


(click the picture to see the larger "original" version on pbase.)


(click the picture to see the larger "original" version on pbase.)


Duncan C

[cKleinhuis]

wow, how do you generate these images ?

with a triangle mesh ? and a heightmap, respects!

i am also trying to render heightmap, but i have to use exorbitant high resolutions to achieve those results, i use opengl for
that...

some questions:
how big is the mesh ? rendering time?

[Duncan C]

wow, how do you generate these images ?

with a triangle mesh ? and a heightmap, respects!

i am also trying to render heightmap, but i have to use exorbitant high resolutions to achieve those results, i use opengl for
that...

some questions:
how big is the mesh ? rendering time?

Trifox,

Yes, I used a height map, and generated a triangular polygon mesh (triangle strips, to be more specific) in OpenGL.

How big the plot I use varies. Sometimes I can get good-looking results from an 800-800 source plot, and other times I need to go quite a big larger, like 2000x2000 pixels. I think the " Swirly Grape Julia 3D" image was created from a 2000x2000 plot.



I'm currently creating a mesh with a vertex for every pixel in the source image. I'm thinking of adding an option to do some averaging or other type of antialiasing to make the highly detailed parts of the plots look better. (I was just getting ready to post a question on that subject to the programming forum when I saw your post.)

I first generate my fractal and save a float value for distance estimates (DE). My app is highly optimized, so typical (2D) plot times are well under a minute on my Intel Core2 Duo MacBook laptop (2.4 gHz). The "Swirly Grape Julia" image, for example, takes about 11.5 seconds to render in 2D at 2000x2000 pixels with DE turned on. (It renders in a little under 4 seconds with DE turned off, because I can do boundary following with DE turned off, and calculating DE is pretty compute-intensive on it's own.) I may go back and add the continuous potential algorithm as another option, as it gives different looking results and is less compute-intensive than DE.

I then go back and massage the data into a height map, which involves finding the max value, taking the log10((max-DE)+1) for each pixel. I then scale THAT to 0-1 and do some further tweaking on it using a non-linear scaling formula I came up with that lets me adjust whether I increase the slope of my height map at high "altitudes" (height values) or low altitudes, while compressing the slope at the other extreme.

Building the height map and rendering the 3D image takes a second or two for a 2000x2000 vertex image (my laptop has an NVIDIA 8600 graphics chip, which is a decent performer). My latest version creates a "display list" out of the mesh, which speeds things up tremendously if you want to rotate or manipulate the final image. Manipulating a big mesh like a 2000x2000 is a little jerky when using a display list, but it's useable. It wasn't useable when I was drawing the mesh for each screen refresh.


Duncan

[cKleinhuis]

oh, i see, rendering time is quite quick

i use a rather time consuming aproach to gaussian blur my height map, because i use an rather dynamic approach, i use grids of e.g. 128x128 and then i render different 128x128 grids aside of eachother, so that i can generate successive a larger map, but this blurring costs so much time if you have to take into account consistency at the borders, so each grid as a non visible border with the size of the blur radius, this leads to heavy redundancy ...

and calculating normals of that smoothed mesh is also a pain in the ass ...

the algorithm described is the one used in mutatorkammer

i am also searching for a way to extract/smoothen out peaks of high iteration wich are very small, especially in the borders ... \

[Duncan C]

trifox,

See my post in the programming forum. I'm also looking for a way to smooth the "gnarly bits" closest to the Mandelbrot/Julia set. I was thinking of using averaging of neighboring pixels.

I would do those calculations on my height map before rendering it as a polygon mesh. I would think you should do that too. Why create a whole series of 128x128 meshes? I would think that would be MUCH slower, since it would greatly increase the back-and-forth between the main processor and the graphics card.


Duncan

[Duncan C]

-snip-
and calculating normals of that smoothed mesh is also a pain in the ass ...
-snip-

Why? I'd suggest doing all your smoothing on your heightmap data when it's just an array of floating point numbers, then building the mesh at display time.

My code builds an arbitrary sized mesh. Right now it's as big as my source 2D plot, but I may change that, and enable meshes that are smaller than the source plot and use smoothing of some kind.


Duncan

[cKleinhuis]

-snip-
and calculating normals of that smoothed mesh is also a pain in the ass ...
-snip-

Why? I'd suggest doing all your smoothing on your heightmap data when it's just an array of floating point numbers, then building the mesh at display time.

My code builds an arbitrary sized mesh. Right now it's as big as my source 2D plot, but I may change that, and enable meshes that are smaller than the source plot and use smoothing of some kind.


Duncan

I would do those calculations on my height map before rendering it as a polygon mesh. I would think you should do that too. Why create a whole series of 128x128 meshes? I would think that would be MUCH slower, since it would greatly increase the back-and-forth between the main processor and the graphics card.

zes, i am doing the smoothing before but i will stick to the series rendering, because you can see the image grow, this is meant to be used for wide area rendering, i want to set the camera perspective, an then render every 128x128 plane with is visible from the camera, up to the horizon ....

[twinbee]

Hi Duncan,

Those are absolutely smashing, particularly the first one. Please generate some more!

Any chance of increasing the height map, and have the camera near one of the peaks for that extra sensation of 3D and dizziness feeling?

[this is not kasker]

I really like the last one, the angle gives better perception of depth than the birds-eye view.

[Duncan C]

Hi Duncan,

Those are absolutely smashing, particularly the first one. Please generate some more!

Any chance of increasing the height map, and have the camera near one of the peaks for that extra sensation of 3D and dizziness feeling?

Twinbee,

Thanks for the kind words. I just played with some images where the camera is near a peak, and I couldn't get an image I really like. I'll play with it some more. Do you have some sample images with the effect you like?

There are more samples of my recent 3D plots here: http://www.pbase.com/duncanc/fractal_images


Duncan

[cKleinhuis]

the close rendering of a high peak involves rendering of far away parts of the fractal, because you have to render
up to the horizont, or at least close to the horizont, this involves level of detail handling ( far away parts do not need the full resolution )

i think this is the biggest problem when rendering from a high peak ... 
 

[twinbee]

Well, just a little bit less "bird's eye view" I suppose. So doesn't have to be right next to a peak (though that would be awesome, so long as it doesn't completely dominate the picture). But it'd be nice if you have the camera more diagonal, so that it's tilting towards the horizon more - perhaps something a bit more like this.

P.s. I really also love your "Douaday's Easter Rabbit" pic.