[sldev] Re: More on Mute Visibility

[Able Whitman]

I figured an example was in order, to demonstrate how "mute visibility" as
I've currently implemented it looks, so I've posted a couple of screenshots
for comparison on my blog:

http://ablewhitman.blogspot.com/2007/06/trying-to-take-back-view.html

Cheers,
--Able


On 6/21/07, Able Whitman <able.whitman at gmail.com> 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
> ), 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/b535ccfa/attachment.htm