Talk:Programmatic Textures - Revision history

Argent Stonecutter: /* RenderHTML and StringAsset */

2007-04-25T15:41:42Z

RenderHTML and StringAsset

← Older revision		Revision as of 08:41, 25 April 2007
Line 12:		Line 12:

	::Thanks for the clarification. What makes it lower overhead than general HTML on a prim?		::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		::* Fetch HTML from LL server -> render client side in mozilla to a raster texture -> apply to face
	seems about the same to me as:		::seems about the same to me as:
	* Fetch HTML from arbitrary server -> render client side in mozilla to a raster texture -> apply to face		::* 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. [[User:Gigs Taggart\|Gigs Taggart]] 07:58, 14 February 2007 (PST)		::I'm not sure where the win is there. [[User:Gigs Taggart\|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).		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).
Line 25:		Line 28:

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



	==String To Asset==		==String To Asset==

Gigs Taggart: html textures

2007-02-14T15:58:02Z

html textures

← Older revision		Revision as of 08:58, 14 February 2007
Line 10:		Line 10:

	''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.'' -- [[User:Argent Stonecutter\|Argent Stonecutter]] 06:29, 14 February 2007 (PST)		''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.'' -- [[User:Argent Stonecutter\|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. [[User:Gigs Taggart\|Gigs Taggart]] 07:58, 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).		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).

Argent Stonecutter: /* RenderHTML */

2007-02-14T14:36:25Z

RenderHTML

← Older revision		Revision as of 07:36, 14 February 2007
Line 19:		Line 19:
	I have attempted to clarify the point you misunderstood in the restored version of the section. -- [[User:Argent Stonecutter\|Argent Stonecutter]] 06:36, 14 February 2007 (PST)		I have attempted to clarify the point you misunderstood in the restored version of the section. -- [[User:Argent Stonecutter\|Argent Stonecutter]] 06:36, 14 February 2007 (PST)

	~~==RenderHTML==~~
	~~<pre>~~
	~~llRenderHTML(integer face, string content);~~
	~~</pre>~~

	~~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==		==String To Asset==

Argent Stonecutter: /* RenderHTML and StringAsset */

2007-02-14T14:36:12Z

RenderHTML and StringAsset

← Older revision		Revision as of 07:36, 14 February 2007
Line 16:		Line 16:

	BTW if I have misunderstood the intent of these proposals, let me know. [[User:Gigs Taggart\|Gigs Taggart]] 06:03, 13 February 2007 (PST)		BTW if I have misunderstood the intent of these proposals, let me know. [[User:Gigs Taggart\|Gigs Taggart]] 06:03, 13 February 2007 (PST)

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

	==RenderHTML==		==RenderHTML==

Argent Stonecutter: /* RenderHTML and StringAsset */

2007-02-14T14:32:41Z

RenderHTML and StringAsset

← Older revision		Revision as of 07:32, 14 February 2007
Line 3:		Line 3:
	==RenderHTML and StringAsset==		==RenderHTML and StringAsset==

	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.		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"'' -- [[User:Argent Stonecutter\|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.'' -- [[User:Argent Stonecutter\|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).		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).

Argent Stonecutter: /* RenderHTML and StringAsset */

2007-02-14T14:30:33Z

RenderHTML and StringAsset

← Older revision		Revision as of 07:30, 14 February 2007
Line 3:		Line 3:
	==RenderHTML and StringAsset==		==RenderHTML and StringAsset==

	What problem does renderHTML solve?		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.

	''It provides dynamic textures where the updates are measured in seconds rather than minutes. You have madly misunderstood the intent of RenderHTML.'' -- [[User:Argent Stonecutter\|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.'' -- [[User:Argent Stonecutter\|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).		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).

Argent Stonecutter: /* RenderHTML and StringAsset */

2007-02-14T14:29:50Z

RenderHTML and StringAsset

← Older revision		Revision as of 07:29, 14 February 2007
Line 3:		Line 3:
	==RenderHTML and StringAsset==		==RenderHTML and StringAsset==

	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.		What problem does renderHTML solve?

			''It provides dynamic textures where the updates are measured in seconds rather than minutes. You have madly misunderstood the intent of RenderHTML.'' -- [[User:Argent Stonecutter\|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.'' -- [[User:Argent Stonecutter\|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).		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).

Gigs Taggart at 14:03, 13 February 2007

2007-02-13T14:03:15Z

← Older revision		Revision as of 07:03, 13 February 2007
Line 9:		Line 9:
	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. [[User:Gigs Taggart\|Gigs Taggart]] 05:59, 13 February 2007 (PST)		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. [[User:Gigs Taggart\|Gigs Taggart]] 05:59, 13 February 2007 (PST)

			BTW if I have misunderstood the intent of these proposals, let me know. [[User:Gigs Taggart\|Gigs Taggart]] 06:03, 13 February 2007 (PST)

	==RenderHTML==		==RenderHTML==

Gigs Taggart: done deleting parts in question and moving them to discussion

2007-02-13T14:01:40Z

done deleting parts in question and moving them to discussion

← Older revision		Revision as of 07:01, 13 February 2007
Line 1:		Line 1:
	Changed the parameters to llRenderText to match the other call. -- [[User:Argent Stonecutter\|Argent Stonecutter]] 12:05, 26 January 2007 (PST)		Changed the parameters to llRenderText to match the other call. -- [[User:Argent Stonecutter\|Argent Stonecutter]] 12:05, 26 January 2007 (PST)

	==RenderHTML==		==RenderHTML and StringAsset==

	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.		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.
Line 9:		Line 9:
	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. [[User:Gigs Taggart\|Gigs Taggart]] 05:59, 13 February 2007 (PST)		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. [[User:Gigs Taggart\|Gigs Taggart]] 05:59, 13 February 2007 (PST)

	~~== RenderHTML ==~~

	==RenderHTML==		==RenderHTML==

Gigs Taggart at 14:01, 13 February 2007

2007-02-13T14:01:01Z

← Older revision		Revision as of 07:01, 13 February 2007
Line 27:		Line 27:
	*Con: Less capable than HTML on a prim.		*Con: Less capable than HTML on a prim.
	*Pro: Does not expose the viewer's address.		*Pro: Does not expose the viewer's address.

			==String To Asset==
			<pre>
			key llStringToAsset(string data, int height, int width, int format);
			</pre>

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