[Opensim-dev] What I've Learned About AvatarAppearance

[Melanie]

Hi,

I pulled your branch into the core repo, where it is now available
as dev-appearance. This is based on current 0.7 in my repo and you
may wish to sync up.

Melanie

Mic Bowman wrote:
> here's the repository git://github.com/cmickeyb/opensim.git
> 
> there is still a lot of debugging to do & i need to re-enable the
> compatibility. without changes to the login server (and the robust
> appearance save) you won't see much benefit. those changes are available for
> simian in a separate patch.
> 
> --mic
> 
> 
> On Wed, Oct 20, 2010 at 1:52 PM, Mic Bowman <cmickeyb at gmail.com> wrote:
> 
>>
>>
>> On Wed, Oct 20, 2010 at 1:32 PM, Melanie <melanie at t-data.com> wrote:
>>
>>> Hi,
>>>
>>> >> The avatar appearance (avatar service) is a name-value pair storage
>>> >> anyway, so it could easily hold the UUIDs of baked textures along
>>> >> with the components of the avatar appearance. It could also hold the
>>> >> visual params, the question there is to what degree that is useful.
>>> >>
>>> >>
>>> > the encoding i have right now is one string (OSDMap) for all of the
>>> > appearance
>>> > assets. when i looked at the userdata code, i think every field/value
>>> pair
>>> > generates
>>> > a separate database update. and given that the appearance gets re-saved
>>> for
>>> > every attachment right now (that is, on login the attachments module
>>> forces
>>> > a save of the appearance once for each attachment even for attachments
>>> that
>>> > are already in the appearance data) that seemed like a lot of db writes.
>>> >
>>> > could you expand the size of the string value that can be stored to
>>> medium
>>> > string?
>>> > that would be enough size to handle the encoding i'm using.
>>> >
>>> >
>>>
>>> Having one row for each item is highly desirable, as it is easy to,
>>> for instance, programmatically detach a single attachment, or unwear
>>> a single wearable, like through a website. Storing the entire
>>> appearance in one OSD is not what we would want. The overhead of
>>> rewriting 27 rows is negligible in such a small table.
>>>
>>>
>> The way the code currently works... it uses the single encoding for
>> agentcircuitdata, clientagentdataupdate, and it uses that encoding in the
>> copyto/copyfrom methods in scene presence. I kept the IAvatarData code and
>> the get/setavatar functions so that (in theory) i wouldn't have to change
>> any of the behavior in the ROBUST AvatarService (so it can still be
>> key/value pairs passed around). I've modified the simian connectors to use
>> the full encoding (which greatly simplifies the code there). I have not
>> looked at how to provide the correct encoding for login from ROBUST. again,
>> it was a pretty simple three line code change for simian to send it because
>> thats what is being stored directly in the user data. that is, having one
>> encoding that spans the services dramatically simplified the login process
>> as well. using a separate format for the avatarservice can work... but
>> you'll have to encode it in form the login service needs.
>>
>> --mic
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev