[sldev] Concept of "loaded avatar" was changed?
Kelly
kelly at lindenlab.com
Tue May 12 13:25:23 PDT 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090512/2c23348c/attachment-0001.htm
More information about the SLDev
mailing list