Hi, Mic Bowman wrote: > comments below... > 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. >
I'ḿ all for streamlining this. > 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. > > I know that, in my grid, I would never want baked textures in my asset server at all. It's fine as an option, so I have the option of preventing the storage of these textures on my systems. > 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). > > I suppose it would make ACD rather large. Maybe it's not such a good idea. >> 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. > > Having one row for each item is highly desirable, as it is easy to, for instance, programmatically detach a single attachment, or unwear a single wearable, like through a website. Storing the entire appearance in one OSD is not what we would want. The overhead of rewriting 27 rows is negligible in such a small table. > i'm going to move my dev onto a github repository. i'll send the link when > thats done. > > Great, thanks. Melanie _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
