Outworld Content On A Prim

A Feature Proposal about loading textures from url's rather than the data server

I posted this in one of the Linden forums forgetting that I couldn't get resident feedback there. So I'm cross posting it here in case someone would like to comment .

So I hear that the intarweb on a prim is only a few weeks/months off. Very cool. Unfortunately/Fortunately this gives me a new and slightly related idea .

You see this web page on a prim thing lets you put pictures, among other things on a prim face... so could we maybe get the ability to specify an image by url for use a as a plain ol texture?

NO, I don't mean: will the web on a prim have this functionality.

I mean I want to be able to open the texture selector, and it should show, maybe underneath the standard inventory texture picker, a url text box where I can type in the url of a tga file that is already in an appropriate format and have it load straight from that url for everyone who sees the object textured with it.

This would allow a couple of neat and useful things to happen:

1) it would reduce the load on the dataserver.
2) it allows externally generated and possibly dynamic content to be placed in world without haveing to manually upload it.
3) while the web page rendering is good for some things, a simple image from out world doesn't need to be treated as a web site, it just needs to be seen as a resource from a source other than the dataserver.
4) this would avoid the security and exploit concerns about web pages being parsed and executed behind the scenes.
5) This type of externally stored texture could still be manipulated via the texture tools. in fact to avatars walking around in sl you should not be able to tell what textures are being loaded this way, unless the server the image is being hosted on is overwhelmed and loading slowly. In that case it's not LL's problem as it is never goes through their network.
6) This allows for images that can be updated in one place and the updates would show across SL without having to run an updater in world or manually go retexture all your signs/vendors/builds/etc.

Please Note: This will not replace in world resources. In world resources are still better for things that are going to be sold and don't need the dynamic updating ability, because then the seller does not have to maintain the resource. Also, not everyone has access to or the desire to get web hosting.

7) That being said, all of you content creators, skin artists and such, wouldn't it be nice to test your textures before uploading them instead of having to upload 20 tries for one good end result ?

One thing...

Textures as they're sent out to the client are NOT in the same TGA format that's used to upload them. They're compressed with something cunning (JPEG2000 I think, but I'm recalling vaguely from memory).

There would also be a bunch of issues about accountability, risk, etc. In SL, if I put a texture in a totally unacceptable place (outright adult content openly in the middle of a PG sim, etc.) then it's within the realms of might-be-possible for the Lindens to remove the texture entirely from their servers, or at least apportion blame properly to whoever uploaded it. If someone decided to steal images from my websites (leech-linking) for use on their builds, then I would be very likely to swap stuff round on my webspace in order to disrupt their build as retribution for stealing my server resources (i.e. goatse/tubgirl appearing where the leeched image had previously been seen).

I've been playing with faking this by use of image URLs as parcel video sources, so I do like the possibilities it would open up (dynamically-generated images containing information from in-world and/or RL sources). I'm just not sure how good an idea it would be to make it a totally open and easily-used part of the feature set.

heh, ya I had a lot of these thoughts while hashing out the idea.

I forgot about them not being tga format but it doesn't really matter. it could be any format as long as something can save to it. The important part is that the client looks at the data and can use it without doing conversion, or kick it out as invalid.

Currently when someone places totally inappropriate content in SL, LL doesn't remove the asset, it just removes the object from the location where it's not allowed. As far as pulling images from a website... well people already do that but you're right, at least they aren't using that sites bandwidth. However, if it does have to be in jpeg2000 format and a specific aspect ratio, the chances are this isn't going to happen that often. Not to mention that the person being leached off of can break it simply by changing the image name/location or making sure the refering site is their own. And since this is not going directly through LL's servers, it's not their responsibility any more than it would be Mozillas if I leech using firefox. or maybe a better example would be it wouldn't be MS' responsiblity if I to use the windows web server with a page that contained a leech link.

Good feedback though . I always hope that if I can present the entire case up front and leave little enough for LL to do, they'll just go ahead and put it in because it looks inevitable (I know I know, but let me have my illusions).

it would also be possible I suppose for LL to include a blacklist check in the client. The image would not have to be stored on their servers. The SL client could announce itself as the browser along with a complaint email address that a site admin could get ahold of easily enough. If they report the leeching to LL via that email address then LL would add the domain to their blacklist. The SL client would then have to check to see if the domain had been blacklisted. blacklisted domains could be cached too. If your client doesn't know a domain is blacklisted then the valid domain would remain in cache for say 12 hours. After that 12 hours the cache expires and if the client sees a url with that domain again, it has to recheck. The actual image could stay cached longer than 12 hours and simply be removed from cache should a domain check show up as blacklisted. A blacklisted domain would remain in cache much longer and if a domain were ever to come off the blacklist it may be that clearing the cache would be required to see things there again. But I kind of doubt that a domain will come off the list very often.