Two LSL Functions

These are two I thought up that I'd like to see implemented at some point, not sure if these have been suggested already...

llTakeSnapshot(integer face, string snapshot_name) - This would have an object take a snapshot from the face of the object as defined by integer face and name it snapshot_name. The snapshot would then go to the objects inventory and would not charge the owner for the snapshot. If integer face is ALL_SIDES the object will take snapshots from all sides somehow and name them all as you'd assume (snapshot, snapshot1, snapshot2 etc.). I don't know if this would be possible to do, but it'd be very cool, it could allow for people to make "cameras", enable time lapse photography, and also make "mirrors" possible. While I could see people using "cameras" instead of the snapshot button because it wouldn't cost money to do this, I think it needs to be free for things like time lapse and mirrors, maybe if there was some charge for taking it out of the object? I duno.

llSendTexture(key id, string texture_name) - This would send a texture/snapshot from the objects inventory to the user as defined by key id. I don't know if this is very usefull but it might come in handy somehow. I was at first thinking to use this along with llTakeSnapshot and having llSendTexture charge you 10L$ so you couldn't get past that, but then I remembered people could just go to the object and take it out themselves. Heheh. But I thought I'd post this one too as well.

Edit: *Eats vB Code*

It's a good idea, but you have to remember that in a VIRTUAL world, the answer to the question, "if a tree falls in a forest when no one's around to see it, is it visible?" is "definitely not".

The SL client isn't a portal into a world that exists, it's a rendered representation of data sent to us by the SL servers. Everyone's experience is subjective -- we all see the world slightly differently, though we all get the same data with which to render it.

So I guess basically what I'm saying is that if you wanted a snapshot, you would need a client -- with a decent video card -- to download and render all the object and texture data at that point, then upload the screenshot to the server. And that's not really efficient for what you want, you know?

Now, IF the Lindens were at all interested in adding a computer with a GeForce FX 5950 Ultra card specifcally for this purpose, yeah, I'd say go for it.

...but it wouldn't be at the top of my list.

Also keep in mind that the reason for the $10 linden upload fee is the space the image/sound takes on the asset server. This fit inline with the original economy, but doesn't so much with 1.2.

I wish there was a way to remove content from the asset server, especially in cases of bad uploads / trials.

Other than that, Catherine hit it. The "world" is just numbers and data, there is no picture for an inworld item to take, nothing to render it. The only other way to do it is really impractical - record all the data in the view of the camera. Then you can have the viewer render the image when it renders the scene. Problem? Even 1 would bring most computers and vid cards to its knees, you are essentially asking it to render 2 scenes at once. And you know if the feature existed it wouldn't be 1 - it would be a house of mirrors, 100s of these. Yeah, thats not going to happen soon, please.

I wish there were a way to upload temporary textures for free. Make them no-transfer, and should last at least an hour or so (preferably a day).

This way they are deleted from the database, and they don't use up storage resources.

I talked to a Linden about specifics including when the asset server cleans itself. They run a reference checker about every week on the asset server, and any keys not referenced to anywhere IW (including source code, which was my reason for asking, I was wondering if a texture in my inv I uploaded and deleted would still be able to be used by my script indefinately by-key) and deletes it.

Feature Request:
It would be nice to get refunds based on this deletion, then textures/sounds can be as versitile as prims were in the previous economy! (when rezzed, cost was $10, refunded when object taken back into inventory). When you upload a texture, it gets assigned a new key, and the asset server starts counting the references you make to that texture. Once the # of references reaches 0, the owner can be refunded.

Oops. Sorry about the hijack

I wonder if the L$10 goes to the storage of the actual texture, or the uploading of the texture itself...

==Chris

To save server space and bandwidth, make uploaded textures local-machine-only so they can use it on objects and avatars to test, for free. Other players would see "Missing image" or the blank texture.

If they don't like it, they delete it, and all references to it in-world go to missing-image or blank.

If they do like it, they can trigger it's final upload to the servers, and it becomes a normal texture.

While it is temporary, it is locked as NO-Transfer. This flag returns to the default when the texture is accepted/uploaded.

There's no reason we can't let our own video cards have access to local textures without having to upload then download them first. There should be more than one previewing texture allowed at once, and quitting the game clears them all. (It's not like you don't have a local copy, anyway.) They should have their permanent keys when first created... IF the system allows for recycled keys, since aborted temporary textures will burn through them.

(Screenshots, the in-game variety, should work the same way -- Temporary and local until confirmed.)

[sorry for the hijack, but llTakeSnapshot is an impossibility, and llSendTexture can be done with an llGiveInventory]

Ah I forgot about llGiveInventory...

I don't think llTakeSnapshot is impossible though, how do other games have pictures updated from in game on a regular basis displayed on their webpage? Like FFXI and other several games do. You could basicly take the same method used there and apply them to making the screenshot in world rather than on a website.

However would it be reasonable to dedicate a server to doing this? (most likely that's what you'd need, or atleast a computer in LL doing it) Probly not.

The methods described for temporary textures would be cool to see.

Raise your hands, who wants a .01x.01x.01 transparent hollow 95% cut cube watching everything you do, possibly following you around?

What measures would you put into place to guarantee people knew these objects were around, and their precise location?

I thought of that too huns, but someone could pretty much do the same thing anyway by following behind you at a far enough distance and just keep zooming on you.

Also someone can already make a transparent cube follow you listening to everything you type. But most people don't.

The only thing that would prevent it is the same thing thats preventing most people from doing the above, its against the TOS and such, you could get in trouble, and most of us are too boring to do it too anyway.

It wouldn't take just one computer. Thought I aught to shoot that down right now.

You know how your computer pauses for a fraction of a second as the picture is taken, then uploads it? It takes a partial second to write to disk an already rendered scene. Now imagine the case of having 100 screens in different parts of the world to be rendered at once? That is an overly tame example and would still way bog down a high end machine, especially if you want special features turned on in these shots. I mean, we only get 30+ FPS on high end machines in SL. So now lets take a closer to reality example of 1,000 things taking snapshots at once, it would take the computer 33 seconds to process that - assuming it could write each screen to the disk instanaiously. Are we going to put a full minute delay on the function call?

More realistically you would need a graphics processing computer on each sim, and to handle it efficiently each one would probably cost more than the sim server itself. Even with that you are probably looking at long delays on the script call (probably in the 30 second to 1 minute range) just to prevent abuse.

I like the idea in concept, it just isn't going to happen. It takes too much processing power to generate a screenshot. And what about particle effects? And other client side effects? They only look how they do when you see them because they have been running for a while, and won't show correctly for a system that only looks at the scene for 1 frame.


----------------------

P.S. I post too much.

I see. Still if they can think of ways to get around all that I think this would be an awsome feature.

P.S. Yay 2004 go Ama!

Yeah, and there'd be a green dot on the map. Pretty different don't you agree?

How do you know they don't? How do you know what proportion of these things are caught and reported?

What I'm most interested in knowing is what mechanism you would propose for forcing cameras to make themselves known.

I was just thinking about something like this tonight (before reading this post).

Not so much for taking snapshots, but for security/anti-cheating/anti-griefing.

..and my brain churns..

Rule:
Can only snapshot on land you own or group land you're a member of (snapshot taking object could just simply have the group set to match the land).
......
The "snapshot" I invision isn't a pretty in-world representation, it's a record of objects/avatars in the area, say 50m or so "snapshot range".


Prim information would consist of size/shape/cuts/etc, position, and rotation -- and owner / creator info).

Avatars would be simple shape info, nothing complicated, just the shape, position, and rotation of the avatar(s), and of course their names.

Why have this? Well I'd like a bit of security to see if someone drags something into one of my games to cheat it. I can see other uses as well to "check on the homestead". I don't need pretty textures and toidee cams to spy on people and their norty bits. Nor a record of chat spew, or anything else intrusive. I'd just want to see what's going on when I'm sleeping, or when I've been gone at work. Already I can devise silly security sensors/collision events to check some things.. but a nice, albeit ugly, "picture" would help as well to judge what's going on in my neck of the woods.


...my brain stops churning, buttery fat has conjealed into a mass of yellowish puss like stuff...

Bos

Bosozoku, would your "snapshots" be like infared or something? Not quite getting what your describing.

Huns, this was already brought up once and I just remembered about it now. As was suggested then and I thought was a cool idea was that "camera" objects would be represented on the map in some form, maybe a small red camera icon or something, and maybe have lines showing what their viewpoint is, such as the map shows our viewpoint. Then you could easily see on the map where cameras are and avoid their viewpoint if you wish.

My figuring is as soon as you Save and compile the script your object would then be lit up on the map if it had the function in it.

Also you could do as Bosozoku said and have it so you can only place cameras on your property.

I'm glad you braught up the whole security thing because I think the above would be awsome additions to it.

i like ama's suggestion and kex's hijack. a temporary texture upload feature would save me a lot of money. rather than a time limit, i'd rather that all the textures upload to a temp file that becomes permanent when i check the box that makes it transferable.

if i don't like one then, i can delete it to my trash. when i empty my trash, it'll be wiped without ever really existing as a permanent file.

for oz's suggestion, i think it would be reasonable for the client to render a texture from any given view. it would need to be a client-based photo subsequently uploaded. that means that the client requesting the photo would have to be near the camera so that their client had all the relevant data.

I like the red camera idea. Add an option to beacon cameras in the View menu and you've got a winner.

BTW you don't necessarily need a video card for this, you could have a headless (i.e. no video card, communicates over serial/ethernet only) pizza box doing this using software OpenGL. Wouldn't be as quick though. There would also be scaling issues as more and more cameras turned up.

On this topic.... I'd love to see some sort of implementation of the security camera they have in the Half Life 2 demo movie. Does anybody know how much of this is Havok 2 and how much of it is Valve Source? Educated guesses? Wild guesses? (If it's mostly HL2's graphics engine we're screwed.... but if it's mostly Havok..... it could work.)

And Huns.... script detection objects would 'see' a camera like that. They're reasonably common.

0% Havok 2, 100% Valve. Havok only handles physics.

I'm afraid it doesn't have anything to do with Havok. Havok is a physics engine -- it calculates the position and motion of objects, not their appearence.

The "portal" rendering used by Quake 3 or Half-Life 2 is made possible by the fact that all assets are already loaded in a map. Second Life uses a streaming content system to download objects and textures from the servers.

In a static game enviroment, the portion of the level that appears to be a remote location is already in memory.

In SL, the remote location HAS NOT BEEN LOADED. The content must be downloaded from the SL servers. The delay you get when you teleport is what you could expect.

Right, but there's still a link of some sort between the 'camera' and the 'display.'

Eh if Havok won't do it probably something else will. Knowing it can be done gives you an advantage with regards to actually doing it yourself. Mostly I'd just like to see actual in game video, and I don't particularly care if it's Havok that allows it to happen or not.

It wouldn't be slow, it'd be painful. I'd estimate that software OpenGL can get about 15 frames a minute rendering the average SecondLife scene.

Depends on CPU and memory, and you'd get scaling issues whether or not you did it with a GPU. Doing it headless, you could have each sim handle its own snapshotting... but again it'd be a CPU hog.