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 :
> 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 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.
>>
>> ARRRG !
>>
>> 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
