comments below...<br><br><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 class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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></blockquote><div><br>like i said... right now, the impact of the visual parameters is disproportionately high. <br>the viewer takes multiple calls to setappearance setting a block of params with each<br>
call. the current code forwards each one of these updates out to all clients.<br><br>what i've seen is that when i get the right set of vparams sent to the viewer on the initial <br>send of the avatar data (there is a sendappearance() call that needed to be added to <br>
sendinitialdata i think) then you avoid the updates completely.<br><br>the other way to get around the mass updates caused by establishing the visual<br>params is to hold off on sending any appearance updates out to other clients. that<br>
would be good anyway.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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></blockquote><div><br>all the assets generated as baked textures are marked temporary. i know<br>we have a cleaner that removes temp assets from the database periodically.<br>it doesn't really create much load and very easy to clean up. we are experimenting<br>
with other geographical caches that help as well.<br><br>that being said... i was planning to make it a configurable option (just sets<br>the value of "local" field in caps.cs where the baked texture is uploaded.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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></blockquote><div><br>the could be.. but the setup costs caused by ACD are high already. the real point here<br>is to re-use that already cached appearance assets (cached in the viewers<br>
of the avatars already in a region). rebaking or moving the assets from<br>simulator to simulator doesn't really help much with that. its the same<br>bandwidth whether the client uploads the textures (they don't get <br>
rebaked just re-uploaded)  or whether they come through agentcircuitdata.<br>and what we're trying to do is to take advantage of them already being<br>in the cache (so passing them through agentcircuitdata will hopefully <br>
be a waste of time in most cases).<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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></blockquote><div><br>the encoding i have right now is one string (OSDMap) for all of the appearance<br>assets. when i looked at the userdata code, i think every field/value pair generates<br>a separate database update. and given that the appearance gets re-saved for <br>
every attachment right now (that is, on login the attachments module forces <br>a save of the appearance once for each attachment even for attachments that<br>are already in the appearance data) that seemed like a lot of db writes.<br>
<br>could you expand the size of the string value that can be stored to medium string?<br>that would be enough size to handle the encoding i'm using.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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></blockquote><div><br>i'm going to move my dev onto a github repository. i'll send the link when thats done.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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>