Talk:Web Textures

Argent, Lets try to keep these article-like, rather than discussion-like. I integrated your comments.

On the white/black list pros and cons, instead of commenting on them, put a subpoint under them to say what would mitigate that con, or just take the con out if you think it's completely bogus. Gigs Taggart 09:54, 26 January 2007 (PST)

Done -- Argent Stonecutter 12:18, 26 January 2007 (PST)

Making page moves

Please make a request to make a page move rather than making moves by cutting/pasting (just request on User talk:Rob Linden for now...we'll come up with a more streamlined process later). It's really a pain to merge histories after a cut/paste/redirect move, and much simpler to move the history/discussion and everything in one move. Thanks -- Rob Linden 10:40, 26 January 2007 (PST)

Turns out there is a move tab I overlooked. I'll use that from now on. Gigs Taggart 11:37, 26 January 2007 (PST)

Proxy

If a professional can't type in an IP address and port number, they aren't very much of a professional. Gigs Taggart 16:51, 26 January 2007 (PST)

have you ever used an anonymizing proxy chain? -- Argent Stonecutter 13:38, 28 January 2007 (PST)

Streaming Media

Streaming music is not specific to the "Do Nothing - Just Implement It" section. I've restored that section. Comments about the relationship between streaming media and texture bugs need to be outside any specific section. Here's my thoughts on it:

Yes, streaming media is an issue. There have been scares in the past over streaming media, and for that I've been on the side of "don't worry about it". Why?

Streaming media differs from texture bugs:

• A significant number of people do not use streaming media in SL because:
  • The overhead of streaming media has an impact on performance.
  • A lot of people have really bad music on their land.
• Streaming music is limited to one parcel. Texture bugs can be anywhere.
• The bandwidth costs of any large streaming-media-based collection scheme are significant.

The result is that it's a far less significant exposure: fewer people are impacted, and even for those people you can only collect data in a small number of places. -- Argent Stonecutter 13:49, 28 January 2007 (PST)

Sorry, I undid some of your changes before I saw this. I reorganized the article some to reflect this suggestion. Gigs Taggart 12:00, 29 January 2007 (PST)

With regards to LSL Implementation

Implementation could be simplified thusly: Instead of the original code:

llSetTextureURL(integer face, string url);
llRefreshTextureURL(integer face);

llSetTextureURL(1, llUrlEncode("http://example.com/getpng.php?text= " + text + "&font=futura&rez=512x512");
llRefreshTextureURL(integer face);

We can make use of llSetTexture()'s ability to be supplied with either a string OR a key.

llSetTexture("http://example.com/example.png",ALL_SIDES);

Since the LSL/Mono VM first checks if the variable supplied for the texture name is in the object's contents, after checking if it's a UUID, the VM would check if it's a valid URL.

I like that idea. This could also be applied to llRenderHTML and llRenderText in Programmatic Textures by allowing the string to be well-formatted XML or the name of a notecard in the objet's inventory -- Argent Stonecutter 06:31, 31 January 2007 (PST)

An alternate method, if Linden Lab were to host/cache the images so the Asset system information could be used to enable Copyright owners to stop content from being used:

llSetTexture(llExternalAsset("http://example.com/example.png"),ALL_SIDES);

llExternalAsset() would take any valid URI, and return a UUID that could be used with the appropriate existing LSL function. Any header information found in the file can be applied to the Asset system, so if a web page/image/sound/animation/etc. had creator/author/producer/developer attributes attached to it, the Asset Server will store that information, so it will be displayed in the UI (as opposed to the uploader of content in the current fashion). This would also give copyright holders an avenue to pursue DMCA claims, as the hypothetical system would indicate that they are owner, making things easier except for cases whereby the less scrupulous Resident did something like run an image through the GD libraries to strip out the metadata.

The llExternalAsset() implementation would also benefit greatly from caching, for two reasons:

1. You'd obviously not want a new asset to be created every time the script was restarted.
2. Lots of people might use the same resource, and
   1. this would help lower the amount of duplicate information being stored
   2. this would speed up subsequent queries
      1. In cases where the Asset Server indicates that the external asset already exists in the system, it'll have the option of attempting to receive a HTTP 304 header from the external source, or
      2. If one location for the asset is bogged down, the current simulator's local asset server can make the call and supply that image to the local simulator.
         • In this instance, after the local simulator re-downloaded the texture, binary comparison would have to be executed, and if the local sim's texture is different to the other sim's textures, then the other sim's asset servers would replace the old asset with the freshly downloaded one.

SignpostMarv Martin 07:20, 29 January 2007 (PST)

Creating assets for every frame of dyanmic content isn't really even an option. A web cam might be streaming 5 images a second through this. You are assuming that this would be for static images. That defeats the entire point of it. They can just upload the image if it's static. This is not some "save 10L on the upload fee" gimmick, the entire point of this is scriptable dynamic content. Gigs Taggart 11:54, 29 January 2007 (PST)

Yeah, but someone streaming a webcam would be better off using the parcel media stuff.

Would you be willing to pay for each asset you create with this method ? L$10, L$20, L$30 ?

SignpostMarv Martin 12:43, 29 January 2007 (PST)