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.

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.
- SVG supports a full XML DOM!
- SVG can support animation using ECMAScript (Javascript)
- SVG can do just about everything HTML can do, without the 15 years of legacy tag soup bloat.

Con: No current direct SVG support in SL.
- However, SL Viewer already links Cairo, which is the main requirement for librsvg. Librsvg is only 300kb, and is LGPL.

- THere are at least three other open source codebases that could be tapped
  - Inkscape http://www.inkscape.org/
  - Qt
  - Gnome's librsvg.
  - GPAC http://gpac.sourceforge.net/
  - Mozilla Firefox http://www.mozilla.org/projects/firefox/

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. Since it would not implement any local scripting it could not be refreshed by javascript or metadata in the HTML... ir would be refreshed by a new call to llRenderHTML.

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.

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.

Vector 2D Point

Feynt Mistral suggests by corollary:

llPlotPoint(integer face, float width, vector colour, vector point)

or, optionally

llPlotPoint(integer face, float width, vector colour, list points)

Where points is a list of vectors. As in previous suggestions by Argent Stonecutter, the Z dimension is disregarded for drawing on the prim.

Pro: Basically, it's written as a sub function for drawing lines, so it would already be there
Pro: As with llPlotLine, can draw anything
Pro: No need to draw very small lines as with llPlotLine to create dynamic raster images, so less memory is spent on points while drawing
Pro: With sufficient deciphering by the programmer, fonts could be drawn with this (albeit slowly).
Con: As with llPlotLine, it would take a lot of bandwidth (a lot MORE in this case, because there's no interpolation between any two points to fill in the pixels to form a line as with llPlotLine). Suggested counter to this would be to have a means of identifying draw functions as a "send to client" code chunk so it's rendered locally.
Con: Very complicated textures could take a long time to form, especially at large resolutions.

Programmatic Textures

Contents