The sexiest SL feature of 2007 award goes to… sculpted prims. The lion’s share of the glory for this one apparently goes to Qarl Linden. Will Torus have to give up its tiara and “Most Versatile Prim Type” sash? Only time will tell.
-
27Apr
-
29Oct
Attention: Maths ahead! Non-geeks may prefer to avoid the equations, and just look at the pretty colors instead.
Previously, on Jacek Writes: our hero introduced the topic of smoothly blending between two colors algorithmically.
Last time, I defined an equation for blending linearly between two color vectors
aandbas time,t, increases from 0 to 1:line(t, a, b) = a + t * (b - a)
After a little algebra, we can rewrite that function as:
line(t, a, b) = (1-t)(a) + bt
Linear blending looks just fine for blending between two colors, as demonstrated above. Starting from the left, we progress from red to blue, passing through magenta and purples. Looks pretty good, right?
-
22Oct
I wrote a post about “section radius” recently, which involved drawing curves with a discreet number of anchor points. The application there was a more robust replacement for the Taper attribute of prims. Of course, the usefulness of using a curve instead of one or two numbers is not limited to Taper alone—there are innumerable other uses for them, completely aside from the Object attributes.
One of my backburner obsessions for the past few months has been color. (No surprise there, given that I’m currently enrolled in a color theory class, I suppose.) In particular and with regard to SL, two aspects have been on my mind. The first is using a base color as input to an algorithm to generate related colors (lighter tint, darker shade, blue-shifted, red-shifted, visual complement…). The second is blending between two colors in a smooth and visual appealing fashion.
This is where curves come in.
-
22Sep
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; 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).
-
10Sep
The Build window should have a tab for controlling a prim’s particle system.
That’s simple enough, yeah? But I like to hear myself type, so I’ll go into more detail.
-
03Sep
Textures take a long time to download, even on the asset servers’ good days. The fact is, they use a lot more storage space and bandwidth than the actual prims they cover. While moderately-sized textures will weight in at several kilobytes, a prim takes perhaps a hundred bytes (the exact figure does not matter at this point, only its relative magnitude). How can a three-dimensional object take less space to store than a two-dimensional image?
The trick is in how prims are created. Every single prim is parametric‘ or procedurally generated. Second Life has functions (i.e., procedures) which take certain parameters (e.g., size, twist, taper) and generate the three-dimensional mesh of, say, a torus based on those parameters. So you don’t have to transfer the 3D mesh, just the parameters; the mesh can be constructed by any client locally.
Textures, on the other hand, store pixel data for the image. Of course, image compression is used, and varying levels of detail are generated (so you only have to transfer the lowest level of detail needed), but it still requires much more data than a prim.
But, just like it is possible to procedurally generate 3D primitives, it is possible to generate 2D images, i.e. procedural textures. Procedural textures are common in 3D computer animation as an easy and storage-inexpensive way of creating high-detail textures. Most animation packages come with a number of texture procedures, and although the complexity of the procedures varies, they all have something in common: one procedure can generate a (seemingly) unlimited number of similar (but not identical) textures, based on the procedure’s parameters. In addition to the “standard” texture procedures which come with the program, many packages allow knowledgeable users to create their own procedures.
-
18Aug
Suppose for a moment that you are a builder of detailed houses within Second Life. In a typical house, you might have ten window fixtures, eight decorative columns, four doors, and two statues in the garden. Each of these items is identical to the others of its type, and is constructed of, perhaps, ten prims each, with the exception of the statues which are 100 prims each.
You’ve just spent 420 prims of your parcel budget to make twenty-four objects, and we haven’t even added furniture! That’s 420 prims which must be saved to the sim, and 420 prims which must be sent to every Second Life client which wants to view your magnificent houses.
What a waste, when each item is exactly the same as the others of its type, with only a different position, rotation, and possibly scale!
With object clones, which I am herein proposing, you could build the exact same house, but the above-mentioned 420-prim figure would be reduced to a mere 130 prims.
-
17Aug
When it comes to flexible prims, size does matter. A small prim just won’t bend as much as a larger prim with the same flex settings. So if you want your lop-eared pet rabbit’s ears to lop just the right way, you may have to scale him up to 5 meters on a side!
If I ruled the Grid, flex would be independent of size. Depending on how Linden Lab has implemented flexible paths, this would likely involve subdividing the path into the same number of parts when it is big as when it is small—that is, a number of subdivisions per path, not per meter of the path’s length.
Since flexible prims have already been implemented, and that change would “break” a huge number of existing objects (not to mention cause plenty of embarrassment for flexi-skirt users who go without the luxury of “glitch pants”), Linden Lab could instead add a new attribute to control the scale used for subdividing the path. The default setting would be equivalent to the current scale, so that existing flexible prims would not behave differently.
Recent Comments