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

[Melinda Green]

Kelly wrote:
> Melinda Green wrote:
>> Tigro Spottystripes wrote:
>>   
>>> Aimee Trescothick escreveu:
>>>   
>>>     
>>>> On 12 May 2009, at 13:38, Tateru Nino wrote:
>>>>   
>>>>     
>>>>       
>>>>> You'd think so, wouldn't you? You should both have each-other's  
>>>>> textures already cached at the very least. Unless the texture IDs  
>>>>> change in a sim-crossing.... and they shouldn't do that, right? If  
>>>>> those IDs aren't changing, then it looks like there's a false  
>>>>> discard going on.
>>>>>     
>>>>>       
>>>>>         
>>>> As far as I know, baked textures are only held as temporary textures  
>>>> on the sim, so they won't be available in the new region after a  
>>>> teleport until the client uploads them on arrival.
>>>>
>>>> However, if your client has baked textures cached for another avatar  
>>>> from the previous region ideally it should continue using those until  
>>>> it is able to obtain fresh ones from the new region, rather than  
>>>> clouding the avatar. That would give a more seamless experience than  
>>>> what appears to happen now.
>>>>
>>>> The only minor "issue" I can see with that at first inspection, is if  
>>>> the other person changes clothes before following you, in which case  
>>>> their  appearance to you would be out of date until their new baked  
>>>> textures are available.
>>>>
>>>> Aimee.
>>>>
>>>>
>>>>   
>>>>     
>>>>       
>>> Shouldn't the servers share this info between them?
>>>     
>>
>> I think it would be overkill to make sims share baked textures 
>> peer-to-peer, however there seems to me to be a simpler way to share 
>> baked textures which is to turn them into ordinary assets. Each avatar 
>> would only have a small, finite number of these so I wouldn't expect 
>> them put too much of a burden on the servers. I could even imagine good 
>> reasons to make baked textures part of the agent data, but in the 
>> short-run I wonder whether the simple solution would be to make baked 
>> textures into ordinary assets.
>>
>> -Melinda
> Hey all!  There are some misconceptions here about how this works on 
> the back end, maybe I can clear it up.  The following is the theory, 
> apologies is reality doesn't quite match up.
>
> * When an avatar changes their outfit they bake their textures (akin 
> to flattening layers in photoshop).
> * They then upload those textures to the simulator which stores the 
> textures on an internally accessible web-dav server on the simulator host.
> * The simulator also stores information about where your baked 
> textures are, in memory.  In theory this should be a full URL but I 
> think it is a host and a UUID instead.
> * The information about what host has your baked textures travels with 
> you when you teleport or cross a region border, but the textures do not.
> * The textures should not need to get rebaked when you TP or region cross.
>
> Texture access (pre http-textures I think) is a funny thing.  The 
> client always gets textures from the simulator which usually gets them 
> from the asset server and keeps them in a local cache.  If it is a 
> baked texture though the simulator fetches from the other simulator 
> instead of the asset server, where "other server" is based on info in 
> memory tied to the agent.  If for any reason the simulator can't get 
> the baked texture then it tells the agent's client to rebake.
>
> I believe most issues center around race conditions and the "couldn't 
> find it, force a rebake and reupload" behavior.
>
> Baked textures used to be regular assets.  Honestly we had a lot fewer 
> issues with them then.  However storing programatically generated 
> textures in our central asset system caused too many assets to be 
> created.  The 'temporary asset' system was created specifically for 
> this reason and specifically for baked textures.  It is not something 
> we are able to revert.  That said I think the http-textures project 
> may open up some great opportunities to improve this system.  If we 
> can refer to textures by url we can remove a lot of the more fragile 
> pieces of this code path, and make 'temporary' textures more normal 
> and more robust.

Kelly,

Thank you for the additional background and technical details. It does 
sound as if a URL-based system should work well for many temporary 
textures. It may also be a good short-term solution for handling baked 
textures but I suspect it's not the best long-term solution. That's 
because I'm beginning to realize that baked textures are conceptually 
very different from other temporary textures. Even though they change 
often, they're also far more precious. My baked textures are almost as 
important to my presentation as my displayed name which is why I'm 
starting to think of them as part of my agent data. I would like to have 
more direct control of the baked textures that I use to present myself 
to the world, even possibly to the point of being able to edit them in 
Photoshop and uploading to SL. I'm not saying that I want to do that 
today but I'm saying that I think it will be important to stop thinking 
of these as ordinary temporary textures.

-Melinda