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

[Mic Bowman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20101020/25ed7d1f/attachment-0001.html>