[#VWR-11644] Attachment conflict scheme for multiple attachments per point

1. Second Life Viewer - VWR

VWR-489

Attachment conflict scheme for multiple attachments per point

Created: 21/Jan/09 06:35 AM Updated: 03/Feb/09 05:58 PM

Return to search

Component/s:

Avatar/Character, Inventory, User Interface

Affects Version/s:

None

Fix Version/s:

None

Description

« Hide

Carlo Wood proposed a way to decide which attachments would replace which other at the SLDev mailing list:
[sldev] Proposal for Extending the number of attachments per attachment point.

Here's my try to reformulate his proposal to be shorter and (I hope) easier to gasp:

Up to now an item replaces another one if and only if they are of same "type" (for clothing) or would occupy the same attachment point (for HUDs/attachments). The feature would add ~~(mutually exclusive)~~ "categories" to what we currently have and an attachment/HUD would then only replace another one if and only if they would occupy the same attachment point AND ~~both be of the same category~~ share at least one category (one item can be in multiple categories at once, or none at all). For clothing (as the proposal is now) nothing would change.

Users would be able to change the names of the individual "categories" to reflect their actual usage. Because the usage of the "categories" doesn't actually has to be in the sense of conceptual categories, maybe "slots" would be a better name. (Up to now, each attachment point has a single "slot". With the new feature there would be N "slots" per attachment point. Each slot can hold exactly one worn attachment at a time. Any newly worn attachment "pushes" a previous attachment at the same slot of the same attachment point (if any) "out of the slot".)

Carlo proposes to implement this by the usage of bit-masks

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Boroondas Gupte added a comment - 21/Jan/09 06:52 AM - edited

If someone can think of a shorter but still accurate title for this subissue, by all means change it!

Carlo asked for some brainstorming, so let the discussion begin!

Some thoughts from me:

Extending this to clothing could probably be done mostly on the viewer side with minimal server side changes: The viewer would just have to bake some more texture layers into one before uploading them to the simulator. Only thing the server would have to be able is to track multiple clothing items of the same type as "worn" instead of only one.
What about an overall limit for the number of attachments lower than "number of slots per attachment point" (16) times "number of attachment point"(currently 37 if I counted correctly) (the parent issue proposes a total of 31, some comments 60)
Wouldn't it be good if clothes could also replace attachments and vice versa? (so newbies don't end up accidentally wearing both a prim skirt and a built-in one). This would probably require a much higher number of categories/slots to be useful, though.

[ Permlink | « Hide ]

Celierra Darling added a comment - 21/Jan/09 03:45 PM

Shortened the summary

[ Permlink | « Hide ]

Aleric Inglewood added a comment - 22/Jan/09 05:23 PM - edited

From a pure technical point of view,

this would require two (or even just one) byte extra per object (attachment).

The original proposal talks about class names, but really all we have are bits
in this new bit mask.

Different attachment points are completely independent, so it suffices to
look at only one attachment point (for example the 'spine').

Suppose that three attachments already exist, with these masks (only showing 4 bits):

Attachment A: 0000
Attachment B: 0001
Attachment C: 0110

Then, the user attaches an additional object D to the same attachment point.
If the Mask of that new object is M, the following table shows what would
happen:

M
0000 : D is added, A, B and C remain.
0001: D is added, B is removed (A and C remain)
0010: D is added, C is removed (A and B remain)
1000: same as 0000
1101: D is added, B and C are removed (A remains)

In other words, the new attachment, with mask M1) is always added,
and the currently attached attachments with mask M2 are removed
if and only if (M1 & M2) != 0.

All of this could be implemented purely client side, if
the server would simply NOT remove old attachments (if
any arbitrary number of attachments would be allowed,
and an attachment would only be deleted when explicitely
detached). However that has two major drawbacks:

such behavior would not be backwards compatible.
allowing an arbitrary number is not practical to begin with.

The second point might be an argument if one is afraid
that this might lead to too many prims being used for
attachments; however - if that is a concern then the limit
should be on the total number of attached prims, and NOT
the number of attachments on a single attachment point.

I am convinced that it would be a mistake to make the
formula "(M1 & M2) != 0" asymmetrical in M1 and M2.
Nevertheless, this very method (as opposed to "simply"
enumerating classes) would allow a user to say:

"I want to be able to wear X and Y at the same time,
but not X (or Y) and Z at the same time."

For example, X could be a bracelet, and Y too, that
can be worn separately but also look good together.
However, Z could be sleeve of a jacket (a prim) that
would hide the bracelets partly, only seeing some
parts stick through the sleeve. Therefore, using
a bit mask is way more powerful than using
enumerates. The only disadvantage is that the
total number of attachments would be limited
to roughly the number of bits in the mask. But
since already four attachments on the same point
seems quite a lot (and certainly a LOT better than
only one, like it is currently the case) - that is not an argument
against using bitmasks.

Finally, there is the point of userfriendliness.

By using a default that mimics the current behavior,
nobody is going to be confused. At most people
will ask questions to a mentor or on a help forum/sim
about being able to use multiple attachments
at which point it can be explained. Giving each
bit some predefined meaning would ONLY be
for vendors to pick some reasonable default,
but not really necessary at all. In fact, maybe it
will be better to simply add a few check boxes
(one for each bit) and not give them a name.

The only real problem that I'm concerned about
at the moment is that these masks should really
be modify at all times; and I'm not sure if that
is possible for no-mod objects because I
can not see the server-side implementation.

[ Show » ]

Aleric Inglewood added a comment - 22/Jan/09 05:23 PM - edited From a pure technical point of view, this would require two (or even just one) byte extra per object (attachment). The original proposal talks about class names, but really all we have are bits in this new bit mask. Different attachment points are completely independent, so it suffices to look at only one attachment point (for example the 'spine'). Suppose that three attachments already exist, with these masks (only showing 4 bits): Attachment A: 0000 Attachment B: 0001 Attachment C: 0110 Then, the user attaches an additional object D to the same attachment point. If the Mask of that new object is M, the following table shows what would happen: M 0000 : D is added, A, B and C remain. 0001: D is added, B is removed (A and C remain) 0010: D is added, C is removed (A and B remain) 1000: same as 0000 1101: D is added, B and C are removed (A remains) In other words, the new attachment, with mask M1) is always added, and the currently attached attachments with mask M2 are removed if and only if (M1 & M2) != 0. All of this could be implemented purely client side, if the server would simply NOT remove old attachments (if any arbitrary number of attachments would be allowed, and an attachment would only be deleted when explicitely detached). However that has two major drawbacks:

such behavior would not be backwards compatible.
allowing an arbitrary number is not practical to begin with.

The first point, backwards compatibility, is addressed by the proposal by giving one of the bits a special meaning, called "legacy attachment": every object that currently exists would have only this bit set. The result is the exact same behavior as currently is the case, by default. The second point might be an argument if one is afraid that this might lead to too many prims being used for attachments; however - if that is a concern then the limit should be on the total number of attached prims, and NOT the number of attachments on a single attachment point. I am convinced that it would be a mistake to make the formula "(M1 & M2) != 0" asymmetrical in M1 and M2. Nevertheless, this very method (as opposed to "simply" enumerating classes) would allow a user to say: "I want to be able to wear X and Y at the same time, but not X (or Y) and Z at the same time." For example, X could be a bracelet, and Y too, that can be worn separately but also look good together. However, Z could be sleeve of a jacket (a prim) that would hide the bracelets partly, only seeing some parts stick through the sleeve. Therefore, using a bit mask is way more powerful than using enumerates. The only disadvantage is that the total number of attachments would be limited to roughly the number of bits in the mask. But since already four attachments on the same point seems quite a lot (and certainly a LOT better than only one, like it is currently the case) - that is not an argument against using bitmasks. Finally, there is the point of userfriendliness. By using a default that mimics the current behavior, nobody is going to be confused. At most people will ask questions to a mentor or on a help forum/sim about being able to use multiple attachments at which point it can be explained. Giving each bit some predefined meaning would ONLY be for vendors to pick some reasonable default, but not really necessary at all. In fact, maybe it will be better to simply add a few check boxes (one for each bit) and not give them a name. The only real problem that I'm concerned about at the moment is that these masks should really be modify at all times; and I'm not sure if that is possible for no-mod objects because I can not see the server-side implementation.

[ Permlink | « Hide ]

Boroondas Gupte added a comment - 23/Jan/09 02:16 AM

Thanks for your comment, Aleric (Do you happen to be Carlo? If so, you might want to include that fact on the wiki). When reformulating I didn't consider the case where an item has several bits set. (I somehow assumed each attachable item would have to have exactly one bit set.) Of course, like this the "categories" aren't mutually exclusive anymore and the "slots" analogon doesn't work out as well as I thought. I've edited the issue's description to reflect this.

[ Permlink | « Hide ]

Haravikk Mistral added a comment - 03/Feb/09 05:58 PM

An interesting idea!

Not sure a sub-task is the correct place for it, as it's not a requirement of the parent suggestion, since people can probably get by with a "replace all" and an "add" option when attaching to a specific location (and a way to remove from a specific location).