Tofu loves us, too!

Linux Users Love Tofu Linden!

Yes, every Linux-using Resident of Second Life is now brimming over with love and affection for Tofu Linden, the Linux client developer for Linden Lab!

Today marks the first time the Linux client has had any sort of file upload/download capacity! Right now it's pretty rough around the edges, as there is still no file browser/picker, but it works! (Just rename the image to upload.tga and place it in your SecondLife/your_name/ folder, then use the upload menu item.) Tofu tells us that the file picker is in the works, which is also very nifty!

Since the last I posted about the Linux client, much progress has taken place, apparently due to the efforts of our hero, Tofu Linden! Audio playback was added August 29, including support for parcel audio streams, and Copy & Paste was added September 13—the Linux client is fast approaching the full feature set that the Windows and Mac users currently enjoy (plus, of course, the added "feature" of being able to log in to SL in Linux!).

I have found my own way to express my appreciation to Tofu: I created the adorable image above, featuring a penguin lovingly embracing a brick of tofu! (The image was created in Inkscape, by the way—a great piece of software if ever there was one!)

I then successfully uploaded the image, and a T-shirt featuring the image, to Second Life! Then I took a snapshot of me wearing the shirt (and standing in front of a waving flexi flag with the texture on it) and saved the snapshot to disk—you can see the proof here!

Since everybody should be able to show their love for Tofu Linden, I am giving out the shirt and textures* at my home/studio/gallery in Hallasan! (While you are there, say hi to Primmy!)

* A small word of caution, though: my gallery is in a Mature sim, and includes a few artistic nudes. You probably won't even see them if you go straight to those coordinates and don't poke around, but I thought I'd give you fair warning, in case you are logging in to SL while at work. In the Vatican. Where you share an office with his Holiness the Pope.

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.

Prim's Amazing Journey

Today, a joyful reunion marks the end of an amazing true story of struggle, perseverance, and hope.

Prim, a purebreed plywood cube and the adored pet of Jacek Antonelli, was returned to his owner today after being missing for nearly two weeks. "I had almost given up hope of ever seeing my dear Primmy again," says Antonelli. "I'm so glad he's back. My life just wasn't the same without him."

Jacek Antonelli looks on as Prim stretches out for a much-needed nap outside their home in Hallasan.

Prim went missing on September 4 after he bounced away from the cottage where he resided in Hallasan (located along the south-east coast of the Most-Southern Continent). "Prim needed some excercise, so I set him on physical and gave him a script to set his llTargetOmega," tells Antonelli. "But I forgot to put on his leash before I closed the edit window, and he bounced up into the air, right over the house! I was so surprised."

Jacek Antonelli searched for hours to find Prim, but he was nowhere to be found. When Prim hadn't been returned after several days, Antonelli feared the worst: "I thought he must have bounced into the ocean and drowned, or gotten trapped in a sex club and asphyxiated."

The route Prim may have taken from Hallasan (south) to Chamisak (north).

(Artist's recreation)

But today, Antonelli logged on to find some good news: Resident Artlan Doctorow found Prim on his parcel in the Chamisak region, over 5.5 kilometers from Antonelli's cottage. Said Antonelli, "I was so surprised! I have no idea how he got all the way to Chamisak by himself."

Asked for comment, Doctorow beamed, "I'm just glad to have helped reunite the two. No one shoud have to go through the fear of losing a pet, especially one that cute."

Now Prim, exhausted but seemingly no worse for wear, purrs contentedly as Antonelli strokes him. "I'm absolutely amazed at how he managed to keep going so long, especially with the grid restarting to frequently. I never imagined he would make it, but I'm so happy that he's back."

Antonelli has a plan to keep Prim safe and sound from now on: "I'm going to be extra-careful when dealing with physical objects. I'm giving Prim a script so I can track him wherever he goes, too. You know, just in case he gets loose again."

When asked to comment on his journey, Prim replied: "Hello, Avatar!"

Defining ourselves

Mera offered a thought stream which got me thinking about deriving identity in activity—the idea that you are what you do. If you center yourself around doing N, who would you be if you stopped doing N?

(I am reminded here of the crises of people who, after working their entire lives at the same job, reach retirement and are at a loss as to how they should spend their time. The job had become their identity.)

This struck a chord with me because I do tend to derive a lot of my identity from what I do. In both Lives, I keep myself perpetually buried in projects, so that I will always have some activity to define myself in relation to.

I create, so I am a creator.
I teach, so I am a teacher.
I do, so I am.

Assuming, of course, that it is undesirable to be left in a state of doubt about one's identity, one should endeavor to prevent and cure such a state. Defining oneself in relation to only one or two things is risky; interests come and go, and the anchor that holds today may not tomorrow. A less risky option (and the one I am prone to do) is to grab hold of as many activities as possible, so that each matters less. If one fails, the others are there as backup. But there is a danger to this too, that of spreading oneself too thin, so that there is no meaningful benefit in anything.

No matter how we define ourselves in relation to other things and activities, there is always the very real possibility that we will lose or shift away from them.

But what if we define ourselves not in relation to something else, but as being ourselves, no matter how we change?

I am myself.
I look a certain way, act a certain way, and enjoy certain things.
In the future, I will look another way, act another way, and enjoy other things.
I will be myself then, too.

(We'll see.)

Build Window: Particles

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.

Right now, the only way to activate on deactivate particle systems on a prim is through the use of a script which calls the llParticleSystem() function. That function takes a list of many pairs of parameters, each pair describing what is being defined (e.g. PSYS_PART_START_COLOR, i.e. particle starting color) and what that thing is being defined as (e.g. <1,0,0>, i.e. pure red). Constructing such a list is a tedious and frustrating task, but fortunately there are plenty of helpful scripts which can make it a bit more convenient. But even these helper scripts must call llParticleSystem() eventually, or there will be no particles.

You might think, based on the fact that a script is the only way to activate particles, that a prim must necessarily be scripted to have particles. This is not the case: the particle system is stored with the prim itself, not the script. Consider the fact that you can stop or even delete the script which activated the particles, and the particles will continue unabated.

To summarize, particle systems can exist without scripts, but there is currently no method aside from scripts to turn them on or off. As scripts are a tedious and ultimately unnecessary way of creating, changing, and deleting a particle system, it thus stands to reason that a more convenient method should be provided as a supplement to the scripted method. The Build window's Features tab (which currently houses the settings for flexible paths and light-emission) seems to be the natural place for this. But particles have a lot of settings, and the Features tab is already a bit crowded, so, at risk of over-complicating the user interface, I recommend branching the Features tab into sub-tabs, one of which would be dedicated to particle systems.

(In fact, particle systems have such a large number of settings that two or more tabs may have to be dedicated to particle systems. An obvious but imperfect division is between PSYS_PART_* and PSYS_SRC_* flags. A more natural but less clear-cut division is between settings which define the appearance of each particle, and those which define how they are emitted and behave as a system.)

So what would we see when we look at the Particle tab(s) of the Build window? It turns out that particle system settings are represented by a handful of distinct types of data, and the proper UI widgets to control each type are already used in other places in Second Life's interface, especially in the Build window itself:

type	widget	example
bitfield	checkboxes	General tab: permissions
option	radio buttons / drop-down menu	General tab: for sale options / General tab: When Left Clicked
float	numeric control	Object tab: Revolutions
integer	numeric control	Object tab: Hollow
vector	multiple numeric controls	Object tab: Position
color	color picker	Texture tab: Color
texture	texture picker	Texture tab: Texture
object/avatar	object picker	Report Abuse window

Some notes: in the script, colors are actually the vector data type, but it is non-intuitive to select a color the same way you set e.g. size in a graphical widget. Also, a script has the advantage in selecting a client asset texture by key, whereas the graphical widget can only select from inventory. And, the object picker in the Report Abuse window can only select the root prim of an object, which would be insufficient when targetting a child prim of an object.

In addition to all the particle system attributes, one more UI element would be needed: a checkbox for whether the particle system is currently active or not. But unchecking that box should not make in impossible to change the other settings, as happens with the flexi and light features (in fact, it should not do so in those cases either!). This might require a small change to the way particle systems work, as I am not certain if non-active particle systems are saved with prims. But even if the values for the attributes of a non-active particle system were stored only client side (so that if the client crashed, they would be lost), it would still be a useful feature.

I feel compelled here to anticipate several possible arguments against this feature:

1. "Newbies and griefers will be making ugly and annoying particle systems left and right! At least now, you have to be able to script to abuse particle systems!"

   To this I have two responses. Firstly, newbies and griefers already make ugly and annoying particle systems left and right, because scripted smoke bombs etc. are already easily available. Secondly, I don't think that imagined fear of abuse is a legitimate reason to prevent progress in ease of legitimate use.

2. "This change would put the makers of particle helper scripts out of business!"

   Adapt or perish. Should we have stuck with the telehub system, because point-to-point teleporting forced vehicle makers to change their business models? Perhaps we should get rid of the Object tab, and force all changes to a prim's shape be made through scripts, to increase demand in the prim-twisting script market?

   The fact is, scripts which control particle systems will still be useful; but they will have to go beyond the basics and have more complex behavior. Some examples include particle systems which gradually rotate through all the colors with time, or particle systems which detect nearby avatars, look up their favorite color in a database, and shoot particles of that color at them.

As I see it, there are plenty of reasons to add this feature and few reasons to reject this feature, little effort required to add it and much benefit from its addition. So get it done.

Procedural Textures

This post appeared originally on the old blog. The original comments attached to the post are listed at the bottom. -J 09/03/06

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.

(To avoid confusion, I will use the terms "texture procedures" or "procedures" to indicate blocks of code which are executed to generate a texture, and "textures" to indicate collection of image data, either from an uploaded image or the saved result of a texture procedure.)

Consider a "wood-grain" texture procedure . Some of the parameters it might have are: wood color, grain color, ring density, ring uniformity (how similar in thickness each ring is), ring noise (how distorted the ring shape is), and so on. Based on these parameters, the procedure would generate a texture. If you used slightly different parameter settings, the procedure would generate a slightly different texture.

If I Ruled the Grid, there would be several standard texture procedures written in a simple 'shading' language (affecting surface color only; control over how light affects the surface would be excessive for Second Life). Eventually, custom procedures could be written by users and distributed through Second Life as objects.

Some examples of standard texture procedures would be:

• multiple-octave Perlin noise (or similar)
• wood grain
• stone/marble
• text
  

Standard texture procedures, which would be distributed with the client software, present a much simpler problem because everyone will already have the procedures on their computer. Custom procedures complicate the system, because they must be distributed across the net to other clients, but the IP rights of the creator must be respected. (Distributing the procedure code, even in compiled form, increases the risk of it being decompiled or reverse engineered.)

To allow the creators of texture procedures control over the use of their creations (making possible a market for procedures), special permission settings would be required, as detailed below. Unless otherwise noted, each setting can be enabled or disabled separately for creator, owner, group, everyone, etc.:

• Modify: user can access and modify the procedure's source code.
• Run: user can set parameters and execute the procedure.
  
• Save: user can save the results of the procedure as a texture in his/her inventory.
  
• Save Permissions: saved results will be created with these mod/copy/transfer permissions.
  
• Download: user can download the compiled procedure to the client. If this is disabled, only cached server results can be seen.
  
• Copy, Transfer: as with other types of object.
  

Obviously, some uses of custom texture procedures do not take advantage of the reduced bandwidth use of procedural textures; instead, they are used as a convenient way for the creator to generate many customized textures, which can then be used separately. The ability of texture procedures to create many textures with minimal human effort is no less useful than its bandwidth conservation.

---

Comments from the original post:

Akela Talamasca said...

Thank you for explaining the whole 'pocedural' thing... since the advent of Spore, there's been a lot of talk about 'procedurally generated animation' and the like, and I've never understood what it meant, and why it was able to provide suce small file sizes. Now I know. And knowing's half the battle. *GI Joooooeeeeeeee!*

8/31/2006 9:47 AM

---