Web pictures on the inside

I was just thinking it would be cool to have the capability of bringing in pictures from the web to texture an object... why?

Well remember in Snowcrash, there was a globe Hiro got from his girl... and the glob showed real-time conditions of the earth??? Well we could duplicate that a little bit by mapping a globe with satalite pictures which can be updated every minute or whatever....

Or other things/ pictures that don't need to be saved in-world, you know, non static images????

Waddaya think?

Love Ingie

Ah, you may be interested in checking out xplanet and some of the server resources that it uses-- there are scientific data sites that provide realtime satellite imagery that can be rendered onto a globe--- clouds and everything. It's my background image on my PC.

In theory, what you suggest sounds nice. In practice, I'm not sure that the SL backend was really built for this kind of thing.

My thinking might be wrong, but it would imply either a fairly long load-time delay or an incessant tap on SL database resources to keep a texture up-to-date with the web-based version of an image.

But, yeah, it'd be kinda cool for slowly dynamically-updating textures. Someday, perhaps, we could include streaming audio and/or video, here, too, as long as we're being visionary...

I do shudder to think of all the objects that would wind up covered in 404 errors. ^_^

Ben

In addition to all the broken image icons we would see on objects, what about the bandwidth of all the poor people whose images get linked? Talk about Slashdotting. I won't go into copyright issues either.

*visions of pop-ups dance in my head*

No actually I'd love to see this develop. I imagine as the XML functionality is added, it will be.

Here's how I'd like to see it implemented:


Early version OPT-IN LINKING

Place a hyperlink script in any object, and anyone could right-click and choose Open Link. This would launch their web browser in a reduced window and take them to the image or any other website. This should only work as a right-click option like Sit. Perhaps there could be a viewer option that Highlights Links in the area.

This would be excellent for card games, and for something like Nephilaine's amazing Pixel Dolls catalogue.


Later version IN-GAME PANES

Dynamic texturing on prims! The image linked directly from a website. This probably does need to wait until the next generation of broadband services.

There's no reason for the SL database to download an image that's hosted elsewhere, if all that's needed is for that image to me mapped to a globe.

Instead, the globe's texture should be a link to the image. Saves SL's bandwidth, and servers.

It also potentially degrades performance. When all images are on SL servers, they are all essentially equivalant performance wise. If the image is somewhere else it could be really, really, really slow to load, have a slashdot effect or the image could not be found. All cases it will be SL who takes the blame. Not saying it isn't a good idea, shouldn't be thought about, or anything like that. Just saying that like many, many ideas I see, it may not be as trivial or as QED as perceived.

ActiveWorlds had something like this, I'm not sure how it worked technicly, but you basicly have a sign object then you put in "create url (urlhere)" or something like that, and it would have to be a direct link to a image, so it'd be like www.secondlife.com/secondlife.jpg etc.

They could restrict what file types you use, maybe only be allowed to use .jpg or .trg or whatever.

I think its a good idea. And why worry about copyright? Someone could just take a picture and upload it anyway.

The only real issue would be bandwith or slow loading, which I don't even think would be that much of a problem.

I endorse this idea/feature.

What about leeching? For an object etc at a popular location that got a lot of downloads, and the image came from some other server that wasn't aware.... not copyright but use of anothers bandwith which isn't generally free.

Hmm, true, I don't really have any ideas on that one.

Final Fantasy XI has something that's sort of the reverse...you can view actual in game action on their website via a first person roaming camera. Don't know if it's still there but it was really cool.

Close.

It was 'create picture http://omg.haiasl.com/blah.jpg' - and it would download the picture and use it for the texture. Limited to JPG only however.

You dont need to worry about slashdotting/etc, for two reasons

1) cache
2) SL has with the most optimistic estimate about 4000 players - 1 download x 4000 = no bump on webserver traffic whatsoever.

-Adam

Well, the image would certainly have to be converted to a JPEG2000 image, which would require caching.

Remember, though, that the Lindens have to pick and choose what features or bugs they can work on based on the amount of effort required and the value of the bug or feature.

Fixing crash bugs, or implementing something like XML-RPC are priorities because they improve the quality of the product and attract and keep more users.

The amount of effort required to implement something like this, while probably not that big a deal, is still effort. Aside from viewing a webcam image in SL, or using a script to generate an image outside the world, there really is no other use for it. It's something that would be nice to have for a few specific things, but you'd have to convince the Lindens that it'd improve the world enough to make it worth their while.

Since when?

I believe it would simply require a few rewrites to the client's texture rendering interface.

I think of it like this:

To load a texture onto the side of a cube:

1. The client gets a path to the image data to load on that face by the server.
Ex.
asset://119.293.192.300/textures/foo.texture

2. The client requests the image data from that path.

3. The client get this image data, assumes that it is JPEG 2000 data and makes the user-specified modifications (repeats per face, rotation, etc) to that image data.

4. The client renders the texture on the side of the prim.

The only changes that need to be made, are in steps 1-3.

In step 1, the server has to send the client a different, userspecified path.

In step 2, the client has to keep in mind that the path isnt always the asset:// protocol (most likely http://).

In step 3, the client must understand that the image data it is modifying isnt always JPEG 2k data. Perhaps user-specified modifications can be disabled for textures who's path's are specified by the user.

Im not exactly sure about this process... but I think it would be the logical thing that would be done; I dont think the server does things this mundane.

==Chris

Sorry, I misspoke. To enable caching, it would require a server-side JPEG2000 converter.

Rewriting the client and texture streaming protocol to accept formats other than JPEG2000 seems kind of insane to me. It would be simplest (though still a lot of work) to make it completely server-side, since there would have to be some kind of system in place to tell the caching server to download an updated image from the website.

Pfft

If something as simple as a webbrowser can display images in jpeg and gif formats, what's so hard about implementing support of them in the SL client?

==Chris

Um, what browser are you using that takes those images and maps them onto 3d prim shapes, stretches and contorts them and renders them in a 3d virtual world at any angle a person might be looking at them? Not saying its not possible or easy or difficult or anything, just that its not a comparison.

Well, you know in the "weather globe" item, it wouldn't have to automatically refresh the picture constantly. In fact, Weather sites make you click on them to refresh the picture… so you could do the same thing with the globe, and it would hold the last picture until it’s refreshed. You wouldn’t have to slash-dot a site… it’d be the same as using those sites already available.

I guess that a temporary cache of the picture could be used, or else a texture could cover the item until it’s clicked on. Then it wouldn’t be too much trouble if the texture were replaced by a satellite picture only loaded down on to the person’s computer who clicked on it. Not needing to be cached in SL itself?? I think that’d do it, maybe?? You could still share information that way, but both parties would have to click on it to get the information……….

I think it’d be cool for all kinds of things actually… Lets say you want to do a tutorial for an event, and to do the tutorial, you’d need to download 25 pictures…costing $250 LD. If you could just make a board display your website and just have everyone click on it, page by page… you wouldn’t be clogging up SL’s memory with one time only pictures… and costing yourself all the money you were hoping to earn by putting an event together.

I mean, after a while, the junk we upload has GOT to cost a TON of memory, and everyone has a copy of so many doubles, just renamed, etc… it must cost memory like crazy!! I think it’d help a ton in the long run… when SL grows bigger and bigger… shoot it’s so new and look how HUGE SL is now???? WOW!

Just my thoughts, Love Ingie

I don't think they use jpeg2000 because of any special added ability to morph the textures (rotate, stretch, etc), but rather because they lend themselves well to streaming.


What if we had a way to push new textures into the game programmatically, instead of going through the manual process we have now? You could have a robot process that uploads a current weather map texture for the globe every 15 minutes, say.

If SL acts as a caching gateway, the asset server can download and cache the image (this would also help with performance).

Periodically, and only when necessary, the asset server could send an HTTP request to see if the image has been updated (note this requires very little data to perform a check since you don't have to download the image to know if it's been updated.

I agree. My point was merely that while a web browser can easily handle rendering different file formats, SL isn't a web browser and has different considerations and so really can't be compared to one. Even streaming is a good example, we don't want people linking to TIFFs or BMPs in SL.

This is I think the right answer and method! It gets my full support.

llGetWebImage("http://www.amaprotu.net/mynewphoto.jpg";

Would require debit permissions and charge the $10 fee.

I know this flies in the face of the original post, but if we are back to caching the image, then we aren't just showing images hosted elsewhere anyways.