[sldev] [ARCH] Render unto Caesar the things that are Caesar's

Nik Radford nik at terminaldischarge.net
Tue Sep 18 14:35:53 PDT 2007


----- Original Message ----- 
From: "Mike Monkowski" <monkowsk at watson.ibm.com>
To: "Jason Giglio" <gigstaggart at gmail.com>
Cc: <sldev at lists.secondlife.com>
Sent: Tuesday, September 18, 2007 10:04 PM
Subject: Re: [sldev] [ARCH] Render unto Caesar the things that are Caesar's


> Jason Giglio wrote:
>> Mike Monkowski wrote:
>>  > If you know the reasons, it would be good to list them, because I 
>> think
>>  > this is one of the limitations that should be eliminated.
>>
>> Sure.  Scene polygon count, script load, physics load, and network load.
>
> For the scene polygon count, I assume you mean the added polygons for the 
> avatars.  This could be handled with lower LOD for more distant avatars.
>
I assumed scene polygon count is all polygons on the region, The polygons 
for the avatar, polygons for all objects and prims, etc etc.

> Script load and physics load (except for collision detection) shouldn't 
> depend on the number of avatars, just the number of objects.
>
Well, physics does depend on avatars too, for collisions against avatars.
Scripts is just load depending on the amount of scripts running on the sim

> By network load do you mean sim-to-sim or viewer-to-sim?  If the latter, 
> then it would mean in the new architecture we shouldn't have communication 
> directly with the Region Hosts if we want to allow more avatars per sim. 
> Yes?
I would of thought the network load is quite high all round, with 
communicating with adjacent sims as well as all
viewers, but yes perhaps a suitable archiecture would be to have one sim, 
and then relay servers a bit like shoutcast does with relay servers? to 
lessen the load, of course the communication between relay and sim (Region 
host, sorry) would be two way to update information on the sim (created 
objects, object updates from clients, avatar positions etc) But would that 
actually help? (sorry I'm just jibbering on randomly)

>
> Mike
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html


Nik 



More information about the SLDev mailing list