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.

RenderHTML

llRenderHTML(integer face, string content);

This would render HTML on a face. The HTML could not contain any links or active content, but would be treated as a static overlay. It would not be refreshed.

If the string begins with an angle bracket, it is treated as the literal content, otherwise it is assumed to be the UUID of a notecard or the name of a notecard in the prim.

The actual implementation would simply pass the content or the UUID of the notecard 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 rendered page and applying that instead). Normal texture calls would translate the content along with the texture.

Pro: Solves a very common problem.
Pro: Significantly lower overhead than full HTML on a prim.
Con: Higher overhead than llRenderText.
Con: Less capable than HTML on a prim.
Pro: Does not expose the viewer's address.

RenderSVG

llRenderSVG(integer face, string content);

This would render Scalable Vector Graphics on a face.

If the string begins with an angle bracket, it is treated as the literal content, otherwise it is assumed to be the UUID of a notecard or the name of a notecard in the prim.

The actual implementation would simply pass the content or the UUID of the notecard 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 graphics and applying that instead). Normal texture calls would translate the content along with the texture.

Con: May be bulkier than llPlotLine (below) for simple patterns.
Con: Will be more complex to implement that llPlotLine or llRenderText.
Pro: Should be significantly more compact than llPlotLine for complex patterns.
- For example, SVG has more predefined shapes: 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon', llPlotLine only supports polylines.
- SVG supports rendering text.
Con: No current SVG support in SL.
- THere are at least three open source codebases that could be tapped
  - Inkscape http://www.inkscape.org/
  - GPAC http://gpac.sourceforge.net/
  - Mozilla Firefox http://www.mozilla.org/projects/firefox/

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.
Con: Linden Labs have stated that they will not implement any function that programatically creates new assets.

Programmatic Textures

Contents