Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2022-01-21 19:31:06



Reply to topic  [ 10 posts ] 
Avatar "Z offset" support 
Author Message

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
Some (many ?) of you may be aware that there has been a long standing (almost 2 years old now) issue with SSB (server side baking) and the breakage of a TPV feature that existed for years before SSB was introduced: the avatar height (size) offset, called (alas wrongly, see why below) "avatar Z offset" by its first implementer (IIRC, it was first implemented in Emerald, or was it Dale Glass' viewer ?...).

I created a JIRA issue, SUN-38 as soon as I noticed the problem (and SUN-38 also addresses the Y and X offsets, i.e. the avatar bounding box as a whole, which is still an issue for tiny and giant avatars).

The proper fix for that problem was trivial: it would have involved mimicking what was done before by non-SSB sims and I bet that, given the server sources, I could have implemented that fix in a single work day, for it was just a matter of adding a delta (offset) parameter to the avatar height (but also width and depth, as described in SUN-38, and which are still not addressed) as calculated by the SSB "ovens" before feeding the result to the physics engine, and allowing viewers to change that delta parameter in real time via a new capability (it was formerly changed via the viewer-to-server AgentSetAppearance UDP message, which is not used any more by the SSB protocol).

Instead, LL disregarded that issue as too minor for them to care and delay the SSB release, and it was only the good will of one single Linden (Nyx) which brought us a temporary (but alas inadequate) work-around, via the new Hover visual parameter in shapes (inadequate because not modifiable in "real time" since it involved changing the shape parameter, saving the shape and rebaking each time the offset was changed, which in turn could not be performed on a no-mod shape...).

A few months ago, the Firestorm team came up with a specification proposal, which, instead of using my own (trivial and fully backward compatible) proposed solution, involved using an extended messaging scheme that would break the "shared experience" for viewers not supporting it (i.e. in older viewers, the avatars won't render at the same altitude as in viewers with support for that extended message). I warned everyone (see the comment I posted in SUN-38 on 22/Jun/14 10:58 AM), but apparently, either the Lindens didn't read it, or they shrugged it off...

Today, the solution (and, let's repeat it again, still partial a solution: the avatar bounding box issue for tiny/giant avatars is still not addressed) to SUN-38 as issued by LL came as the "Avatar Hover Height" feature (AHH for short), which is for now implemented in the sl-92 viewer branch (and backported in today's Cool VL Viewer releases). Alas, that solution involves the extended UDP message as suggested by the Firestorm team, meaning the "shared experience" is broken and will remain so until all residents update their viewer to one supporting the AHH feature (which could take months or even never happen, given the outdated viewers used by some)...

Also, the "Avatar Z Offset" was not implemented as an avatar size delta (like it initially was in non-SSB sims and next in Nyx' Hover shape visual parameter), but as an altitude offset which is added to the avatar's position in the viewer to the position sent by the server (that's why the "Avatar Z Offset" was a bad choice of name: it confused the Lindens, apparently...). This means that, for now, the @adjustheight RLV command (used by RLV-aware scripted items to auto-correct the animations Z offset to match your avatar's actual size) would need different parameters than it used to because, instead of correcting the avatar size, it would now need to correct its altitude, and no, it's not the same thing, because the altitude depends on the pelvis to foot length, which in turn can vary based on the shape/shoes and the animation being played (kneeling, standing, laying, sitting on ground, etc...).
I will have a look and see if I can find a formula to auto-correct internally the Z-offset value that is sent by @adjustheight so to restore the compatibility with existing RLV items, but a better solution would be for Lindens to read this message and change their mind on how AHH must be implemented in the end... Yes, I'm dreaming...
EDIT: I found a solution for @adjustheight, see below.

So, for now, AHH is taken into account by the Cool VL Viewer (i.e. you will see avatars using AHH for themselves rendered at the proper height), but the feature is disabled by default for your avatar, which will instead keep using the Hover shape parameter (for mod-ok shapes only, of course); you can nonetheless enable AHH for your avatar via "Advanced" -> "Character" -> "Use Avatar Hover Height" (*), but then @adjustheight will not work properly (the Z correction will be about twice too large, but even that factor depends on the played animation...) (EDIT: problem solved, see below). Also, be aware that the only sim servers allowing to use AHH in the main grid are for now the RC channels servers (Le Tigre, Magnum, Bluesteel). (EDIT: now available grid-wide).

(*) Before switching that feature on or off, make sure the current "Z offset" is at 0.00 because the viewer does not reset an offset (Hover or AHH) before switching to the other.


2015-01-31 12:35:22
Profile WWW

Joined: 2012-02-09 21:01:50
Posts: 284
Reply with quote
Why do the Lindens so often just make the false decision if they already got a proper working solution proposal? :cry:

Thanks for detailing it for us. :)


2015-01-31 18:07:54
Profile

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
And, again, the very same arrogance and lies from LL... I'm pissed off today, big time. So, here is what I replied to them:
Quote:
Date: Mon, 2 Feb 2015 20:49:49 +0100
From: Henri Beauchamp <sldev(at)free.fr>
To: "Oz Linden (Scott Lawrence)" <oz(at)lindenlab.com>
Cc: opensource-dev(at)lists.secondlife.com
Sender: opensource-dev-bounces(at)lists.secondlife.com
Subject: Re: [opensource-dev] Avatar Hover Height feature

On Mon, 02 Feb 2015 13:05:20 -0500, Oz Linden (Scott Lawrence) wrote:

> On 2015-01-31 07:53 , Henri Beauchamp wrote:
> > Greetings,
> >
> > I know this should be posted in the JIRA, but apparently the comments in
> > the existing issue (SUN-38) are not read or not taken into account by
> > Lindens.
> >
> > Please, to any and all Linden(s) involved in AHH, do read this post for
> > your own enlightement (and hopefully, a better and definitive solution
> > for the SL community as a whole):
> > viewtopic.php?f=5&t=1494&p=6890#p6890
> >
> > Note that I'm beyond the point to care about whether this message will
> > be taken into account or not (so it's perfectly useless to enter a
> > sterile argument on this list about it). It's more like a bottled
> > message I throw into the sea...
>
> I won't speculate on whether or not we would have decided to do it
> differently had your suggestion actually been made when we were starting
> work on this months ago; the factors affecting avatar height and avatar
> vertical offset are quite complicated and it may or may not have been
> the right thing to do. I will say that your input would certainly have
> been considered had you been a part of the conversation at the time
> rather than posting a note on our private forum well after the fact.

Are you ***kidding*** me ????

I have been attending quite a few Server group meetings with Nyx, and
you even were there once (for sure) or twice (can't swear on it), when
I spoke about the SUN-38 issue.
You will find several agendas with my entry about SUN-38, in the Wiki:
http://wiki.secondlife.com/w/index.php? ... ext=Search
Most of the corresponding transcripts are alas missing from the Wiki,
but I *did* explain my solution in at least two of those meetings
and I will point out one particular agenda, where I asked if SPEAKING
with a Linden about SUN-38 and the possible solutions would be at all
possible:
http://wiki.secondlife.com/wiki/Mesh/Archive/2013-04-29

It's not my fault if you keep shrugging off every remark or proposal
I make, or even refuse the dialog (in plain text, because I cannot
articulate well enough English neither understand English spoken
with the US American accent in real time).
I will not even bother quoting the various emails I sent to
*YOU*, Oz, and that you never replied (albeit about other subjects
than SUN-38), but if you want them, I could dig in my backups...

> Despite the fact that you refuse to contribute your code,

Again you are reverting the roles here !!!!

I never refused to contribute my code: it's GPL and always said
that anyone (and yes, that includes *you* Lindens) could reuse it.
Also, each time someone asked for permissionto make my code LGPL
to be compatible with their own viewer, I always said "go for it !".

What I refuse, however, is to sign a contribution agreement where
I would have to give private data to perfect strangers residing
in a foreign country that doesn't respect the privacy protection
Law of *my* country (or of any other country for that purpose).
You perfectly know this, for I explained it to you (and to Soft
Linden, your predecessor) countless times in emails, even going
down to give you pointers to paragraphs in the (English-
translated even !) French Law "Informatique et Liberté".

I am not the one refusing to contribute my code, YOU are the one(s)
refusing to use my contributions because of stupid and pointless
lawyer-induced bureaucracy. It is *YOUR* choice and *YOUR* refusal,
not mine !!!

> I'm happy to make sure that your input is considered if and when
> you provide it in a timely way;

I am the very initiator of the SUN-38 issue, and if you re-read the
comments I made in it, my solution is exposed here as well (see
the comment posted on 22/Jun/14 10:58 AM, in reply to the Firestorm
team's proposal, i.e. QUITE in the TIMELY manner !!!).

I ALWAYS gave pointers to major flaws and regressions, either in the
form of a JIRA issue, or directly via emails (to YOU !!!). So,
accusing me of not providing the info or not in a timely manner is
quite INSULTING and a pure LIE from your part.

> I hope that in the future you'll chose to engage more productively.

I hope that in the future, you will actually read the JIRAs I initiate,
the emails I send to you, the messages I post on the various boards and
blogs you DO frequent as well as I do (Nalate's blog, to cite just one).
I also hope that you will make the minimum effort to communicate in a
way that a non-English speaking person such as myself can actually
manage (Open Source meetings used to happen in CHAT and not in voice,
when Soft Linden was still there... and I DID tell you in one of your
first meetings that people like me COULDN'T attend your meetings because
of the language barrier: I can find the log, if you wish...).

Now, I would *much* more prefer a clever and fruitful collaboration
to this sterile childish behaviour (ignoring me, then putting the
fault on me for not participating. I think that in 8+ years of SLing,
I *never stopped* participating !).

A *pissed* off (BIG TIME !)...

Henri.


2015-02-02 19:56:39
Profile WWW

Joined: 2011-09-17 11:12:19
Posts: 328
Reply with quote
Incredible, that's like the most arrogant answer I ever saw, I can't belive they would do this.

I gave up on the jira long ago when the lindens stopped participating it actively, I can't say if its changed or not though, plus all the Lindens I knew, left or got sacked, so my involvement in the development is rather limited. The email communication from Oz just confirms my decision.


2015-02-03 17:38:42
Profile

Joined: 2010-08-21 12:30:36
Posts: 89
Reply with quote
To tell you the truth, I don't think it had anything to do with not knowing any better way to do it. I think it has more to do with injecting yet another feature, albeit forwarded to them by the Firestorm 'team' who also have a similar agenda, in order to make users of older viewers feel less comfortable using them, making them seem 'broken' to the user, in an effort to get them to use newer viewers, so they no longer have to support them and can cut back on their support staff. Always follow the money.


2015-02-06 04:16:45
Profile

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
Lord wrote:
To tell you the truth, I don't think it had anything to do with not knowing any better way to do it. I think it has more to do with injecting yet another feature, albeit forwarded to them by the Firestorm 'team' who also have a similar agenda, in order to make users of older viewers feel less comfortable using them, making them seem 'broken' to the user, in an effort to get them to use newer viewers, so they no longer have to support them and can cut back on their support staff. Always follow the money.
I doubt very much this could have anything to do with LL's "decision" (or lack thereof, instead blindly implementing a badly thought out proposal from their fan boys and girls).

For a start, both LL's viewer and Firestorm got a deprecating "feature" implemented (i.e. they can blacklist from the grid old versions of their viewers).

It is nonetheless indeed quite ironic that LL folks, who made out the rule 2.k in the TPV policy (i.e. the "no shared experience breakage" rule), is breaking their own rule when they had a backward-compatible method proposed to them as an alternative...


2015-02-06 13:09:52
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
For today's releases (v1.26.8.88 and v1.26.12.30), I found a way to restore the compatibility between AHH and @adjustheight: for the techies (or TPV developers) among you, the trick consists in only keeping track (as usual) of the avatar height (Z size) delta in the viewer, and sending to the AHH-enabled sim servers that delta divided by a factor which is equal to the avatar shape total height divided by its pelvis to feet height (both being kept up to date already by the viewer code).

There's however still the issues I described in my first message in this thread, namely the lack of a way to adjust the avatar bounding box (like it was possible in non-SSB sims) and, worst, the "shared experience" breakage (which will take ages to solve, since it relies on all residents updating to AHH-enabled viewers). Because of the latter reason, the AHH feature is still disabled for your avatar by default (toggle in Advanced -> Character menu).


2015-02-07 10:43:29
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
Since releases 1.26.8.90, 1.26.12.34 and 1.26.3.2, when wearing a no-mod shape in a SSB-enabled sim (i.e. in SL) and the sim supports AHH, AHH is used to set your avatar's Z-offset regardless of UseAvatarHoverHeight being set to FALSE (since in that specific case we can't use the shape Hover visual parameter anyway...).


2015-03-28 08:18:19
Profile WWW

Joined: 2012-06-29 15:57:50
Posts: 10
Reply with quote
This might be a silly question, but could the technology used to adjust the hover height slider of a shape be used to retrieve and edit other shape sliders via RLV command of a body? Could open up some interesting options if this was possible.


2015-03-30 04:20:07
Profile

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
ibigfire wrote:
This might be a silly question, but could the technology used to adjust the hover height slider of a shape be used to retrieve and edit other shape sliders via RLV command of a body? Could open up some interesting options if this was possible.
Yes, but I doubt very much people want their avatar shape modified by some random RestrainedLove script, loosing the parameters of their original shape in the process and perhaps finding themselves unable to restore their shape... So, I won't implement such a (dangerous) feature. You can already "modify" a shape with RestrainedLove, by simply force-wearing a new shape on the avatar (and the original shape stays safe and untouched).


2015-03-30 07:34:48
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 10 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.