[sldev] More on Mute Visibility

[Able Whitman]

Thanks, Nick! I originally intended only to figure out how to extend the
existing mute list functionality, but, well, I got a bit carried away. :)

I think the conlusions about parcels are interesting, pity that
> this road seems closed for the moment.


Actually, after I sent the email out, I did some tinkering with the viewer
code that's responsible for drawing  parcel borders. This already does some
pieces of what mute-by-parcel would require, at least in terms of reqesting
and storing parcel boundary information. I'll have to do some poking around
to see if a similar technique can be used for muting.

I'm currently thinking about giving it a try in my viewer build,
> but one of the things I can't (don't want to) do is to mod the
> the XML/GUI files (my viewer just is installed as a separate
> exe and doesn't touch anything inside the SL program folder).


It would be very simple to just replace the existing mute functionality with
mute visbility instead, and leave the menus alone. That would require
changes to the code that hooks up the menu handlers, but wouldn't touch the
XML.

Do you think there would be a version of your hack with reasonable
> impact on the source, just based on the regular Mute function?
>
> I'm just thinking of the basic visibility functions, hoping that
> these would affect just a few points in the source?


This sort of gets into why my current patch isn't really the best solution.

I took a rather brute-force approach to forcing the effects of visibility
muting, and I added code to special-case all the visbility properties of an
object wherever it seemed like they could be manipulated. The result, while
pretty effective, is inelegant at best.

If I was updating this patch for submission, I'd take the time to go through
all the tweaks and leave in only the ones that are absolutely necessary. I
understand if you'd prefer to have fewer changes to the source, but I would
prefer to put off the pruning until I get some more feedback. :)

A lot of the hacks I used stem from the fact that there are 3 different
messages the viewer can receive when an object is updated. There's
essentially a single event handler which updates the object properties based
on these messages, and it has a lot of special-cased code depending on the
message type, since they're all decoded differently. In some places, I
tweaked the getter/setter accessor functions for some properties. When that
didn't work, or wasn't possible, I tweaked the message handlers themselves.
And if *that* didn't work, I tweaked other things, even though I'm pretty
sure there are better ways of handling the probelm. So right now it's a bit
of a hodgepodge of tweaks.


> I'd then make a build and offer it to users to just gain a bit
> of feedback (although I fear that opening that door a bit might
> eat us alive with requests for more).


Well, I think I fixed the last crashing bug in my current patch. Right now,
I'm trying to track down a couple fiddly issues, but when I get a chance to
generate a diff based on what I currently have, I'll send it to you. Then
and you can judge whether it's something you'd feel comfortable putting in
your viewer or not. :)

--Able


> Able Whitman wrote:
> > 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
> > <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
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/506cb617/attachment-0001.htm