Fractal prim

Ok, this idea is not completely gelled in my head, but... would it be possible to add a "fractal" prim? Set a few parameters, and presto! an interesting organic looking shape, possibly rendered client-side. It *should* be possible to pretty severely limit the amount of data needing to be sent to the client.

Someone who knows how the rendering stuff really works will probably explain that this is impossible, though.

neko

Custom made trees this way would RAWK.

LF

It's not "impossible" - in fact, it's something that's very much doable already if you're suici... err, have a death wi... um, enough prims and some free time. The rendering engine already does something like this with trees, as well as prim resolution.

Having a prim, say, draw several cyclical triangles on down in an algorithm is very feasible on the server level, since all you're really sending is the algorithm values on down with the prim's values. I wish you'd elaborate on "poof, organic shape!" though - that's a bit vague.

However, the difficulty arises in two different areas. First, how would something like this be made scalable and unabusable, such that lower-end clients would not crash to desktop rendering them? And second, how would something like this be made user-friendly such that residents without a degree in the subject could understand it?

Just picking your brain, Neko. I'd be interested in seeing something of the sort.

oh i can't wait to see the llGetPrimitiveParams([PRIM_TYPE]) for this

Well, you would want details and expose the fact that I really know very little about this stuff.

Well, maybe I know enough to be dangerous (just from 30 odd years of browsing Scientific American). Here's an example of a Java applet that creates a tree/shrub in 2 dimensions, based on a bunch of sliders:

http://id.mind.net/~zona/mmts/geometrySection/fractals/tree/treeFractal.html

This is based on a "V" shape. There are other starting shapes that could be more helpful, such as a "Y" shape, and the proportion between the trunk and the branches could be one of the parameters. (That way you could get this V-based bush shape as well as taller, more tree-like shapes.) Or, since we're talking about 3 dimensions, not 2, a stick-tetrahedron shape, a sort of 3-dimensional Y with a trunk and 3 branches spaced at the edges of a tetrahedron with one vertice on the trunk. (This would be much easier to illustrate in-world.)

Another parameter could be color. The color could get darker or lighter as it goes from trunk to branches, e.g. ranging from brown to green. Or the last branches could be a different color, e.g. white for flowers. There could also be an element of randomness in the branches, so that every tree doesn't look the same. (Such trees also wouldn't look the same each time they are drawn, or for each viewer. Er... it's a feature, not a bug....)

However, the fractal technique could also be used for rocks, clouds, crystals, sculpture, prim hair, etc. by using prism shapes and/or elliptoids, and overlapping the shapes. I couldn't find a good online picture or demo of a rock with a casual search, but I'll continue to look. Meanwhile, envision a central elliptoid, then overlap it with a couple more smaller elliptoids, somewhat rotated, whch are in turn overlapped... you get the idea.

This would be even more fun with hollow shapes. Anyone want to live in a giant snail shell?

A general creation mechanism could be something like this:

1 - create a set of prims, perhaps up to 5. They can be different shapes, perhaps different colors or textures. Link them. Select the linked group. Then choose the proposed "Generate fractal" command from the menu. You will have to "pay" for the original prim set, plus a small markup for the fractal information (possibly you could pay a markup per generation specified, say one extra prim per generation -- heck, I'd be willing to pay the whole set per generation, just not for each of the copies per generation).

2 - In the resulting popup-menu, set the duplication factors:

- Number of copies per generation
- Placement per copy with respect to the previous generation - probably this should be limited to points along the vertices of regular solids or something, e.g. pick a "cubic" or "tetrahedron" shape
- Rotation of copies with respect to previous generation
- Distance of copies from previous generation
- Size reduction (or could be expansion) with respect to previous generation - for maximum flexibility, allow this to be specified in 3 dimensions
- Number of generations (this should be somewhat limited, to avoid really expensive objects)
- Transformation of final generation -- just for fun, identify a different color or texture to apply to the final generation only. This would create things like flowers on plants.

To change the way the result looks, select the whole thing (the only option, at that point) and pop up the fractal menu again, and either make different parameter choices or turn fractal expansion off and fiddle with the base set. Fractal transformation parameters should be savable so you can re-apply them again later, or to a different base set. The Library should have some examples of fractal transformations and transformed items, e.g. some sample trees, rocks etc. that people can use as-is or play with. That should help get people started.

I know people have written scripts to generate fractal items. The thing is, you rapidly use up prims that way, and probably the cost shouldn't be that high. Adding this kind of transformation could dramatically improve the appearance of created items in-world by allowing for more natural looking objects (trees, rocks, crystals, clouds, etc) without dramatically increasing computational expense, bandwidth, and storage.

(Maybe I will write the script for the giant snail shell, though. )

Two-dimensional fractals for textures could be interesting, too, but people do have the ability to import textures, so I don't see this as quite the same level of desirability.

Ok, that's my take on it. Would other people be interested? Would what I've described be easy enough to use that it would get used? Would it crash the server or the clients?

neko

It's not a bad idea, but something still tells me it would be rampantly abusable and, frankly, it serves a niche as opposed to a definitive role, in my opinion.

However, remind me to show you my particle flower sometime. It generates a three-dimensional particle effect using a simple algorithm generated with polar coordinates, and three prims.

It gets me thinking, then, that perhaps a "particle tree" effect would be a good idea on the same premise. I have an active project and schedule that won't let up until well into next week, but remind me sometime and I just might take a whack at that.

Neat idea, but collision-detecting these thing would be a serious pain in the butt

Particle trees could be cool. Particle flowers on fractal trees would be even cooler.

Yeah, I hadn't considered the collision detection problem. I'd settle for only the first generation being physical, and the rest being phantom. (It would mess up my giant snail shell house, but I think I should script-build that, anyway.) Usually in fractals the subsequent generations are smaller and pretty close to the root object, so making the subsequent generations phantom should work ok.

That would make the whole thing a visual effect, sort of "particle trees for dummies." Would that really be so much of a niche thing? I do hear a lot of complaints about trees, the way they look, lack of variety, etc.

(If no one else has noticed, an awful lot of my feature suggestions seem to have fallen in the "give SL a more organic look" category... it wasn't a conscious decision on my part. Actually, I'm kind of surprised. I've never thought of myself as being that visually oriented.)

One thing I forgot to mention earlier is that the system as I originally described it could actually be used to generate a flight of stairs, by setting no size reduction and no rotation, one branch per generation. That would *not* work if generations 2+ were phantom, however.

I think the biggest opportunity for abuse using the system as I originally described it would be to make really big things. If you are limited to, say, 8 generations, and you make a 10m wall and tell it to make one child per generation at a bit of an angle, you could make a hollow octagon 38.28m across. Or you could have no angle and make a wall 80m across. I'm not sure why this would be a bad thing, but I've never understood the existing prim size limits. Supposing that you want to restrict things to the existing 10m boundary, I guess you could automatically shrink root primsets so that the entire fractal stays within 10m (and there goes my giant snail house, again).

This focus on snails must be from watching too many repetitions of RacerX's Snail Dude routine too late at night....

neko

From what I've gathered, it used to not be that way. However, the geometry and collision engine does not seem to like, say, 100m-tall prims (like the owner of a certain cyberpunk sim had rezzed in-world) - causing all sorts of collision and rendering problems while I was giving them a good looking-over.

Besides - I'd hate to see griefers sit in sandbox regions dropping 100m x 100m frying pans on a quarter of the sim. It's still possible... just not nearly as easy.

Anyway, the push for an organic look makes a lot of sense, as aesthetically, Second Life is a bit behind the eight ball with people expecting newer tech on the market to be incorporated automajically. Not that simple. However, I devote a lot of my time in-world to working with the system to do stuff like that... the 3D model importer being the first step, and if I can get my current project to work quickly... well, good things will come of it. I hope.

And yes, I'll look into the particle tree thinger - no promises though.

Jeffrey, I know you do spend a lot of time on this stuff, and I for one salute you on your 3D model importer. I haven't had the time (or the spare prims) to try it out yet, but I think it's very cool and a terrific idea.

Thanks for explaining about the collision detector imposing limits on prim sizes. I guess Havok2 wouldn't help that? (Whenever that happens....) But at least now I know *why*.

neko

neat idea but man that could generate a ridiculous amount of tris