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.

I’ve taken on the task of porting Aurora’s variable region feature into OpenSimulator.

This port will use Aurora’s protocol extensions so the existing Firestorm and Singularity Aurora support will now work for OpenSimulator. The larger regions size will be restricted to multiples of 256 meters and adjacent regions (the ability to have other regions spacially next to larger regions) will not be implemented and will not work. Additionally, the larger regions must be square. This latter restriction is because the viewers currently (20131101) only use the X size dimension for both X and Y size. These restrictions are enforced by code in RegionInfo.cs which truncates and rounds values and output warning log messages.

The size is be specified in the Region.ini file:

[MyRegionName]
RegionUUID = 95ec77ec-58c5-4ce2-9ff3-b6d1900d78a2
Location = 1000,1000
SizeX = 1024
SizeY = 1024
InternalAddress = 0.0.0.0
InternalPort = 9200
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP

If size is not specified, it will, of course, default to the legacy size of 256.

Since this will be a major change to OpenSimulator that touches a lot of different parts, subsequent posts, will discuss the changes I’m making.