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

[Melanie]

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