Programmatic Textures

Summary

Programmatic Texture generation is a similar technology to Dynamic Web Textures, except the client generates the texture from programmatic instructions rather than downloading it from a script on a web server.

RenderText

Argent Stonecutter has suggested:

llRenderText(integer face, string text, integer color, integer font);

This would render text on a face, similar to llSetText, except on a face.

The actual implementation would simply passthe parameters to the client, similar to the way calls like llParticleSystem() operate. The client would create an overlay for the texture on that face (for example, by baking a new local texture containing the text and applying that instead). Normal texture calls would translate the text along with the texture for things like marquee effects.

The available fonts could be generic: FONT_SAN_SERIF, FONT_SERIF, FONT_TYPEWRITER, FONT_SCRIPT, FONT_CASUAL, FONT_SYMBOL, FONT_GRAPHIC. Named fonts that defaulted to the generic fonts when not available might be an option.

• Pro: Solves a very common problem.
• Con: Limited in scope, only useful for text.
  • FONT_SYMBOL and FONT_GRAPHIC (a 4x2 bitmap) would contain a variety of special characters.
• Con: Font selection may be limited.
• Con: Windows platforms, Mac platforms, and Linux Platforms all have different default fonts.
  • Mapping to generic fonts would prevent lost data. FONT_ARIAL and FONT_HELVETICA could map to FONT_SAN_SERIF when not available, and there are readily obtainable versions of most of teh common web and printer fonts.

Rendered Vector 2D Lines

llPlotLine(integer face, float width, integer color, list coords);

Coords to draw a square:
[ <0,   0,    0>, 
  <0,   0.1,  0>,
  <0.1, 0.1,  0>,
  <0.1, 0,    0>,
  <0,   0,    0>
]

The vectors here are really only used cartesian X/Y values.

• Pro: Can be used to draw text, simple fonts can be created.
• Pro: Can draw anything.
• Pro: Can be used to create dynamic raster images by using very small lines that form "pixels".
• Con: Could require a lot of bandwidth to send the client a complex image.
• Con: Fonts created this way would look ugly.

String To Asset

key llStringToAsset(string data, int height, int width, int format);

Convert a string of data directly into an asset avaiable on the asset server. Once it's created, it would be treated like any other asset. The assets could be used to do something like piece together clothing dynamically. The user would probably have to be charged L$10 to keep it fair.

• Pro: Allows some types of images to be created easily, if you can write a function that will generate it.
• Pro: The data could be fetched via llHttpRequest... but right now SL doesn't allow long enough responses for an image.
• Pro: Users could go to a script, type in a url, and that would get converted directly to a texture.
• Con: Unsure if the string type can properly hold binary data, we might need a byte type for this, perhaps an int array would work.
• Con: Uses are limited, and it would only be at it's most powerful when there is some kind of dynamic image service that a script could connect to.