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.

Procedural Texture Generation Libraries

Texture and Text Example

Similar in kind to programmatic texturing, these libraries handle the generation and storage of complex textures.

• http://www.fxgen.org (Open Source Libraries)
• http://www.werkkzeug.com (Commercial)
• http://www.profxengine.com (Commercial)

A summary of the included pros and cons of these procedural libraries:

• Pro: Intuitive interface and application make them useable by artists without the need for scripting knowledge
• Pro: No image quality loss; The client can render images at any chosen resolution without impact on the file size
• Pro: For a texture process file (which includes its maps and masks), the file size generally ranges from 1 kb or less to 2 kb
• Pro: Imputs come in the form of text, basic shapes and randomized patterns
• Pro: Can use uploaded images as part of the processing
• Pro: Can create everything from seamless tiling textures to UV maps, and all their needed maps and masks without the need to upload a single file if so desired
• Pro: Comes with advanced texture and model functions which would benefit SL as a whole both in functionality and in enhanced visual experience (ex: normal mapping)
• Pro: Just like scripting, linking smaller processes efficiently can create beautiful and complex images with fewer imputs and short processing times
• Con: Also just like scripting, using redundant and badly-made processes can create ugly images with long processing times, which could potentially crash a client
• Con: Render time is dependant on the client's CPU and its ability to process the files; This becomes the new 'bandwidth' instead of the connection speed

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.

Render 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.