[sldev] More on Mute Visibility

[Able Whitman]

Howdy,

On and off, I've been investigating the feasibility of implementing
"Visibility Muting" as Nicholaz describes in VWR-1017 (
https://jira.secondlife.com/browse/VWR-1017), and as discussed in a few
threads on this list. I'm pretty close to having a proof-of-concept patch
ready which adds the ability to mute the visibility of objects by their ID,
in much the same fashion that the existing chat muting function works.

I'd like to know if anyone would be interested it testing the patch which, I
assure you, is rather rough around the edges. This is mainly because I
cobbled it together as I was learning how the visibility muting needs to
interact with object update messages and with the rendering pipeline. But it
works pretty well, at least for me.

Since there was a fair amount of interest the last couple of times this
topic came up, I thought I'd share some of what I learned during my
investigation. If you're not interested or don't care, I won't be offended
if you mute this thread. :)

The patch will add a new object pie menu item next to the existing "Mute /
Unmute" item, named "Mute / Unmute Visibility".

This is what the patch endeavors to do when an object's visibility is muted:
1.    The object is also muted "classically," that is, its chat is
suppressed, just as with a normal mute.
2.    Any particle system associated with the object is removed, just as
with a normal mute.
3.    All the textures on the object are replaced with a solid-white
texture.
4.    Phantom objects are made completely transparent.
5.    Non-phantom objects are made 67% transparent. (They are not made
entirely transparent because I believe that object collision happens in part
on the server, so avatars would still run into them. This way they are at
least visible enough to avoid.)
6.    Attached sounds on the object have their gain forced to zero.
7.    Hovering text on the object is removed.
8.    Objects have their light source and fullbright settings turned off.
9.    Touchable objects have their click action removed.
10.    Objects for sale are not purchasable.
11.    Objects have their angular velocity (llTargetOmega) forced to zero.

If a muted object is part of a link set, all objects in the set are also
visibly muted. At the moment, only LLVOVolume objects are visibly mutable;
so you can't visibly mute things like avatars, trees, the ground, the sky,
etc.

The patch works by extending the existing mute list capability of the
viewer, adding a new OBJECTVISIBLE mute type. There are a lot of places in
the LLPrimitive, LLViewerObject, and LLVOVolume classes (more than I
expected) that are hooked into altering their behavior when an object is
muted. There are portions of this patch that I am not at all happy with
because they're quite a hack, but now that I know what I'm doing (more or
less), I think the implementation can be much improved.

A few observations from testing visibility muting so far:

1.    It is possible to mute buildings -- houses, clubs, skyboxes, etc. This
seems like an obvious statement, but I hadn't considered the implications of
it until I tried muting my house. At first this was mildly amusing, but it
does raise some very important privacy concerns.

2.    Muting lots of individual, unlinked objects -- like lots of ad cubes
or billboards or whatever -- is a pain. I might jam in a Client menu item
and a keyboard accelerator, just because clicking the object pie menus over
and over is really annoying.

3.    It really, really reduces visual clutter. There's no question that
visibility muting, even in this rough form, is very helpful at eliminating
clutter and spam from ad prims and the like. Even though you wind up with a
bunch of semi-transparent cubes hovering around, it's a huge improvement.

I also learned some things about the feasibility of doing visibility muting
by-owner or by-parcel:

Mute-By-Owner is a nice idea, technically possible, but a bad way to go.

The problem is that the owner information is not included in the
ObjectUpdate message (or any of the related Update messages). In order to
ascertain the owner of an object, the viewer must send a
RequestObjectPropertiesFamily message and wait for an ObjectProperties
reply.

There's a significant amount of latency involved here -- it's the same thing
that happens when you Edit an object and wait a moment before the "General"
tab is populated. In order to implement Mute-By-Owner, the viewer would have
to make this request for *every* object that it gets an ObjectUpdate message
about. The patch already generates a good deal of extra ObjectUpdate traffic
in order to trigger the initial muting / unmuting of an object, and adding
this additional overhead would be simply untenable.

Mute-By-Parcel is a nice idea, but it also has its share of complications.

First and foremost is doing the work of figuring out if an object is in a
given parcel or not. This in itself is not a trivial task, since parcels
aren't always rectangular. Getting the border geometry of a parcel also
requires a request and reply message from and two the viewer.

Also, the viewer would probably have to request information for all the
parcels in the agent's current draw distance. With a 16sqm minimum parcel
size and a maximum draw distance of 512m, this is potentially a very large
number of parcels.

Basically what the viewer gets is a bounding rectangle for a parcel, and
then a bitmapped array indicating which of the 16sqm subplots within that
rectangle actually belong to that particular parcel. While doing an "is this
object in that parcel" determination isn't terribly difficult, it's not
trivial, and it would have to be done for every N objects in the viewer's
object list, against M parcels in the agent's draw distance, which is
potentially a lot of extra work.

On top of all that, there's the problem with tracking objects that are moved
into a parcel but not necessarily initially rezzed within that parcel.
Simply matching an object to a parcel isn't enough, because vehicles or
other moving objects which happen to cross into a parcel that is muted would
become muted when they entered, and unmuted when they left. This isn't an
ideal situation, so the viewer would also have to track whether an object
started out in a muted parcel or not. It's also worth considering whether
parcel muting should go "all the way up" or only cover objects rezzed below
the map limit (400m).

As I've said before, Mute-By-ObjectID is a useful approach, but ultimately
one that can be defeated by clever scripting, since object IDs change
whenever an object is rezzed by an agent or by a script.

At any rate, it was a thoroughly interesting (if sometimes desperately
frustrating) experience even getting this far with the visibility muting
idea. I'd love to have a few adventurous people give it a whirl and then
give me their feedback when I've got the proof-of-concept patch ready.

Cheers,
--Able
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/984969f6/attachment-0001.htm