[sldev] Concept of "loaded avatar" was changed?

[Tateru Nino]

Absolutely, Zha - I was just thinking that myself. As I've observed 
previously, a teleport seems to somehow trigger quite a bit of discard. 
That might not be what's going on, but that's how it feels.

Zha Ewry wrote:
> Note that when you cross a sim boundary, your client has already had a
> child agent in the new region for some time. (How long will depend on
> details such as your draw distance and speed approaching the crossing)
> Further, if you are crossing with another avatar, they too, have a
> child agent in the new region. I suspect this means that most of the
> material needed for your client to render the avatars will already be
> in hand in both the sim and your client as you cross. This is quite a
> bit different than the teleport case, where you both simultaneously
> establish new connections to the new sim. (Now why if you tp, and tp
> back you lose *so* much context, even cached, is another kettle of
> fish)
>
> ~ Zha
>
> On Wed, May 13, 2009 at 7:26 AM, Carlo Wood<carlo at alinoe.com>  wrote:
>    
>> On Wed, May 13, 2009 at 06:08:53AM +1000, Tateru Nino wrote:
>>      
>>> I don't recall ever seeing this problem with a companion walking or flying
>>> across a sim border.
>>>        
>> Indeed. So, whatever happens then might be the Right Way
>> to deal with this when one teleports.
>>
>> Anyway, to me it seems obvious that the only way to
>> get this really seamless is by caching the baked textures
>> of other avatars around you on the viewer, and reusing
>> them after a TP if no other data is available.
>>
>> The downside of that is that in those cases that now
>> we see a permanent cloud or grayness (because something
>> really went wrong), current we ask that person to
>> rebake their textures, but now would think we see
>> them correctly. However that is ONLY a "problem" in
>> the following case:
>>
>> - That avatar changed clothing / textures before
>>     following you; or since last meeting you.
>> - The normal update fails.
>>
>> I'd think: concentrate on the latter, which is a bug
>> to get rid of this "problem" then.
>> Another way to tackle this new problem would be to
>> add some hash (ie, in the form of three UUID's for
>> the head/upper/lower parts) to the quick avatar data
>> (that now contains their attachments; which seem
>> to load always rather quick... quickly enough for me).
>> Then my client would get those 'hash(es)' very quickly
>> after a TP (as quick as currently the AO animations
>> or attachments of the other avatar) and see that
>> the clothing didn't change and therefore without
>> any problem can start to show the cached clothing.
>>
>> Bottom line is: the viewer has to cache bake textures
>> for other avatars until that avatar is out of sight
>> too long.
>>
>> --
>> Carlo Wood<carlo at alinoe.com>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting privileges
>>
>>      
>
>    

-- 
Tateru Nino
http://www.massively.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090514/6a5f7ed1/attachment.htm