Update March 4th: The main viewer download links on the Sunshine wiki page now all reference the updated viewer version (3.4.5.271118).
Update March 2nd: Just as a point of clarification, the update discussed here is not currently linked-to from the Sunshine wiki page. To obtain a version of the viewer with the updates, you will need to download version 3.4.5.271118 of the viewer (link repeated here for ease-of-refernce).
As I recently covered, a problem has emerged with Server-side Baking in that it “breaks” the Z-offset capability found in the majority of third-party viewers.
The Z-offset allows the vertical height of an avatar above the ground to be adjusted, such that sits and kneels don’t leave the avatar apparently floating in the air, and which allow those with very tall / giant avatars or very small / petite avatars and those wearing full body mesh to similarly adjust their vertical placement relative to the ground / floor.
The problem was reported to Nyx in week 8, and SUN-38 was subsequently raised by Henri Beauchamp on February 24th to officially log the matter.
On March 1st, Linden Lab issued an update to the Server-side Baking project viewer (release 3.4.5.271118) which is an attempt to address the issue.
The new capability is referred to as SH-3909 Support avatar height offset and is described as, “Adding a new visual param that allows users to manually adjust an offset for how far off the ground (+ or -) their avatar’s root bone is.Supports the +-2m range people are used to adjusting in their viewers, but new implementation should support server-generated appearances.”
It appears within the viewer as a new slider in the Body section of the Edit Shape floater, called “Hover”.
Moving the slider to the right or increasing the displayed value will move your avatar upwards, much as increasing the Z-offset value in a TPV will. Moving the slider to the left or decreasing the displayed value will move your avatar down. As with all the shape sliders, any changes must be saved prior to exiting the editor, in order to be persistent beyond editing.
The slider offers a huge range of height adjustment compared to the z-offset slider in the likes of Firestorm, and is somewhat less accurate – with most TPV Z-offset options, height above ground can be precisely adjusted to 2 decimal points, whereas the Edit Shape floater only allows whole numbers in the range 0-99.
The vertical range of movement can be considerable, and lead to some interesting results when saved – your avatar can currently disappear entirely underground, for example. Also, adjustment made using the slider are not apparent in viewers which do not have the SSB code – something which shouldn’t be a major problem, given the need for people to be using SSB-enabled viewers once the server-side code starting deploying to the main grid anyway.
What might be of greater concern, however, is the fact that the control has been incorporated into the Edit Shape options means that it cannot be used on No Modify shapes, which could leave those using such shapes still feeling aggrieved if they are impacted by the height offset problems resulting from SSB.
It’s an interesting approach to solving the problem – and it would appear that LL consider the matter now resolved, Nyx Linden having issued an e-mail to the opensource dev list which reads in part:
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.
Marking SUN-38 as resolved.
Given that earlier in the week – at the Content Creation User Group meeting on Monday February 25th, where the subject of SUN-38 was raised, Nyx commented, “It hasn’t escaped our notice. We’re considering a couple different approaches … we’re considering a few different options. Suggestions appreciated, but we haven’t officially settled on an approach we’re going to commit to publicly just yet”, it will be interesting to see the response is to this particular fix.
With thanks to Latif Khalifa, who both provided me with news of the arrival of this update, and provided the necessary links for me to have a play.
Inara Pey: Living in a Modemworld 
Although I really don’t care about non-modifiable shapes (never used them, never will), I consider the problem far from resolved, especially considering its lack of accuracy.
LikeLike
‘resolved’? WTF
LikeLike
My reaction was similar. From “nothing decided” to “case closed”, with something which isn’t the most convenient of solutions, particularly if you swap animations sets …
LikeLike
Of course I can not comment on sun-38 …. love the new jira ‘improvements’ LL. *eyes roll*
LikeLike
Half of us participating in the recent pile-on / load test couldn’t even submit JIRA under the SUN project. We had to annotate the JIRA was for SUN then e-mail a rest for our report to be re-assigned. Fun.
LikeLike
Henri Beauchamp, who opened the SUN-38 jira about this issue, has posted a brief critique of Nyx’ solution in that jira. He doesn’t appear particularly satisfied with it.
LikeLike
I’ve just had a look – and also passed a further critique in drafting the second part of this week’s SL Project news (which I now probably won’t get out the door until Saturday; fatigue is gaining on me). My comment is that solution is hardly elegant for those who routinely swap between avatars of different heights – say a “normal” avatar and a petite; which I think is partially encapsulated in Henri’s much broader point.
LikeLike
The whole idea of the Shape data is creaking at the seams. We often need a specific Shape to wear Mesh clothing, which can be partially fixed with an Alpha Map, but the Shape data includes everything. If we want to change part of the shape, leaving such things as our face alone, we need a combination of modify-permissions on the shape we wish to use (so we can read the numbers) and a painstaking manual copying of the numbers from one Shape to the other.
And this setting is, I think, likely to come into play with footwear. The Shape settings for the feet are a clumsy tool for matching feet to shoes, especially when an Alpha map has to be applied to keep the AV-generated heels invisible. Merchants are already producing shoes with Mesh feet.
And the hang all this on the Shape, apparently because the back end can get at it. Am I crazy to see this as a sign of an un-engineered collection of hacks by yet another bunch of prima donna coders.#?
LikeLike
Leaving aside the rest of the argument…A 0-99 slider for +/- 2 meters adjustment means each step is 4 cm. Current TPV sliders allow adjustment to 2 decimal places, or 1 cm. I’m not sure that that’s all that much a loss of precision, especially given everything else that’s going on with the avatar shape.
Even so, they are constrained a bit by what they can accomplish in the short term. Adding a new wearable – and that’s what this will take, since that’s the only way to get the information to the bake engine – is probably going to be outside the scope of SSB.
Maybe the answer is to allow multiple shapes, and a second shape only modifies non-default parameters of the first one…
LikeLike
OK, consider me baffled.
The Avatar position, relative to a fixed reference point is a matter for animations. And things such as Sits routinely have adjustments, hidden in a script or even made accessible, to position different sized avatars correctly.
How do the now-broken TPV offsets work?
What else does this SSB system break? Is everyone going to be sitting in furniture, rather than on it?
I can understand why nobody might have tested these things. Why would anyone think that a process for assembling a set of textures, using the same UV map, into a single texture using that UP map, should change the shape or the position of the object the texture is to be applied to?
I just cannot see why a texture manipulation should affect avatar position.
LikeLike