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