[sldev] More on Mute Visibility

Nicholaz Beresford nicholaz at blueflash.cc
Thu Jun 21 05:31:18 PDT 2007


Wow Able, now that sounds like hours of extensive research and
work :-)

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

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).

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?

 > 4. Phantom objects are made completely transparent.
 > 5. Non-phantom objects are made 67% transparent.
 > 11. Objects have their angular velocity (llTargetOmega)
       forced to zero.

And these just depending how complex their implementations are?
 > 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.


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).


Nick



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



More information about the SLDev mailing list