Migrating from Flat to Spherical Grids

Legacy

Given that VR began in the era before neural networking, beowulf clusters, and multithreaded processing, it is unsurprising that VR spaces have always been rather limited in the amount of virtual "real estate" represented in a given simulator, because a single sim ran on a single server, so scaling was always an issue.

Even with a large grid like Second Life, it is an asset and server centered architecture, where a single region of 256x256 meters of virtual land is operated on a single server core. Even when you can run multiple sims on a single core, they were still separate regions that may or may not be virtually adjacent on the grid.

Because of this architecture, in order to cross from one region to another, necessitated the users viewer essentially log out of one regions server and into the server of the adjacent region one is entering, along with all assets that the users avatar is wearing and/or sat upon (in the case of moving vehicles). While the system is designed to make this visually as seamless as possible, it still results in a considerable lag of several seconds that breaks the sense of immersion and can even result in the users viewer crashing.

Other VW platforms have different region sizes. Decentraland, for instance, treats every 16x16 square meter parcel of NFT LAND as its own entity, unless one person owns adjacent parcels and can have them load together. Sansar promises 4kmx4km region sizes, but non-gridded, and they are all tightly curated and very empty.

Var-regions and Megaworlds

In order to resolve this issue for most purposes, given the relatively small size of a standard region, in opensim, var-regions were invented in Opensim. This technology allows for a wide range of region sizes, from the legacy 1 sim 256x256 up to a typical maximum of 1kmx1km (8x8 or 64 SL sized regions in one), however experiments by the US Army's MOSES program on the PhysX enabled platform had regions as large as 32x32 kilometers for simulated exercises.

Experiments With Spherical Grids

Mike Lorrey and Rob Lindman experimented with changing the grid topology from a flat plane to a sphere in 2014. An early prototype with a 36 region grid in a sphere worked relatively well, though with a significant amount of distortion given the small sphere size. Using a UV Sphere layout, as opposed to an Icosphere, (an Icosphere is geodesic while a UV sphere is organized like lines of latitude and longitude with a planet globe.) This arranged four rows of eight regions covering 75% of the sphere, with region geometry being slightly skewed into trapezoidal shapes.

For this reason, treating distance and positional coordinates as meters was fraught. Each region remained 256 units on each side, but as with polar coordinates, a degree of longitude would vary in length from equator to poles, almost 12 meters at the equator. Obviously with a larger grid, there would be less change in the dimensions of a region from one end to the other.

Other Topologies

Similar experiments would work for both toroidal worlds as well as Ringworlds. A Ringworld would be less problematic for distortion of region dimensions.

Benefits of Round Topologies

One obvious benefit of round topologies is to represent a grid as an actual planet, which also means there is the possibility of simulating actual space travel between planets, and offering grids that are analogs of real worlds like Earth, the Moon, Mars, etc.

Problems With Curved Grid Topologies

The obvious problem is the distortion of regions from the standard square, however this is really only a problem if the grid is operating on the traditional SL/OS architecture of region/server relationships, a geography service architecture. Ultimately, the solution to all these problems is to shift entirely to a service oriented architecture where server resources are user focused, not region focused. These ideas will be explored in [Universe Simulations].