algorithm based on:

> Fractal Dimension of Dielectric Breakdown
> L. Niemeyer, L. Pietronero, and H. J. Wiesmann
> Phys. Rev. Lett. 52, 1033 – Published 19 March 1984
> Abstract
> It is shown that the simplest nontrivial stochastic model for dielectric breakdown naturally leads to fractal structures for the discharge pattern. Planar discharges are studied in detail and the results are compared with properly designed experiments.

· · Web · 1 · 0 · 1

first image upthread has the power parameter at 100, pretty sure the rectilinear stuff is an artefact of the pixel grid. with power 10 the lines are much more wiggly (image coming soon)

Show thread

something went bad in this one (power 10), don't know why the thicker vertical/horizontal lines are there... they're not there in the previous image with 1/2 the iterations, but the texture is not so full....

Show thread

tweaked some parameters and it went all weird - this one adds (alpha * (number of boundary pixels) ^ beta) new points each step, with alpha = 0.5 and beta = 0.25.

Show thread

takes a couple of minutes for an image at this resolution, but going bigger is slow - I guess it's O(dpi^4) which means doubling pixel dimensions will take 16x as long...

guess is because it's definitely O(dpi^2) per added pixel (need to solve Laplace equation for electric field), and number of added pixels is probably O(dpi^2) itself (to get to a fixed image density, the tree is 33% filled). pixels (actually, rasterized circles getting progressively smaller) are added one by one, with field solving in between each.

Show thread

added a horizontal shift when plotting each circle (think this one was 1x radius)

Show thread

Part of the algorithm is solving the Laplace equation for electric field strength. I do this by repeatedly applying boundary conditions, blurring, and normalizing. Typically I do 16 or more iterations of this between each next point selection and plotting, because when doing only 2 the image looks weird. But I somehow like the effect, not sure how to control it better...

Show thread

the boundary conditions also constrain it within the frame. can also add additional constraints, like the hole in this one. obvious next step is reading a mask from a bitmap graphic file instead of defining it with code.

Show thread

another variation, using the output as a new mask for another stage

Show thread

@mathr Hey Claude, how are you generating this? Are you using some C graphic library?


I'm not using any special libraries beyond libc and libm. But I do use OpenMP pragmas for parallelism to speed it up.

I'm outputting PGM files (raw uncompressed 8bit greyscale raster bitmap data with a simple ASCII header). Actually my data is 1bit black and white, but packing it into PBM files is something I've not got around to yet.

unsigned char pgm[H][W];
// ... calculate image ...
fprintf(stdout, "P5\n%d %d\n255\n", W, H);
fwrite(&pgm[0][0], W * H, 1, stdout);

Then for some of the images, I use potrace to vectorize then upscale the vector version (mainly for printing, because 60dpi looks bad on paper...).

@mathr Oh, this is smart and cool. And also lightweight. I'll try to experiment a bit with PGM, it seems reasonably easy to manage. Thank you for the source snippet :)

Sign in to participate in the conversation

Welcome to, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.