On Mon, 2 Feb 2015 20:49:49 +0100
Henri Beauchamp <sl...@free.fr> wrote:
> Are you ***kidding*** me ????
etc...
LOL - Henri, I respect you a LOT, for technical reasons.
I even once told Oz that if you said something he better
listen because it would be worthwhile.
However,
sometimes I wonder why you aren't being smarter than this :p
At the time I was enthusiastic about working on an opensource
viewer (even though that meant given my private info, which I
agree is rather silly and annoying; and I understand why you
refuse that)... That was before Oz - we worked on the viewer
for a YEAR before finally being confronted with the fact that
Linden Lab ('s internal coders) hadn't even LOOKED at our
contributions and EVERYTHING we did had been /dev/null-ed and
not used in their next release. I didn't reconfirmation: I left.
Then Oz came and promised change: everyone would work on the
same repository and be treated the same (Lindens and open source
programmers a-like). I never believed that, but I gave him a chance:
because of his promises I ported ALL of (one year) of work
to the new code base. Then I gave them TWO MONTHS to merge my
work - which failed; and I left again and never returned.
By now (years and years later) it's a blatant fact that the
above was a lie: Lindens and open source coders are still *not*
being treated the same.
Bottom line is. Linden Lab only uses and likes "invented here".
The don't listen to others, nor are they interested in what
others have to say. Things are STILL being developed behind
closed doors mostly (and have been since the very beginning),
that will never change. If you come with a good idea, it will
be shrugged of. Trying to communicate with Linden Lab is a waste
of your time.
When the viewer developers figured this out and therefore
concentrated on COOL INNOVATIVE stuff that they didn't NEED
Linden Lab for; Linden Lab got very very frustrated, until they
finally came with the Third Party Viewer ToS that literally
forbids TPV devs to come with cool innovate stuff; so now
it's again and 100% closed-door-"invented here"-Linden-Only
stuff pushed out to some repository after which it is Oz's task
to make sure all the TPV's copy and support the new functionality
in the name of 'shared experience' etc. At no point in this
development cycle they are going to listen to you, let alone
do something (different) because of a bright insight that you
have.
Stop Wasting Your Time.
Just let them kill SL in peace.
Regards,
Carlo Wood <ca...@alinoe.com>
PS Needless to say that I completely agree with the technical point you
have been making. But it's not just the hover height that is
problematic lol. The whole animation (format) is useless. That format
was never intended to be used by many different shapes (but only by a
single shape, one that the animation is specifically intended for).
However, if you accept that design error then what is really needed
is neither a Z-offset nor a fake bounding box. What a viewer (script)
would need control over are two reals: an offset and a (vertical)
scaling factor.
The problem is this:
If an avatar of 2 meter is standing straight up, then -say- by default
their feet are on the floor (tuned to be on server side).
If the same avatar bends its knees so that the feet--pelvis distance
decreases from 1 meter (say) to 0.4 meter (say), then its feet would
be 0.6 meter above the ground because the pelvis height is fixed (well,
the avatar center is, but that has the same height basically).
Therefore, in order to get the feet on the ground again the used
animation format includes an offset of -0.6m: moving the whole avatar
down 0.6 meter. This is why this format is only usable for a single
shape: that 0.6 meter is only fixed for a given shape.
A smaller avatar, lets say one of 1.5 m (with otherwise the same shape)
has thus a feet--pelvis distance of 1.5/2 = 0.75m. This is "known" by
the server and corrected for: the pelvis is moved down 0.25m so that
the feet touch the floor when standing up.
Then, when that smaller avatar plays the same animation (made for the
2m tall one), it pulls up its feet 0.6/2*1.5 = 0.45 meter and the
animation moves the whole avatar down 0.6 meter... resulting in the
feet being buried 0.15m into the ground.
The old way to "fix" this is by telling the server: Hey, I'm REALLY
1.8 meter tall (instead of 1.5m), causing the server to not move you
down 0.25m but only 0.1m - causing the feet to precisely touch the
ground again. I don't consider that a good solution :p.
The new Hover solution is actually better - except that it was
baked into the shape itself and isn't the correct way to fix this
either - and therefore (like the first case) needs fast and dynamic
changes (ie, every time you change animation) which is no longer
possible - making it MUCH worse than what we used to have.
Still, the Hover is just an offset and therefore not what we need.
The main problem with both is that it only works for a static pose,
not for an animation where the knees are bend and stretched again,
like in certain dance animations, or in animation where someone goes
from standing up to a (ground) sitting pose for example.
In order to address those dynamic animations you need to make the
vertical offset a function of this builtin-offset (in the animation),
by allowing to provide a factor. In fact, that would work SO well
for general humanoids that you can automate it and do away with
Hover or whatever special user- or script defined variables that
depend on the animation being played completely!
Ie - ignore Hover, ignore whatever Linden Lab is working on now...
Instead make the following implementation in your viewer:
Let h = avatar (shape) height (when standing straight up).
Let x = animation defined (dynamic) vertical offset.
Let most animation be created for H = 2 meter tall avatars.
Then avatar should be drawn with an offset of not x (like
they are now), but with h / H * x.
To apply that to the above examples: when standing up x=0,
the 2m tall avatar when being it's knees would move 2/2*x=x
down, still being x thus, still moving down 0.6 meter thus.
The smaller avatar however would be drawn at 1.5/2*0.6=0.45
meter down, exactly as needed. Not that this is NOT a magic
0.15 meter offset, but a CORRECT scaling: the avatars feet
touch the ground when standing up and while bending its
knees all the way from the beginning of the animation to
the end of the animation.
_______________________________________________
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
