Difference between revisions of "Programmatic Textures"
Gigs Taggart (talk | contribs) |
|||
Line 10: | Line 10: | ||
This would render text on a face, similar to llSetText, except on a face. | This would render text on a face, similar to llSetText, except on a face. | ||
The client would | |||
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. | *Pro: Solves a very common problem. | ||
*Con: Limited in scope, only useful for text. | *Con: Limited in scope, only useful for text. | ||
*Con: Font selection may be limited. | **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. | *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== | ==Rendered Vector 2D Lines== |
Revision as of 12:04, 26 January 2007
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 font, integer color);
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.