A viewer is like a web browser for a 3D world. It's like a game client, but it doesn't have any game logic or content. As with a web browser, all content is downloaded from the servers. Firestorm is a third-party viewer with a sizable development organization. See "firestormviewer.org".
Quick overview:
Second Life / Open Simulator worlds are divided into "regions". Each region is 256m on a side on Second Life, and can be other sizes in Open Simulator. The world is about the size of Los Angeles. The viewer starts out by talking to a login server for a grid, which authorizes it to connect to a region. The viewer then talks to the region. There are short messages over UDP, and some bigger stuff over HTTPS.
Once a viewer is talking to a region, it asks the region server about adjacent regions. The viewer can then talk to a few adjacent regions, too, showing the user a big, seamless world. As the user moves around the world, connections are made to new regions, and connections to regions out of range are dropped. This is how the world scales. There are about 27,500 live regions today, each with its own simulator program, always on even if nobody is using it. Each simulator program takes about one CPU and under 4GB on a server. Second Life is currently hosted on AWS, with dedicated servers. This scales well; the world could be scaled up substantially if there was demand.
The always on feature runs up costs, but the business model is that users rent land. So costs and revenue stay in balance. Regions really are always on - trains run through regions where no one is around, for example. This architecture made more sense when Second Life had their own servers in a co-location facility.
The region servers talk to their direct neighbors. This allows movement across region boundaries. If a region goes down or is restarted, the viewer will show a water-filled hole with steep sides where the region is supposed to be. So the overall system is fault-tolerant.
Content is stored on asset servers, separate from the region servers. These are ordinary AWS web servers, front-ended by Akamai caches. Content includes textures (images in JPEG 2000 format, which is a pain to decompress fast), meshes (a documented but nonstandard format), sounds, etc. There's petabytes of content. The region servers tell the viewers what hashes (UUIDs) to ask for, the viewers get the content from the servers with ordinary HTTPS requests, and all this is assembled in the viewer into 3D images for the user.
Any user can upload new content. Uploading an image costs about US$0.05. Uploading a 3D model might cost $0.50. This is a one-time charge. As long as someone, somewhere, is using that content, it's kept on the servers. There's a garbage collection run every month or so.
Voice is outsourced to Vivox. (Vivox has problems. Not recommended for new designs.)
Coming soon is "puppetry". Second Life is now testing full body and face tracking, for those who want their avatars to run more than canned animations. This involves an entirely new data path by which viewers talk to other nearby viewers via a server that just forwards data. Second Life is getting VRchat features.
So that's what a viewer is. And that's what the architecture of a big metaverse looks like.
Quick overview:
Second Life / Open Simulator worlds are divided into "regions". Each region is 256m on a side on Second Life, and can be other sizes in Open Simulator. The world is about the size of Los Angeles. The viewer starts out by talking to a login server for a grid, which authorizes it to connect to a region. The viewer then talks to the region. There are short messages over UDP, and some bigger stuff over HTTPS.
Once a viewer is talking to a region, it asks the region server about adjacent regions. The viewer can then talk to a few adjacent regions, too, showing the user a big, seamless world. As the user moves around the world, connections are made to new regions, and connections to regions out of range are dropped. This is how the world scales. There are about 27,500 live regions today, each with its own simulator program, always on even if nobody is using it. Each simulator program takes about one CPU and under 4GB on a server. Second Life is currently hosted on AWS, with dedicated servers. This scales well; the world could be scaled up substantially if there was demand.
The always on feature runs up costs, but the business model is that users rent land. So costs and revenue stay in balance. Regions really are always on - trains run through regions where no one is around, for example. This architecture made more sense when Second Life had their own servers in a co-location facility.
The region servers talk to their direct neighbors. This allows movement across region boundaries. If a region goes down or is restarted, the viewer will show a water-filled hole with steep sides where the region is supposed to be. So the overall system is fault-tolerant.
Content is stored on asset servers, separate from the region servers. These are ordinary AWS web servers, front-ended by Akamai caches. Content includes textures (images in JPEG 2000 format, which is a pain to decompress fast), meshes (a documented but nonstandard format), sounds, etc. There's petabytes of content. The region servers tell the viewers what hashes (UUIDs) to ask for, the viewers get the content from the servers with ordinary HTTPS requests, and all this is assembled in the viewer into 3D images for the user.
Any user can upload new content. Uploading an image costs about US$0.05. Uploading a 3D model might cost $0.50. This is a one-time charge. As long as someone, somewhere, is using that content, it's kept on the servers. There's a garbage collection run every month or so.
Voice is outsourced to Vivox. (Vivox has problems. Not recommended for new designs.)
Coming soon is "puppetry". Second Life is now testing full body and face tracking, for those who want their avatars to run more than canned animations. This involves an entirely new data path by which viewers talk to other nearby viewers via a server that just forwards data. Second Life is getting VRchat features.
So that's what a viewer is. And that's what the architecture of a big metaverse looks like.