[sldev] Re: [ARCH] Render unto Caesar...

Mike Monkowski monkowsk at watson.ibm.com
Tue Sep 18 16:15:46 PDT 2007


Tao Takashi wrote:
> I wanted to suggest to step a little back and see at the thing we want 
> to implement.
> I think the main distinction Linden Lab does here is the agent and 
> region domain.
> Mainly two black boxes to each other. Does it matter then where that 
> avatar host is
> and if one is needed at all?
> Do I understand it right that your (Mike) suggestion is to have a 
> separate box handle
> avatars?

Yes, that was the suggestion.

> If it's part of the region domain then the main question is whether it 
> affects
> any possible interface or not.

It affects the information flow and the computational load.

> I also think the agent hosts were merely thought as some interface to a 
> session object which can
> - take and give out inventory
> - handle profile and status updates
> and so on but not for having anything to do with rendering or simulating 
> the actual virtual world.

Yes, I misunderstood before, but I now I understand.

> As for the population limit we maybe need some input from Linden Lab 
> what the bottleneck here is.
> We once discussed it in an Zero office hour and the main thing there was 
> some database bottleneck

Yes, the central database is very inefficient.  If avatar information 
were distributed in Agent Stores and region information in Region Stores 
as the new architecture proposes, then database access would be 
distributed.  No bottlenecks.

> "There's some neat tech coming out, like "avatar imposters" to improve 
> your framerate in big crowds by using less resources to draw 
> further-away avatars. That means they will walk kind of jerkily and look 
> like old-skool video game sprites, but the performance tradeoff may be 
> very well worth it. This, of course, will be an OPTION so if you have a 
> beefy rig and want to turn those imposters off, that's your prerogative."
> 
> But I wonder if that really is something the architecture can change. Of 
> course we should keep
> connections and possibly data streams to as minimal (or adjustable) as 
> possible.

Well, it's not something the architecture can change, but it should be 
taken into account when estimating communications loads.  The key issue 
of all the new architecture is scaling.

Mike


More information about the SLDev mailing list