The verdict is in, and server-side appearance is a big win all around. Bake fails have dropped to being very rare and fairly easy to fix. One whole class of copybots has been rendered much less useful (those that copied system clothing). Rezzing is much faster, as are outfit changes.
Nevertheless, not all is rosy in SSA-land. Before SSA, the viewer had the ability to set the avatar's bounding box height. The bounding box is the box the server's physics engine uses to decide when the avatar is going to collide with something and take appropriate action. Adjusting the height had the effect of changing the center point of the avatar, and thus making it rise or sink vertically.
SSA changed that. Since all of the parts of the avatar's bounding box are determined by the shape and attachments the avatar's wearing, the SSA bake oven can figure it out all by itself. So it does. Since it's being done server-side, the viewer now has no ability to control it.
This removed a useful and popular feature. Many pre-SSA viewers had a control, like the one Firestorm called Z-offset, that let the user move her avatar up or down. This was useful for mundane things like not sinking into a chair, as well as compensating for some rather extreme clothing and the like.
It was also widely used to compensate for animations that were set up for one height of avatar, making them lift smaller avatars into the air and sinking larger avatars into the ground. This capability was automated in the RLV specification with the @adjustheight command.
When it was discovered during SSA testing that the Z-offset feature no longer worked, we raised the issue with the folks at LL. Nyx Linden went out of his way to implement a fix on his own time: the hover attribute on an avatar's shape layer. The fix works well for what it does, but it doesn't cover all of the use cases - and arguably the ones it doesn't cover are the most common ones.
Henri Beauchamp fixed the omission. Unfortunately, he did it in a really hackish way: he took the Z-offset specified with the control, or @adjustheight, and modified the shape the user is wearing. It works, to be sure, but it's a real kludge.
There are several problems, most notably that the shape must have modify permissions for the feature to work at all (else the SL permissions system is violated, a strict TPVP violation) and adjusting the height results in modifying an asset on the SL asset server. I find the latter most curious, since Henri resisted implementing the current outfit folder in CoolVL Viewer based on his unwillingness to depend on automatic asset updates from the viewer.
The Firestorm team discussed it internally, and decided not to implement this kludge. We felt it was just too problem-prone, as well as either being limited by the permissions system or else requiring a violation of it to be useful in many cases where the user has purchased a no-mod shape. As it happens, LL has said that shapes are not intellectual property and therefore not protected by the permissions system...but bypassing it on this basis makes us vaguely uncomfortable. (And yes, allowing shape import/export makes us a bit uncomfortable as well, but since the LL viewer does exporting without considering permissions...)
Marine Kelley now has a product, the Pretty Mummy set, that depends on @adjustheight to work properly. It looks really nifty, with several components, both fitted and unfitted rigged mesh, and has a lot of capability and a lot of complexity. However, it apparently does not work well if @adjustheight is broken. Marine's answer is to tell people to use her viewer or CoolVL Viewer, which have Henri's kludge in them. (She also tells people to use Singularity, but according to one developer, that viewer doesn't have the kludge - and won't implement it either, for the same reasons we won't. We're not sure why Singularity users can see the item properly, if in fact they can.) Further, the product seems to issue @adjustheight whenever the avatar is moving - several times a second. This is a recipe for corruption.
The right answer is not to kludge around the lack as Henri did, but rather to implement a proper Z-offset mechanism in SL that propagates through the SSA bake process. This will require LL to help out. What we don't know is why Nyx did it the way he did. We suspect, but do not know for sure, that a real fix was suggested and turned down internal to LL. If that's the case, then we may not be able to convince LL to implement it properly.
Until this is fixed right, we see no reason to implement Henri's kludge. We've come up with a tiny bit less kludgy solution internally, and may implement it if nothing better is possible (involving physics layers, which aren't protected assets). Still, the right answer is to get LL to do it right.
We're especially not going to implement Henri's kludge for the sake of compatibility with one product. Sorry, Marine.
No comments:
Post a Comment