Section Radius

What I'm proposing here is fairly radical, in that it represents a very different method of building in Second Life. But, like everything I propose, it is not only possible, but feasible; I could devise the algorithm for it myself, with a bit of research as needed. This feature would require a more significant change to the data structure for prims than before, but the possibilities are astounding.

Throw away the Taper attribute for objects. It was great, but it will be made entirely obsolete by the feature I am proposing: section radii. Instead of describing the relative size of the beginning and end of the prim, as Taper does, Section Radius would describe the size of the prim at every point along its path.

NB: Every prim, with the exception of Sphere, can be represented as a two-dimensional shape such as a square or circle, which is extruded along a path to create a three-dimensional surface. For Box, Cylinder, and Prism, that path is a straight line into the third dimension; for Tube, Torus, and Ring, that path is a circle.

Take a look at my fancy diagram (to the right, click for a larger version). In (1), we are describing 5 different sections (solid lines), with another 4 values being interpolated between them (dotted lines). The gray line at the bottom represents the full span of the path from beginning to end.

In (2), we see a top-view of a cylinder with the sections that were defined in (1). Note that by smoothly interpolating between the defined sections, we can achieve a very smooth result without defining a large number of sections. In (3), we see a top-view of a torus with the same sections (or, at least, a passable representation of one; it's hand-drawn, not mathematically computed, so it may not be very accurate).

In the example, all the sections were equally spaced, but that need not be the case. Nor need there be a set number of sections. An arbitrary number of sections could be defined, with data storage increasing linearly with the number of sections defined (i.e. if we define twice as many sections, it takes twice as much space to store the data).

The advantage taper has is that it can be represented as two numbers between -1.0 and +1.0, one number for each axis X and Y. So, it doesn't take much bandwidth to transmit the Taper attribute of a prim. The disadvantage to taper is that its possibilities are decidedly limited: the shape's size can only be changed by a constant value as it is extruded along its path. It cannot, for example, start out small, become large in the middle, then small again at the end (making a surface resembling a lemon or American football).

With section radius, on the other hand, it would be possible to make such a shape, and a great many other shapes, with a single prim: vases, bullets, wavy french fries, bushy tails, barbells, and a great many non-PG items (which I will refrain from linking to). I haven't even started to mention all the possibilities with torus and kin!

There is, of course, a trade-off: section radius takes more information to store and transmit than taper. How much more?

One axis of taper requires, at most, a single floating point number (i.e. not an integer). If Linden Lab is clever, they don't even need that, because the granularity of each attribute is in the hundredths (I may be wrong, it may be thousandths), meaning there are only 200 (or 2000) possible values for one taper axis. That would take only 8 (or 11) bits to represent, versus a 32 bit float value.

Section radius, on the other hand, would require at least twice that, for every section defined. The more sections you define (i.e. the greater the detail in the section radius), the more data you have to store. I say "at least twice", because additional storage would be needed for storing the interpolation type (linear, smooth, step, and perhaps others). That might be stored once for the entire curve, or stored for each section. The latter would require more storage, but would be more flexible.

Section radius can, of course, be used to emulate the current Taper attribute (as well as the poorly-named Hole Size attributes for torus and kin, at no extra cost): one section each defined at the beginning and end, with linear interpolation between them. That's between four and six times as much data, for the same result.

When it's phrased like that, it seems like a bad idea. The same result, but a higher cost? No thanks!

But consider this: section radius would enable shapes which were impossible before. And if you were to try to approximate such a shape using existing building methods, it would require (n-1) separate prims, where n is the number of sections. Each prim, of course, has to store a great many redundant attributes (position, rotation, size, texture data, etc.) which would not be necessary for a single complex prim. And besides taking more storage space (not to mention parcel prim limit space), a many-prim solution would require a great deal of time to construct, and the results would be blocky and undesirable.

To put this in another light: section radius would enable complex and beautiful shapes to be made from a single prim, but would make creating a large number of simple shapes slightly less efficient.

It represents a shift from low-level, difficult-to-use tools to higher-level, easy-to-use tools. This is a shift that Second Life needs to make, in many areas, if it hopes to attract and retain the Doers and Makers that create the content of Second Life.