Talk:Programmatic Textures

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

RenderHTML and StringAsset

What problem does renderHTML solve?

It provides dynamic textures where the updates are measured in seconds rather than minutes. When I wrote "non-refreshable" I meant "it could only be refreshed by LSL, not by (for example) javascript embedded in te texture" -- Argent Stonecutter 06:29, 14 February 2007 (PST)

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.

This isn't just a "different way to get stuff on a prim". It's a system where textures can be dynamic in response to LSL running in the prim. It sidesteps the whole issue of user-interaction with HTML by leaving the user interaction in LSL, with updates handled by sending a small HTML string rather than a large bitmap. -- Argent Stonecutter 06:29, 14 February 2007 (PST)

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)

BTW if I have misunderstood the intent of these proposals, let me know. Gigs Taggart 06:03, 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.

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.