I wanted to make the creation of varregions easier so I added some parameters to the ‘load oar’ simulator command. But, while I was in the area, I got a little carried away.

For varregions, ‘load oar’ now has a ‘–displacement “<x,y,z>”’ parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named ‘bigregion’. The following commands place the four regions of objects, terrains and parcels into the new larger region:

change region bigregion
load oar oar00.oar
load oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel oar01.oar
load oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel oar10.oar
load oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel oar11.oar

Note the new “–forceterrain” and “–forceparcel” parameters. “–merge”, used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

While I was in the neighborhood, I also added ‘–rotation degrees’ and ’–rotationcenter “<x,y,z>”’. These apply a rotation to all the objects in the OAR file before they are displaced and placed in the new region. The rotation center is relative to the original OAR and defaults to “<128,128,0>”. At the moment, the rotation is applied only to objects and not the terrain or parcels.

Say you have a 512x512 region named ‘bigregion2’ and an oar file with buildings named ‘buildings.oar’ which is from a 256x256 region. The following places the buildings big region rotated 30 degrees without modifying the terrain:

change region bigregion2
load oar --merge --displacement "<128,128,0>" --rotation 30 buildings.oar

The caveat to all this is that it is only in the ‘varregion’ source branch. More testing will make it get into the master branch quicker so test and file those manti.

And have fun with those OAR files.

After a brief hiatus recovering from a crashed disk and installing and becoming accustomed with Windows 8.1 (question to MS: what the heck were you thinking???), I’ve spent more time on the OpenSimulator varregion code.

The code is still on the ‘varregion’ branch of the source repository and it has been kept pretty close to the ‘master’ branch. I’ve added the size information to a bunch of the teleport messages trying to get teleport to a large region working. Sadly, it crashes Singularity whenever you log into or teleport to a non-legacy sized region in grid mode. Works in standalone mode. I haven’t tested it yet, but I’m hoping adjacent standalone large regions (like four 512x512) now border cross. It is an iffy thing, though, since there is ‘find my neighbor’ logic in Scene, GridService, EntityTransferModule, and a few other places. That logic does need some cleaning up.

I found that the Singularity crash when running in grid mode has to do with the fact that the grids out there are not running the ‘varregion’ code. In particular, OSGrid’s grid service is not storing and returning the region size. This means that Singularity gets told the destination region is zero by zero which is assumes means that region is legacy sized (256x256). The simulator, though, thinks the region is larger and sends terrain patches to Singularity for the larger region. Singularity doesn’t like that and it crashes complaining about bad terrain patches.

The fix is to get the grid services updated. To that end, I added a new commit to ‘master’ that adds the size accounting to RegionInfo, RegionData, and GridRegion classes. Since the database code already knows about storing the region sizes, this makes for a downward compatible update to the ‘master’ branch that does not change any APIs or change any functionality except for passing around and storing the region size along with its location.

Once that patch is distributed or cherry-picked (commit 6869633d76b2a6664743a608e4284b8dd7df85a6), testing will continue.

Seems that 8192 is a good maximum for region size. Both the viewer and the simulator agree.

To that end, I added Constants.MaximumRegionSize and have RegionInfo enforcing same.

Having a maximum region size is also good for searching for neighbor regions as this limits the search area. This constant is thus used in the ‘find neighboring region’ logic as well as the ‘find region containing point’ logic.

For the moment, this is in the varregion branch of the OpenSimulator source repository.

Most of the ‘move to new region’ code is based on checking boundaries. There is much code related to computing if an object or avatar has crossed a region boundary and then computing the address of the next region from same. Introducing variable sized regions messes a lot of this computation up. That is, the code doing the arithmetic usually assumes it knows the address of the next region based on a known region size and them can compute the location of the next region based on that. With varregions those assumptions no longer hold. Varregion implementation means that the computation of region base locations and border locations moves to the GridService who is the entity who really knows the size of all the regions and what is adjacent to what.

The realization that location to region computation is really a GridService operation lead me to totally rip apart the grid boundary checking code and replace it with two functions: Scene.PositionIsInCurrentRegion(Vector3 pos) and then IGridService.GetRegionContainingWorldLocation(double X, double Y). The former function tests to see if the object/avatar has moved out of the current region and the latter gets the region moved into.

A side note is the computation of positions. A region has a base X,Y that is measured in meters and in “region units” (the number of 256 regions to this point). For instance, the region location of (1000,1000) is in ‘region units’ which is the number of 256 meter regions to the location. The “world coordinate” of the region is (256000, 256000) – the meters from zero. These meter measurements are usually passed around at ‘int’s or ‘uint’s. An object/avatar within a region has a relative position – relative to the base of the region. This relative location is usually a ‘float’. So an object would be at (23.234, 44.768) withing a region. An object’s world location, though, must be a ‘double’ since a C# float has only 6 or 7 significant digits. An object’s relative location (float) plus a region’s base (uint) are combined into a world coordinate (double) that can be used to find the region that includes  that point.

One major problem is passing the terrain data from the region to the protocol stack. The existing implementation passed an array of floats that were presumed to be a 256x256 array of region terrain heights. The TerrainChannelclass is an attempt to hide the terrain implementation from TerrainModule. TerrainChannel can’t be passed into the protocol stack (LLClientView) because TerrainChannel is defined as part of OpenSim.Region.Framework which is not visible to the protocol code.

My solution is to create the TerrainData class in OpenSim.Framework. TerrainData just wraps the data structure for the terrain and additionally has the attributes giving X and Y size.

I didn’t want to change the signature of IClientAPI since so many external modules rely on it. It should be  changed to pass TerrainData rather than a float[]. I decided to not change IClientAPI but rather have LLClientView ignore the passed array and instead reach back into the associated scene and fetch the TerrainData instance.

At the moment, all of these changes are in the varregion branch of the OpenSimulator repository.