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

[Melanie]

Hi,

Mic Bowman wrote:
> comments below...
> like i said... right now, the impact of the visual parameters is
> disproportionately high.
> the viewer takes multiple calls to setappearance setting a block of params
> with each
> call. the current code forwards each one of these updates out to all
> clients.
> 
> what i've seen is that when i get the right set of vparams sent to the
> viewer on the initial
> send of the avatar data (there is a sendappearance() call that needed to be
> added to
> sendinitialdata i think) then you avoid the updates completely.
> 
> the other way to get around the mass updates caused by establishing the
> visual
> params is to hold off on sending any appearance updates out to other
> clients. that
> would be good anyway.
> 

I'ḿ all for streamlining this.

> all the assets generated as baked textures are marked temporary. i know
> we have a cleaner that removes temp assets from the database periodically.
> it doesn't really create much load and very easy to clean up. we are
> experimenting
> with other geographical caches that help as well.
> 
> that being said... i was planning to make it a configurable option (just
> sets
> the value of "local" field in caps.cs where the baked texture is uploaded.
> 
> 

I know that, in my grid, I would never want baked textures in my
asset server at all. It's fine as an option, so I have the option of
preventing the storage of these textures on my systems.

> the could be.. but the setup costs caused by ACD are high already. the real
> point here
> is to re-use that already cached appearance assets (cached in the viewers
> of the avatars already in a region). rebaking or moving the assets from
> simulator to simulator doesn't really help much with that. its the same
> bandwidth whether the client uploads the textures (they don't get
> rebaked just re-uploaded)  or whether they come through agentcircuitdata.
> and what we're trying to do is to take advantage of them already being
> in the cache (so passing them through agentcircuitdata will hopefully
> be a waste of time in most cases).
> 
> 
I suppose it would make ACD rather large. Maybe it's not such a good
idea.

>> 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.

> i'm going to move my dev onto a github repository. i'll send the link when
> thats done.
> 
> 

Great, thanks.

Melanie