[Opensim-dev] Notes on varregion

Mister Blue misterblue at misterblue.com
Sat Nov 30 03:43:00 UTC 2013


There are so many 'social network' services that I don't know where to
publish anything any more. I've taken to putting notes on my 'varregion'
implementation on my blog at http://misterblue.com and in my OpenSim circle
on Google+. People suggested this is another forum for notes. Well here are
a few notes:

VarRegion: adding TerrainData and HeightmapTerrainData
classes<http://misterblue.com/wwpp/archives/20131129-varregion>

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 256×256 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
TerrainDatainstance.

At the moment, all of these changes are in the varregion branch of the
OpenSimulator repository.
Varregion: crossing region
boundries<http://misterblue.com/wwpp/archives/20131129-varregion-crossing-region-boundries>

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.
varregion: maximum region
size<http://misterblue.com/wwpp/archives/20131129-varregion-maximum-region-size>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20131129/ea9603d6/attachment-0001.html>


More information about the Opensim-dev mailing list