Quote Originally Posted by adampjr View Post
wow. I really like the last output there. Are you going to make the program available when you finish?
Yes? I'd make both the source and the program avaliable. I'd want to do a quick UI on top of it (right now it's just a single command in the terminal), but I'd like to release.

Quote Originally Posted by waldronate View Post
One thing that you might try is to use an ellipse and rectangle rather than circle or square. These shapes give you an additional degree of freedom (aspect ratio), which might well get you more interesting shapes with fewer primitives.
Yeah, I think I'll probably do that. My other option was to read in vector shapes and use those, so I could theoretically have a "C" shape or something, but it might be that ellipses and rectangles are enough. Oh, and of course I'd need to have a random rotation of the ellipse and rectangle.

Quote Originally Posted by waldronate View Post
As far as the shapes themselves, they don't seem statistically different than the output of a slice through a fractional Brownian motion (fBm) surface or a simple wavelet noise surface. I suppose that's not surprising because the basic process is the same (add progressively smaller details to a basic shape).
Ehhhhh.... kind of. I'd love to see some kind of mathematical analysis to see if they were similarish, but I suspect the reason they look similar is because the third one was blurred and then thresholded, which removed most of the noise around the edges. If you go back and look at the first two I posted (the unblurred and thresholded ones) you'll see the noise I'm talking about, which doesn't seem like either of those you mentioned.

Now, are these existing methods better? Very good question...

Quote Originally Posted by waldronate View Post
If I understand correctly, you're generating an abstract shape tree and then rasterizing it, which would mean that performance would break down the generation phase and the rendering phase. Are you limited on the placement end or on the rendering end?
Ah, that was my first approach, yes; that approach quickly became too slow to be usable. A faster approach is instead to tie the generation in with the rendering: this means I don't have to save that massive tree, and am instead only looking at a part of it at a time.

i.e.:
Code:
DrawFractal( size, location )
   DrawRandomShape( size, location )
   GenerateRandomChildren()
   ForEach Child
      DrawFractal ( Child.size, Child.location )
Similar in concept to a depth-first search tree rather than a breadth-first search tree. In terms of memory use, this means I'm only keeping the size and the location on the stack (three doubles), and at each iteration of draw fractal I create a new shape on the heap, draw it, then delete it, so I don't consume as much memory.