Considering SL large regions

While reading the transcript of the Simulator User Group meeting of Tuesday 25th September as a part of preparing my last SL projects update, I came across an interesting exchange on the subject of large regions –  megaregions in OpenSim parlance – which gives some insight into the broad level of thinking about the platform that goes on within the Lab.

For those unfamiliar with the concept, a megaregion is essentially a number of standard 256×256 metre regions stitched together to present what appears to be a single large region. These are generally presented in terms of areas equivalent to 2×2 regions (i.e. 4 region in total) or 3×3 (equivalent to nine regions) and so on.

The Universal Campus designed for 4-region (2×2) megaregions, created by Michael Emory Cerquoni. The arrow indicates my avatar, to demonstrate the size of the build

Megaregions have been available within the OpenSim environment for the last few years, and are seen as means of providing far more space free from the terrors of region crossings, greatly facilitating a range of activities – flying, sailing, vehicle racing, etc., – although there are some limitations with them at present, which can make working with them difficult (parcel media tends to be restricted to the South-west corner “region” of a megaregion, for example, and elements such as terrain textures cannot currently be easily edited).

Second Life is very much geared to the 256×256 metre region, so it was surprising to come across a discussion on large regions in SL – and to learn that Linden Lab have in fact looked at them in some detail. The revelation came in a comment from Simon Linden, “Yeah, big regions have been a pet project of mine … unfortunately it’s an incredible hassle to get right,” he goes on to say, a short time later:

I’ve spent some serious time looking at large regions … it’s a huge project to do it right, involving a bunch of messaging changes to the viewer (like layer data, object positions, etc), region-to-region communication (all the neighbours) our back-end (the grid layout itself) … it touches almost everything in some way, which is why we’re where we are today 😛

Simon also indicated that he felt an ideal size for large regions – were they ever to happen – would be to a scale of 1 km on a side, rather than  1024m on a side (as would be the case if large regions were somehow “scaled up” from the current region size, as with OpenSim). However, this would mean breaking away from the current power of 2 approach to building Second Life, and might lead to position translation issues (as in translating the position known in one region to the relative position in a neighboring region), although Andrew Linden felt this might actually be easier to handle this in 1k blocks between neighbouring regions, rather than relaying on power of 2. When asked as to what would happen to the 24 metres per side which would be lost in scaling to 1000x1000m, rather than 1024×1024, Andrew suggested (semi-jokingly) that they’d be lost “To … boundary conditions.”

Large regions in SL would offer much to the sailing, flying, role-play and racing communities, were they possible

Were any change in region sizes to be undertaken, they would not be limited to just the simulator / server-side of things. The viewer itself is predicated on the power of 2 approach, being specifically geared to handling regions of 256m on a side (hence why megaregions in OpenSim have some limitations in terms of editing, etc.). So for large regions to work properly, it is likely that substantial changes would have to be made to the viewer – which even with the best will in the world, isn’t something which is going to happen any time soon, even were LL pondering looking beyond the theoreticals of large regions.

Nevertheless, the fact that the matter has been – and might still be – something some in Linden Lab are actively looking at, even at only the conceptual level, is interesting, and does tend to demonstrate that LL do think about the platform in somewhat radical ways.

13 thoughts on “Considering SL large regions

    1. Pricing would be an issue. One scenario might be for LL to simply “replace” the current full regions with “large regions” pitched at the same price, not so heavily squished into servers and with some increased capabilities, then do something similar with Homesteads. Thus, tier issues are “solved” in terms of people getting more product for their $ and LL not taking a hit revenue-wise, or upsetting the land barons.

      Of course, that could open additional cans of worms – which is why I opted to discuss the discussion, rather than delve additionally into pricing, as that is so very, very open (and I’m sure others have views of their own!).


      1. wow that would be nice. i think there might be some demand for smaller regions as well. personally i could never afford a mega region, but might be all over a mini-region of say half size and prims of a full sim.


  1. A kind of intermediate step in this direction has been discussed for the mainland.
    Clustering adjacent regions onto the same server could, maybe, perhaps help with sim crossings (some of which would become region crossings within the same sim 🙂 ). It may also make for easier mother – daughter relationships between the clustered regions.
    I am not sure if this has actually been tried, last I heard the hangup was in the random way the regions are assigned to sim servers. There simply is no concept of adjacency in that system now.


    1. Haven’t heard anything myself, but then I’m not overly au fait with Mainland, and haven’t been since around mid-2007. However, would have said sim / server allocations would have been the problem there myself.


  2. In the past, I’ve heard a couple of things that went against Large Regions.

    1: There were assumptions in the server code about region size, such as source-code constants and use of power-of-2 arithmetic, rather than compiler optimisations.

    2: Connecting different-sized regions is hard.

    The second, at least, could be avoided by a private island approach. Some of the sandbox regions could be replaced by a megaregion. Likewise, maybe the Linden Home regions: start off with a few test regions, a new continent.

    A bigger problem may be the apparent conflict between open source and proprietary code. OpenSim is open source, and I suspect the Lindens are backing away from open source as fast as they can manage. There is proprietary code in both the viewer and the server now, and they’re using it to put up barriers against OpenSim.


    1. The power of 2 situation was discussed in the meet – as you point out and as mentioned in the article, much SL was predicated on that. Andrew Linden actually commented in the meeting:

      The reason we picked powers of 2 originally was because we were sending DCT compressed data for the heightfield which is easier to code for powers of 2. But, as we know now… the DCT compression stuff is not a good idea.

      The proprietary code situation could be answered by making any large regions – were they to happen – could be handled through a region model that is, say 1 km on a side, and re-coding the viewer to specifically handle units of that size. Problem is, and outside of the issues you mention vis placement (assuming everything went on the same grid) & things like position translation, etc., is the sheer size of the effort involved. Hard to see it realistically happening.


Comments are closed.