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

---