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

[Dahlia Trimble]

Persisting visual params makes sense for those types of clients which dont
generate them, such as some libomv bots. Typically these clients rely on
params generated from prior logins with a normal viewer.



On Wed, Oct 20, 2010 at 12:31 PM, Melanie <melanie at t-data.com> wrote:

> Hi Mic,
>
> that all sounds great.
>
> To address your questions:
>
> Persisting visual params doesn't appear to make sense, as far as I
> know they are regenerated on each login anyway, and they are < 256
> bytes. Not really a load factor to worry about.
>
> Persisting baked textures would require them to be uploaded to the
> asset server, which would cause unacceptable asset bloat. While I
> can see where there are scenarios where that is an advantage, for a
> normal social grid this is an unacceptable volume. It needs to be
> optional, and not on by default.
> However, encoding the actual baked textures into AgentCircuitData
> could improve performance, as it would no longer be required to
> re-upload them in each sim one crosses or teleports into.
> 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.
>
> Compatibility is not really an issue. For something as tremendously
> beneficial as this could become, we can easily bump the interface
> version.
>
> As for testing, we can either branch it on opensimulator.org, and
> then work with the branch, or you can branch in your repo and we
> pull from it and then debug and fix it in opensimulator.org.
>
> Melanie
>
> Mic Bowman wrote:
> > just to set some context... we started looking at appearance because the
> > cost of logins was very high and grows quadratically (it takes 3+ hours
> to
> > start up our 1000 avatar demonstration).
> >
> >
> > the current version of opensim does not persist either baked avatar
> textures
> > or visual parameters. as a result, when an avatar logs in, the login
> service
> > sends to the simulator a packet that includes wearables and attachments.
> as
> > part of the login process the incomplete appearance is sent to the client
> > and the client "fixes" it. the "fixing" process involves multiple packets
> > being sent by the viewer to the simulator to set various visual
> parameters,
> > uploading multiple baked textures (in my case i see 6 textures uploaded
> on
> > the typical login), then a final setappearance packet to assign the baked
> > textures to the avatar's appearance.
> >
> >
> > each one of these updates causes the current state of the avatar's
> > appearance to be sent to every connected client. and, since currently
> baked
> > textures are not persisted, baked textures must be uploaded/downloaded on
> > every login. so 10 clients logging in simultaneously means that the
> > simulator is sending appearance 10x10xN times where N is the number of
> > packets it takes for one avatar to establish its appearance (N == 8 for
> my
> > avatar).  with 1000 clients logging in... the numbers are in the
> millions...
> >
> >
> > to get around this problem we set out to persist visual parameters and
> baked
> > textures. there is no easy fix....
> >
> >
> > to summarize what we are testing (see below for question about how to get
> it
> > published... too big for a simple patch)...
> >
> >
> >
> > we moved all packing/unpacking of appearance into AvatarAppearance. this
> > works really well except that the four places where the appearance was
> > packed before (all four using slightly different encodings) now break
> > backward compatibility unless we leave all the old code in place (which
> sort
> > of defeats the purpose). I’m not sure what to do about backward
> > compatibility, more on that in a minute.
> >
> >
> >
> > the packing includes baked textures and visual params. the net effect of
> > that is that if you appearance hasn’t changed, there are no baked
> textures
> > uploaded and no visual params set on login. that cuts out 6-ish baked
> > texture uploads and multiple (4-6 depending on the avatar) updates of the
> > visual params.
> >
> >
> >
> > we added [Set|Get]Appearance calls to IAvatarService but left in the
> Set/Get
> > avatar calls which pass avatar data. The Robust implementation of
> > Set|GetAppearance just calls the Set|GetAvatar operations. That should
> > encode the data in the same way it was encoded before (the Appearance
> > encoding/decoding in AvatarData remains) with no baked textures or visual
> > parameters saved. And all values that will be stored in the user database
> > should continue to be short-ish (no change, in theory) to fit into the
> > current 256 character size limit on userdata.
> >
> >
> > we cleaned out a bunch of unused code from avatarfactory and moved
> several
> > of the appearance handling routines from scenepresence into that module.
> at
> > some point... appearance updates should be held briefly to accumulate
> > changes rather than sending out the changes on every appearance update
> > packet.
> >
> >
> > compatibility issues…
> >
> > first… appearance is encoded|decoded in ScenePresence (CopyTo() and
> > CopyFrom() routines, AgentCircuitData, ChildAgentDataUpdate, and
> AvatarData.
> > Each one uses a slightly different method for encoding/decoding the
> > appearance data (and they do not all encode the same subset of appearance
> > data). If backward compatibility were not an issue… AvatarData could go
> away
> > completely and all three of the others could use just the new packing
> > routines (that’s basically what I’ve been testing). I’ve already modified
> > the login script for simian to send the right data. If the data were
> being
> > passed to the Robust avatar service in the same way, I could modify that
> to
> > use the new data as well. However… unless we drop backward compatibility
> > with older regions, all the old encode|decode code needs to stay in the
> > codebase & be checked on every access. i'm open to suggestions for the
> best
> > way to handle this... there is value in having a flag day and just
> switching
> > to the new encoding, but it seems more reasonable to preserve the old
> code
> > for awhile so long as we deprecate it at some point...
> >
> > final issue...
> >
> >
> > this is a big refactor/rewrite. and it needs to be tested on a variety of
> > platforms. and i need help updating the avatarservice & loginservice in
> the
> > robust code (no set up to test that). what's the best way for a non-core
> > developer to create a public branch that others can test before it gets
> > merged...
> >
> >
> >
> > --mic
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20101021/75ee9bd5/attachment-0001.html>