Suggestions for building fractals in SL.

well, I've finally developed a few fractal generators with the SL engine, and I'm running into issues with how to present the fractals themselves. using prims can be very consumptive, a simple "dragon" fractal will easily reach over 2,000 prims by the 10th iteratation, and if I were to go the temp_on_rez route, even using distributed rezzing methods to bypass the greygoo fence, it still takes too long to rez the entire set before parts start getting deleted.

particles are very unreliable as well. using the basic "chaos game" to generate the pascal's triangle fractal, and a snowflake fractal, I used .01x.01 particles to display the points in the fractal set, which depending on the mood of the sim or computer sometimes looks great, and othertimes looks like a messy blob.

So my question is: is there another way to try and display thousand(s) of points (pixels if you want), within a fast time frame that is not detrimental to the sim (ignoring prim count concerns)

The only thing that comes to mind... Since fractals are recursive functions, let rezzed objects rez their child(ren). That way you don't have 1 object rezzing all, but all objects rezzing others (until they've reached a large or small enough size for example, to prevent endless rezzing). That should increase the speed.

As for saving primcount... not a clue in this case, sry.

First I'd try particles at a larger scale, unless that's already been tried. It's not completely superstitious: I've had experience with smaller particles exhibiting more flakiness. At best, particles will suffer the limits of the environmental particle load, viewer settings, and the fickle temperament of llParticleSystem, but it should be easy to paint and repaint a lot of them quickly without hitting parcel prim limits.

My hare-brained Plan B would be a lot more work: constructing a very complex texture, sorta like the XYtext scheme, and paint an array of prims with m-by-n "pixel" chunks of the texture, where the texture offset selects the appropriate configuration of on/off pixels. (First intuition would be m=32 and n=1--kind of a raster line segment--with offset into the texture corresponding to the 32-bit value of the on/off "pixel" bits.) The complexity here is manifold: texture creation, offset calculation, and the need to precompute and store each iteration before displaying any of it. But it should reduce prims 32-fold (or perhaps more, with a more ambitious texture-offset-indexing scheme).

[Edit: On further reflection, that would be a *very* complex texture. At minimal resolution, it would need 32 x 2^32 pixels... possibly 2 x 2^30 if one could take advantage of symmetry and inversion. On the plus side, one could use the XYtext 1.2 scheme of a squashed, cut, hollow prism to expose 5 faces of the prim, meaning the primcount reduction would be m x n x 5, possibly making a smaller value of m still worthwhile. And if one actually got all this working, hey, virtual black-and-white graphics-on-a-prim! ]

Maybe you should use an external web server. Send the parameters, and the web server generates a texture which you get back. Something along those lines?

unfortunately, even "low rez" fractals using 5 prims per iteration hit the greygoo fence after about 4 iterations using this system. This was in fact the first method I attempted using, but had to resort to distributed rezzing because of the grey-goo fence.



I haven't thought of that yet. I'll see how well that works out.