comments below... On Wed, Oct 20, 2010 at 12:31 PM, Melanie <mela...@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. > 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. > > 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. > 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. > 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 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). > 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. > 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. > > i'm going to move my dev onto a github repository. i'll send the link when thats done. > 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@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
