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)

Thanks for the clarification. What makes it lower overhead than general HTML on a prim?

• Fetch HTML from LL server -> render client side in mozilla to a raster texture -> apply to face

seems about the same to me as:

• Fetch HTML from arbitrary server -> render client side in mozilla to a raster texture -> apply to face

I'm not sure where the win is there. Gigs Taggart 07:58, 14 February 2007 (PST)

Those aren't parallel. This is for the case where the content is generated by LSL, not an external server.

• Generate URI containing string -> send to client -> client sends string to server -> render client side...

This will reduce the latency of the update significantly, and also sidestep the privacy issues. It's still more overhead than RenderSVG or RenderText, but with appropriate limits (say, only display the nearest N HTML textures) it shouldn't be too bad. Avoiding the need for those limits would still be better.

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)

I have attempted to clarify the point you misunderstood in the restored version of the section. -- Argent Stonecutter 06:36, 14 February 2007 (PST)

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.