One of the most interesting developments in Opensim lately have been megaregions. Megaregions are non-standard “big” regions created by combining several standard, 256×256 meters regions. For example, you can combine four standard regions in a square to get a megaregion of 512×512 m. Megaregions are very convenient because of several reasons: for example the usual lag in region crossings disappears completely (since you are in the “same” region), and the same is true of vehicles. On the other hand, megaregion support is still experimental, and a number of things that work in normal regions don’t work or work only partially in megaregions. For example, you cannot define parcels outside of the SW region (this is due to the way parcel maps work), and therefore you can’t have independent music streams (for example) when x > 256 or y > 256.
Diva Canto’s distribution of Opensim directly supports megaregions. You can also migrate an existing non-megaregion installation to a megaregion configuration, if you follow certain precautions. Migrating from a megaregion configuration to a non-megaregion configuration is also possible — you change the setting that implements megaregions, “CombineContiguousRegions” to false, and it works as expected.
OAR support for megaregions is partial: since technically all the objects in the megaregion are stored in the SW region, when you take an OAR of the SW region you get all the objects of the megaregion but only the terrain for that same region — this means that you cannot fully rebuild a megaregion from an OAR, which is a pity (you will be missing the terrain files for all regions except the SW one).
In this post I’ll describe some experiments I made with an OAR manipulation tool I developped following a suggestion of Stefan Andersson. The tool takes as its input a megaregion OAR and splits it into several non-megaregion OARs, creating one OAR for each region that constitutes the megaregion and has objects in it. This is so because megaregions may have holes, and when a possible region does not have objects there’s simply no information in the megaregion OAR about whether a it’s a region with no objects (for example, a sea-only region) or a hole in the megaregion.
The tool works in a very simple way: the OAR contents is first optionally extracted, and then it iterates over each object in the megaregion, extracting the x and y coordinates from the XML2 file and calculating the position of the corresponding region in the grid (relative to the SW region). Then a copy of the object with new non-megaregion coordinates is written to a temporary directory called ‘objects.i.j’, where ‘i’ and ‘j’ are the grid coordinates offset + 1 (for example, the SW region will have i = j = 1, the region to its east i = 2, j = 1, the region to its north i = 1, j = 2, etc). Finally, each of these directories is temporarily renamed to ‘objects’ (the standard directory name for objects in a OAR), and the ‘tar’ command is invoked to produce a file called fname.i.j, where fname is the name of the original OAR file, or ‘region’ if this name is unknown.
For example, using the tool against a 2×2 megaregion OAR called ‘test.oar’ will produce 4 OARs: test.1.1.oar (the SW region), test.2.1.oar (the SE region), test.1.2.oar (the NW region) and test.2.2.oar (the NE region). The current version of the tool has two problems: the first one is that it does not attempt to perform asset splitting, that is, the original megaregion OAR contains the assets (i.e., textures, scripts, object contents, etc) for all the objects in the megaregion, and the splitted OAR files will contain a copy of all the assets in the megaregion (instead of only the assets corresponding to the objects in the splitted region); this can be manually corrected by “normalizing” the OAR file: load it into an empty region and save a new OAR.
The second problem cannot be corrected, and is due to the (already mentioned) fact that megaregions do not contain terrain data for regions different from the SW region. Due to this fact, all the OAR files produced will contain the same terrain file, that is, the terrain file corresponding to the SW region (would it be better if I simply didn’t include any terrain?). This is not so much of a problem as it appears, if we can have access by other means to the missing terrain files: we can manually load the terrain in the target region and later load the oar with the ‘–merge’ option, or we can first load the oar and then the terrain.
How should megaregion terrains be stored in OAR files?
It is very probable that a future version of the OAR file format will include terrain information for all the regions in a megaregion. There are two ways to store such information: one is to store a big r32 file with the terrain data for the whole megaregion, and another one is to store the individual terrain files for each region. Both approaches have advantages and disadvantages: storing the terrain for the whole megaregion is ideal if we want to do some kind of online editing of the terrain (this can also be done if we have the single-region terrain files, but we have to aggregate the terrains first, which is cumbersome); on the other hand, storing the individual terrain files is ideal for megaregion splitting tools like the one presented in this article. The ideal solution would be to include both the megaregion terrain and the individual region terrains, and define semantics for the OAR load process: for example, “use the megaregion terrain if it is present, else use the individual region terrains”.
Implementation and technical details
To save coding time, I’ve implemented the tool as a new command called “SPLIT” in version 0.2 of my ZOE OAR editor. You open a megaregion OAR file with ZOE, type “SPLIT”, and that’s it — in some seconds you have the new OAR files. I’ve also updated ZOE so that it now depends on Cygwin being installed (instead of using 7z like in version 0.1) — this means that ZOE should run unchanged under Linux (but I can’t test that since I don’t have access to a Linux machine). This also means that ZOE should be called using “rexx zoe oarname” instead of “zoe oarname” (Cygwin bash does not understand the latter). To summarize, here’s what you’ll need:
- Open Object Rexx.
- (Only for Windows:) Cygwin (tested with Cygwin 1.7.1-1).
- ZOE version 0.2, which you can download here.
Other minor changes in ZOE 0.2 are that the “zoe ??” and “zoe (c)” special calls have been eliminated (please refer to the documentation for ZOE 0.1 for details).