Talk:Programmatic Textures

Changed the parameters to llRenderText to match the other call. -- Argent Stonecutter 12:05, 26 January 2007 (PST)

RenderHTML

What problem does renderHTML solve? I don't see much use in a static, nonrefreshable texture that just happens to be defined in HTML. Remember we are going after a different problem domain than what can be accomplished with static texture uploads that we have now. This isn't merely a "different way to get stuff on a prim", we want a system where textures can be dynamic in response to the LSL running in the object.

The string2asset proposal has the same problem. The point of this isn't to make static images that will be used over and over, it's to generate things on the fly that are temporary in nature (such as a textual output or a status display).

I'm going to remove these two proposals, as they are orthogonal to what this proposal is trying to accomplish. If you want to make them into their own feature requests, feel free. I'm going to move their text here for easy access. Gigs Taggart 05:59, 13 February 2007 (PST)

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.