<div dir="ltr">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 <a href="http://misterblue.com">http://misterblue.com</a> and in my OpenSim circle on Google+. People suggested this is another forum for notes. Well here are a few notes:<div>
<br></div><div><h2 class="" style="font-family:Veranda,Arial,Helvetica,sans-serif;font-size:12px;margin:0px;padding:0.25em 0px;border:none"><font color="#000000"><a href="http://misterblue.com/wwpp/archives/20131129-varregion">VarRegion: adding TerrainData and HeightmapTerrainData classes</a></font></h2>
<div class="" style="font-size:12px;margin:0px;padding:0px;font-family:Veranda,Arial,Helvetica,sans-serif"><p style="margin-top:5px"><font color="#000000">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 <tt>TerrainChannel</tt>class is an attempt to hide the terrain implementation from <tt>TerrainModule</tt>. <tt>TerrainChannel</tt> can’t be passed into the protocol<br>
stack (LLClientView) because <tt>TerrainChannel</tt> is defined as part of <tt>OpenSim.Region.Framework</tt> which is not visible to the protocol code.</font></p><p style="margin-top:5px"><font color="#000000">My solution is to create the <tt>TerrainData</tt> class in <tt>OpenSim.Framework.</tt> <tt>TerrainData</tt> just wraps the data structure for the terrain and additionally has the attributes giving X and Y size.</font></p>
<p style="margin-top:5px"><font color="#000000">I didn’t want to change the signature of IClientAPI since so many external modules rely on it. It should be  changed to pass <tt>TerrainData</tt> rather than a <tt>float[]</tt>. I decided to not change IClientAPI but rather have <tt>LLClientView</tt> ignore the passed array and instead reach back into the associated scene and fetch the <tt>TerrainData</tt>instance.</font></p>
<p style="margin-top:5px"><font color="#000000">At the moment, all of these changes are in the <tt>varregion</tt> branch of the OpenSimulator repository.</font></p><h2 class="" style="font-size:12px;margin:0px;padding:0.25em 0px;border:none">
<font color="#000000"><a href="http://misterblue.com/wwpp/archives/20131129-varregion-crossing-region-boundries">Varregion: crossing region boundries</a></font></h2><div class="" style="margin:0px;padding:0px"><p style="margin-top:5px">
<font color="#000000">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.</font></p>
<p style="margin-top:5px"><font color="#000000">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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>IGridService.GetRegionContainingWorldLocation(double X, double Y)</tt>. 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.</font></p>
<p style="margin-top:5px"><font color="#000000">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.</font></p>
<h2 class="" style="font-size:12px;margin:0px;padding:0.25em 0px;border:none"><font color="#000000"><a href="http://misterblue.com/wwpp/archives/20131129-varregion-maximum-region-size">varregion: maximum region size</a></font></h2>
<div class="" style="margin:0px;padding:0px"><p style="margin-top:5px"><font color="#000000">Seems that 8192 is a good maximum for region size. Both the viewer and the simulator agree.</font></p><p style="margin-top:5px">
<font color="#000000">To that end, I added <tt>Constants.MaximumRegionSize</tt> and have <tt>RegionInfo</tt> enforcing same.</font></p><p style="margin-top:5px"><font color="#000000">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.</font></p>
<p style="margin-top:5px"><font color="#000000">For the moment, this is in the <tt>varregion</tt> branch of the OpenSimulator source repository.</font></p></div></div></div></div></div>