Hello, Since I cannot comment on SUN issues, may I make a suggestion here?
If adding new parameters to existing stuff belongs to allowed actions to resolve this issue, then couldn't we consider adding new parameters to poses/animations, so that they can exactly know how to adjust in order for the avatar not to sink into or float over ground? The 3 parameters of current RLV command @adjustheight more or less achieve this result. These parameters need to be adjusted on a per-animation basis and do not depend on the avatar shape (this was not possible with a single Z-offset parameter, because the needed absolute offset depends on each avatar hip/height ratio... but I am sure that Henri Beauchamp can explain this better). I believe that what I propose would be the best solution for newly created poses. For already existing ones, since the animation system allows "layering" several animations, then this would become a possibility to create poses just for adjusting the Z-offset of existing ones. Of course, it would be even better if the viewer was also still able to send bounding box update messages to the sim, as existing height adjustment systems would continue to work. 2013/3/2 Marine Kelley <marinekel...@gmail.com>: > What Henri said. Avatar height offset is a variable that currently > changes OFTEN, that's even the reason why it was added as a RLV > command, so that it could be changed automatically without annoying > the user too much. > > If this is now a shape slider, and viewer devs like me have to deal > with accordingly, this means this RLV command will trigger a shape > rebake every time it is issued, which would happen, like I said, > OFTEN. And like Lance mentioned, I'm not even sure this would work on > no-mod shapes anyway. > > I'm not saying the old parameter was ideal. In fact it was a just > acceptable solution since it didn't actually modify the altitude of > the avatar but its height, its bounding box. It would have been better > if it were an offset, and we could modify it in X, Y and Z > independently, and beyond [ -0.5, +0.5 ]. > > I'm saying that this new parameter will make it even less ideal. The > formula for calculating the correct value to send to the viewer via > the RLV command is not trivial, the extrema of this new slider are [ > -2.0, +2.0 ] if I'm not mistaken, and we will have to issue the > command in two different ways according to whether we are in a > SSB-enabled region or not. That's a lot of work and development time > for us. Perhaps it is easy for you to add a slider, but this solution > is far, far from ideal for us. > > It is currently a debug setting (which name varies from viewer to > viewer). Can't we have a solution that involves a debug setting > instead of a shape slider, so we don't have to rewrite everything ? > Please ? > > Marine > > On 02/03/2013, Henri Beauchamp <sl...@free.fr> wrote: >> On Fri, 1 Mar 2013 16:20:10 -0500, Nyx Linden wrote: >> >>> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 >>> >>> Added a new parameter to shapes to replace the viewer-side height offset. >>> Since it is stored in a wearable, the new back end can read and use the >>> value. Will send an email to third party devs later today to let them >>> know >>> to pick up the patch. >> >> ARRRGHHHH ! >> >> Adding a new parameter to the shape is NOT a suitable way to achieve >> equivalent results as what we could get so far in non-SSB sims: each >> time a new (sit, lay, kneel, crouch, crawl...) animation is played, >> you need to adjust the Z-offset: this can't obviously be achieved by >> each time changing a shape parameter, saving the new shape, and then >> asking for a (full !) rebake: the Z-offset (and more exactly the avatar >> height as requested by the viewer depending on the currently worn shape >> and the Z-offset) needs to be accounted for in real time (like what >> LLAgent::sendAgentSetAppearance() allowed to do), indenpendently of the >> other visual parameters; the shape wearable itself should be left >> untouched when the height is adjusted via the Z offset. >> >>> Marking SUN-38 as resolved. >> >> Nope, I'm sorry, but it's far from resolved !!!! >> >> Henri. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
