One of the single most common requests for OpenSim has been “I want bigger regions” – coming originally from an ActiveWorlds background, I wholeheartedly agree.
Space is still a major constraint – and while OpenSim allows you to run multiple regions within a single simulator – it’s a poor comparison because crossing region borders, even within the same machine are a complicated and error-prone process; requiring the client to disconnect and reconnect at least once. This preventing any kind of “instant” handoff on a technical level. Megaregions are a new bit of code that solves this problem by side-stepping it (a.k.a cheating).
Regions within the same simulator process can be ‘combined’ via the new RegionCombinerModule; to the client all the regions that existed in the server previously become ‘neighbours’ rather than full regions in their own right; while the original region takes authority over the combined original space. Objects get coordinates that no longer resemble 0,0-255,255, they now can reach values such as “1077,2099″, and likewise your avatar and any positional coordinates you see reflect this new larger domain.
The result is you can use these combined regions to make ‘megaregions’ that exceed the original 256×256 bounds. I personally have tested both 512×512 and 2048×2048 regions (comprised of 4 and 64 original regions respectively) and it is awesome. For vehicles I can see this being a very impressive and useful new feature – eliminating border crossings makes for bigger racetracks and faster speeds. Sailors can build oceans that aren’t equivilent to a lake-in-the-backyard, and if my estimate of 5MB per empty region holds true at scales larger than 64 regions in size; then it’d be possible to build a 4km x 4km ocean on a server with less than 2GB of RAM (equivilent to about 256 sims normally).
Pictures are of course essential for this post – the first picture below has me selecting a 65,536sqm parcel for comparison — everything you can see in the picture is but a small fraction of a single region. (11 cells are visible, of a total of 64)
…and a slightly larger picture of the same sim showing a few more cells at once.
Finally, I recorded some video of vehicles playing around on one of these megaregions (from a slightly earlier version when the largest regions were a bit smaller). This is in OpenSim trunk now; however it does have some known issues – so I wouldnt do anything resembling production work on this code for a long while until it has been more properly tested. I’d like to do some more testing with this and vehicles at a later date however, as OpenSim/ODE’s support for vehicles has improved dramatically in the last few months.
You my friend rock!! Thanks so much for continuing to improve the platform beyond expectations.
Kyle G
8 Sep 09 at 3:21 pm
Aside from stability, what are the Combined Regions’ deficits, compared to separate instances? For example, are the combined regions sharing a single ODE instance? Also, what is the maximum Combined Region size? I know you were working this weekend on a 64×64 megaregion. I’d love to do a virtual Central Park.
Omar Abedelrahim (Jim Siler)
8 Sep 09 at 4:25 pm
Woah, that is amazing!
Alvi Halderman
8 Sep 09 at 4:39 pm
Adam, this is very interesting news indeed. It is also good to see vehicle support get better.
Question, does this support prims crossing region boundaries?
Darryl
8 Sep 09 at 6:04 pm
How does this impact scripting? Does llGetPos (llGetRegionName, etc, etc, etc) reflect position within the megaregion, or the particular (um) subregion?
Dale Innis
8 Sep 09 at 6:32 pm
wow nice – i like it so how i can get that create the new megaregion
andrew
8 Sep 09 at 7:47 pm
Good gracious, the impossible has been made true.
Congratulations, Adam, nice work! Thanks for that! And it’s on trunk already? Oh wow!
Gwyneth Llewelyn
9 Sep 09 at 1:51 am
Are these “megaregions” only for you to test or can they be made available for others to test?
Dr B the Master
9 Sep 09 at 10:21 am
Now this is a great deal ! If there’s a proof of concept in local mode, it might not work in full public mode (mega-region + lotos lots lots of prims + a crowd of avatars … OUCH !). But imagine AM Radio creating on this big land
Imagine a desert … Desert ? Burning Sim ? Adam what about a live test in the Burning Man style ? If this seed grows in the sand please consider me to be part of the fun and creation 
Samare Thor
10 Sep 09 at 6:38 am
@Dale Innis : It reflects the position relative to the south west most region. It’s possible to have an object at . For all grid services, they act as individual regions.
@Omar Abedelrahim: They all share one ODE Physics instance.
@all: It is available in the Git repository now. It works best with standalone, but GridMode works with bugs. The trick is to get your regions to load in order from South to North, West to East, and then add CombineContiguousRegions=true to the [Startup] section of OpenSim.ini
Teravus
10 Sep 09 at 5:44 pm
Re: my previous comment, it took out the position that I entered.
It reflects the position relative to the south west most region. It’s possible to have an object at 2012,780,22
Teravus
10 Sep 09 at 5:47 pm
Adam and Teravus, how does this impact the number of avatars which can be in a single region?
Hamlet Au
10 Sep 09 at 8:02 pm
Woah.
Quite a few comments here. I’m going to assume Teravus answered all the pertinent ones above – so to answer Hamlet:
It doesnt significantly improve the number of avatars in a single region, since you still have the same network limitations/etc.
Arguably it could be worse – since you are encouraging more regions on a single server; but the technical answer is ‘No difference’.
The lag on border crossings is however completely eliminated for regions combined by this system – see the video I posted at the end of the link.
Crossings between different megaregions, or otherwise inter-server will still proceed at the current pace, since you are forced into doing the usual network handoff there, and can’t ‘cheat’ your way out of it. (although it can be optimised. See Diva & Melanie’s work in that department.)
Adam Frisby
10 Sep 09 at 9:30 pm
Second addendum: they dont need to be square, or even rectilinear. You can use any contigous pattern of regions.
So a pixellated circle, triangles and other megaregion patterns are quite possible. The big limitation is system memory – my initial tests put the memory cost on .NET at about 5MB per extra tile — so say a 1024 region system (eg; 8192m x 8192m) would need ~5GB of memory to host.
Adam Frisby
10 Sep 09 at 9:33 pm
Thanks Adam, updating my post accordingly!
Hamlet Au
11 Sep 09 at 6:19 am
Intrestingly, I recently wrote a blog about the future of OpenSim being focused on 512m regions (4 sims combined that would run on a single core and cost the same as current 256m regions). http://elfclan.ning.com/profiles/blogs/the-512m-megasim-concept
Not being an OpenSim tech (just a standard user), my question is this: would the concept of mega-regions allow someone to run say, 4 regions on a single core with close to the efficiency of a single regions?
For example, let’s say one puts 20,000 prims in each regions. Taking it for granted that the same number of avatars and scripts were present in either scenario (256 or 512), could a single core run a 512 just as efficiently and speedily as a 256?
If the answer is yes, think of it: four people could co-own a 512 mega region at a cost of about $20 to $25 each… and for the first time entire sims would be affordable to the average person.
What about a single core handing 8 regions? 12? Basically: What are the core performance-per-region limitations and consequences in the concept of multi-region megasims? I feel pretty confident that 512m (4 sims) would work ok on a single core, with 20,000 to 32,000 prims per sim. Would like to have that belief verified (or anti-verified).
Along this line, we may have some terminology that would come in handy too. A “sim” (as in “OpenSim”) could refer to a single region. A “region” could refer to two or more contiguous sims on the same server. A “grid” could refer to two or more non-contiguous sims or regions. That’s handy.
When we get individual regions down to a cost of $20 to $25 a month and the code functioning properly, the LL strangle-hold and $295 regions will quickly become a thing of the past, and VR will be truly ready for prime-time.
Wayfinder Wishbringer
14 Sep 09 at 6:24 pm
What I have been eagerly waiting for. Kudos x 10^34. My dream of a mostly-ocean 4096×4096m region with a population cap of 6 AV + 6 Bot is looking quite possible. The ability to have a round(ish) shape (ie, clip off unneeded corners) is a nice bonus too!
LaeMing
15 Sep 09 at 8:30 am
@Adam “So a pixellated circle, triangles and other megaregion patterns are quite possible”
now you got my head spinning. Say, hypothetically, you have a grid with megaregions. Since they don’t have to be rectilinear, say can you do a buckyball spherical pattern?
Will actual planets be one day possible?
hypatiaa
15 Sep 09 at 6:52 pm
opensim is the future of all online worlds
this combined with silver lining..who knows whats possible
a see a bright future for opensim
vince braver
16 Sep 09 at 10:08 pm
The only problem I foresee is the fact they all share the same ODE instance. 1024 sims sounds awesome, but the weakest link is ODE. OpenSIM has made strides with it since they first started using it and its the best physics engine they have, but compared to commercial engines like Havok and PhysX its extremely primitive. If someone tries to rez over 100 physical objects they could crash an entire mega-region. If support for better physics engines could be implemented it would fix a lot of issues.
Ron Overdrive
18 Sep 09 at 8:04 pm
@hypatiaa. “can you do a buckyball spherical pattern?”
I believe it still has to be flat, you can just leave out 256m squares you don’t need (such as mega-region corners for a circular-ish region like my Impact sim).
LaeMing
19 Sep 09 at 4:50 am
ODE is over 10 years old, and was written only for single-core machines. Personally, I would replace all of the physics subsystems with PAL, or Physics Abstraction Layer. It is an open source wrapper for several physics engines, allowing for seamless integration. It supports Bullet, JigLib, Newton, ODE, nVidia PhysX, Tokamak, and TrueAxis, with experimental support for Box2D, Havok, IBDS, OpenTissue, and Simple Physics Engine.
Now PhysX is one I’d like for OpenSim to support. Why? Three words: Hardware Accelerated Physics. If you have a server with a GeForce 8000 series card or higher, then you could use it. The graphics card GPU would perform all the physics calculations, taking the load off of the CPU and greatly reducing lag.
In all honesty, if you want a sim with racing and boating, you would DEFINATELY want hardware-accelerated physics, or at least something better than what ODE can handle. I don’t know why the opensim devs focus so much on ODE when there are better physics engines available. The use of the Physics Abstraction Layer would definately open up new possibilities and streamline the physics code.
Zauber
19 Sep 09 at 5:04 am
I realise it has to be flat *now* but … infinity grid would be nice
hypatiaa
21 Sep 09 at 12:38 am
@Zauber, The biggest problem with Phsyx and Havok support is cost, your looking at bills in the 6 figure range to license either per project. OpenSimulator does not qualify to be used for free. Not to mention server side physics, I highly doubt there are any examples or implementations in any kind of game or VW that uses server side hardware accelerated physics of any kind.. Its not just a simple drop in a physics package and it works. Out of all the engines ODE is the most open and compatible license for this project. There have been attempts to make Bullet work but none have gone well or gotten very far.
Nebadon Izumi
22 Sep 09 at 6:41 am
@Nebadon PhysX and Havok are free for personal use. There’s a PhysX wrapper that comes with OpenSIM, but its dated and is incompatible with the current version. The only way using these commercial engines pose a problem is if you are intending to run a commercial grid. For personal and non-profit grids (ie, those used by Education) would qualify for the inexpensive/free licenses. Utilizing the suggested wrapper (PAL) would not violate any licenses, but would open up options for the grids that wish to use said commercial engines. ODE would still be available for grids who don’t have the capitol for commercial licensing fees.
Ron Overdrive
24 Sep 09 at 4:39 am
this is all wonderful information. Thanks.
Now if someone could just tell me how to get a 64 bit physics engine to work with opensim without having to waste RAM using the 32 bit exe, or a 32 bit virtual machine, I would be ecstatic.
We have to get this working if opensim is going to make it through the transition to 64 bit Operating systems. Right now about 75% of new computers are 64 bit.
myron Curtis
12 Dec 09 at 4:46 am
To me, the dream is to build truly scale projects that take a lot of space. As mentioned by Omar Abedelrahim, a replication of Central Park (NYC). Or a model of the Gateway Arch (in St Louis) with a working elevator for avatars. The arch would span two standard regions.
Commercially, I can see home builders modeling EVERY house plan they offer on streets exactly like the community they are building. The ability to visualize an entire streetscape allows clients to visualize what they cannot see in blueprints. Yes, even with the ability to see the sunlight accurately coming through the windows.
City planners could tell the story of encroachment on wetlands without field trips in their overshoes. The possibilities grow in my imagination as I stand in my recently built 512×512 mega-region.
Ethos Erlanger
27 Dec 09 at 8:22 pm
Greetings, what is the thing with prims on Mega-Region? The SW one reads (calculates) prims the correct way, but all the other 3 regions show 0 prims on Region, however many I have there.
Do I risk loosing the builds I have on the other three regions?
Cay Trudeau
19 Jan 10 at 10:39 am
No, you can use a command (but it escapes me right now) to import the content in the other three regions into the first megaregion. It’s something like “fix-ghosts”.
Adam Frisby
23 Jan 10 at 5:16 am