Avatar dependent transparency?

I have no clue if this is possible to script. So, I post this question as a challenge/RFI to those much more knowledgeable than I.

Is it possible to script a prim so that it appears transparent/invisible to some avatars but not others?

The use is relatively obvious - especially for small land owners.

Assume a small house with walls... basic box construction. The avatar is building within the confines of the house "seeking privacy" in doing so. Obviously, depending on the exact dimensions of the house and placement of the walls, eventually the camera begins to interfere with the building process. That is, in order to see from end to end on the built-prim-set the camera must be zoomed in a particular direction/vector. However, doing so causes the camera to "go outside" the walls.

Hence, the desire to maintain the walls but see through them while feeling that others cannot. I am not seeking "impenetrable" walls. Only asking if it is possible to make it so that the camera of avatar A can see through wall 1 while avatar B looking through the same wall from a different position but at the same time cannot see through it.

Any thoughts?

Don't think this is possible.

But it seems like what we need is something like "close clipping".

The camera is just outside the wall of the house. If there were some way to specify a short clipping distance, we might be able to get the effect that you are asking for. If the client would clip everything within a short distance from the camera. And make this distance a preference.

Don't know. just brainstorming...

I really wish there was a way to make object invisable, and visable for some.

Itottaly gree that there should be clipping in sl. But to have it work right. I think ll would have to let us define the clipping, through the use of boundrie boxes.

nope, not possible. People who make HUDs have wished for this a lot. The solution ll has promised is a customizeable UI which would allow for personal HUDs.

Regarding "close clipping", SL does actually use this. As a matter of fact, all modern 3D apps use a near clip plane, but most of the time the clip distance is set very close to the camera. I haven't searched through the INI files to see if there's any value for adjusting the near clip plane, though. Most likely not... but you can always check if you're so inclined.

There are, in fact, a couple ways to do something like this (responding to topic). It all depends on how elaborate you want to make your object, and regardless - anyone savvy to what you're doing or making good use of a camera perspective will be able to get around it anyway.

This is nothing but brainstorming solutions to your problem, by the way. The only true way to seek privacy in SL is by finding an empty sim.


Case One: Smoke Screen
Make heavy use of particles in your domicile, then shut off particles for your client.

Result: Irritation to any avatar that has no idea what you're doing, warding off many potential interlopers with the camera. Note any avatar with particles off, or in the case of a small plot, are off plot - can potentially still see you.


Case Two: Air Raid
Place your home at a high world height (eg. 512m).

Result: Many script-savvy landowners do this. The upside to something like this is, usually, people have no idea you're up there or just don't care. The downside is you still show up on radar so they could potentially find you anyway. I actually make use of something like this.


Case Three: Inviso-Prims
Best combined with solution number two. I'm sure, if you use the forum search feature (or check the Wiki), you can find the prim invisibility script on these forums or the Wiki. Utilizing a well-known "bug" (I would say exploit, but it's borderline since you can still see people if you try ), you could build a wall of invisible prims around your domicile. Note these are the ones that utilize said bug, not a truly "invisible" prim.

Result: Assuming someone doesn't know *exactly* where you are, nothing should render through these prims but completely non-transparent primitives (eg. attachments set to no alpha transparency will be seen through this, but any prim, attachment or otherwise, with an alpha value of even just 1 percent should not render through the wall. Same thing with .TGA textures with alpha set, I believe). In this respect, no one will be able to see you or your build unless they mouselook through the wall, which you can do little or nothing about.

As a caveate, you can also also view through an inviso-prim to "see through" walls with, say, 1% alpha.


As for my $0.02 to what we should have: llDetectedCamera() and a sensor constant CAMERA (extra data for the client to pass to the server, though). That way, if a camera enters a certain radius, let the person know or Do Something Bad to the person in question.

You could use dot product math to have prims detect when someone's looking at them, and have them become visible or invisible that way. Yes, that's very silly.

dosen't that assume the direction the avatar is point is the direction they're looking?

Yup.



I agree with both suggestions, but I must expand on the latter. Both llDetectedCameraPos and llDetectedCameraRot should be implemented rather then a single llDetectedCamera, to give scripts a more precise view of what exactly the camera is looking at.

Additionally, llDetectedCameraDist and llDetectedCameraAngle should be optionally implemented:
llDetectedCameraDist gives the viewing distance of the camera and llDetectedCameraAngle gives the angle from the center of the camera's view to the edge to account for shifts in the lens of the camera (done with ctrl + 8, ctrl + 9, and ctrl + 0)

I dont think the implementation of those functions creates a need for more client <-> server communication, as the server already needs to know the position and rotation of the camera on the client to pass the client the correct set of objects in its viewing area. (There is also evidence to support this, when moving the camera around, you can see your avatar triggering partial object updates). Its just the refactoring required to make this information available to LSL.
==Chris