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 <[email protected]> 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 > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
