persisting them doesn't really hurt. and in some cases makes things much
better even when the client can regenerate them. the current 1.23 viewers
use six packets to set visual params, setting a batch in each packet (i
should say that i see six packets for all of the avatar i have tested). the
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
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
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
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
On Wed, Oct 20, 2010 at 1:32 PM, Melanie mela...@t-data.com wrote:
Hi,
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,
