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

[Mike Monkowski]

I've read the transcript and looked at the slides of teh Architecture 
group, and I'd like to suggest an alternate partioning of the tasks.

I'm not sure what the Hosts are in the diagrams, but my interpretation 
is that they are temporary instances, "virtual" virtual worlds.  The 
information about an avatar is kept in the Stores, and when that avatar 
logs on, an instance of the avatar is created on an Avatar Host.  The 
information about a region is kept in the Stores, and when someone 
visits it, an instance is created on a Region Host.

It's not clear from the charts exactly what is in an Avatar Host, so let 
me suggest that first it should contain an instance of the avatar mesh. 
  We don't want to live with just two meshes forever, and we don't want 
to have to store a universe of avatar meshes locally with the viewer. 
Second, it should contain instances of all of the avatar's attachments, 
including their positions relative to the avatar.  And third, it should 
contain any objects temporarily rezzed by the avatar from his/her inventory.

An avatar's inventory and all processing of the inventory would be 
handled by the Avatar Stores.

A region host would contain instances of all objects owned by the 
region, but the ownership would be handled by the Region Stores.

The diagrams don't consider multiple viewers attached to a Region Host, 
but let's consider how viewers get information about other avatars.  In 
the current SL architecture, all the information about all of the 
avatars is on the sim (region host) and all connections are through the 
sim.  When an avatar moves across regions, his information is handed off 
from sim to sim.  And because of this, we are limited to about a hundred 
avatars per sim.

So the new architecture has Avatar Hosts to keep track of the avatar 
information, and viewers get information from the Avatar Hosts.  So if 
my avatar is in the Region and your avatar is in the Region, we both get 
information from the Region Host and we share information from our 
respective Avatar Hosts.  And if we would like to be able to see across 
regions, we need to contact all of those other Avatar Hosts.  That's a 
lot of very dispersed connections.

Which brings me to my alternate partitioning of the tasks:  The Avatar 
Hosts should be in the same domain as the Region Hosts.

Getting information from the Avatar Stores to the Avatar Hosts doesn't 
have to be fast, but getting information from the Avatar Host to the 
Region Host should be fast.

The Avatar Host would serve the appropriate LOD instances to the Region 
Hosts that need them.  For highest LOD, they could communicate directly 
with the viewers.  For lower LOD, the viewers could get the information 
through the Region Host.  Region Hosts really only need to know enough 
about an avatar geometry to compute collisions.  The rest of the physics 
could be done by the Avatar Hosts.

The goal is to keep the amount of avatar information on the Region Host 
to a minimum so that we can dynamically repartition the virtual Region 
on servers as the load demands.  A server could be running several 
Regions if they aren't doing much, or it could be running just a 
fraction of a Region if there are a lot of avatars doing a lot of 
things.  Eliminate the population limit.  "All the avatars that fits."

For looking across regions, the avatars already have multiple LODs.  For 
prims and object meshes (yes, we don't want to limit ourselves to prims) 
the Region Host could automatically generate low LOD meshes to represent 
the objects at a distance and pass them on to neighboring Regions.

The viewer, also, could choose to use lower LODs for avatars and objects 
to improve performance.  Kind of like progressive loading of images on 
the web.

So if we allow thousands of avatars on a sim, how will they all be able 
to see the performer on stage?  Well, since the Region Hosts are just 
instances, we can make multiple instances of the Region in the world 
that can only be entered by way of the instance that the performers are 
viewing at the time.  For other instances, it would look like avatars 
appear and disappear at the region boundaries like a walking teleport.

So you could have very large intimate gatherings and everybody gets a 
good seat.

Right now we have huge central Stores, but we really know that objects 
belong either to an avatar or a region, so the Stores can be very small 
and very distributed with connectivity only to the relevant Avatar Hosts 
and Region Hosts.  Transactions with the Stores would be through the 
Stores servers.  There would be no "push" transactions to the Stores, 
they would all be "pull" transactions by those who are authenticated to 
the Stores servers.  So the Stores could even be simple Apache web 
servers.  The Stores could "push" to the Hosts or the Hosts could "pull" 
but nothing is permanent on the Hosts.

So, in summary, if you din't get the clever biblical allusion of the 
title, the main idea is to keep all the information for rendering 
avatars on Avatar Hosts and for rendering Regions on Region Hosts, but 
keep both in the same domain.

Mike