OpenSimulator now supports variable-sized regions, some of which can be
quite large. The recommended maximum is 8192m x 8192m, which is (4 x 8) x
(4 * 8) = 1024 times larger than the “standard” 256m x 256m region. Regions
of greatly increased size have exposed some weaknesses in the current
Terrain model. Some of the issues are discussed on the Wiki page
http://opensimulator.org/wiki/Varregion .
Database communications (in mysql – not sure about other DBs) is one place
where the change is very noticeable. Since a region's terrain is stored as
a single blob, the “max_allowed_packet” setting must be increased to
accommodate the greatly increased blob size for a large VarRegion. This
large size also appears to lead to noticeable pauses while the database is
updated during terraforming operations.
Here's what I'm thinking:
Since logic already exists for working with 16x16 patches, perhaps the
terrain can be persisted in the same layout. This might remove the need for
extremely large DB packet sizes, and may drastically reduce delays while
terraforming.
Start by adding a new table "Terrain_Patches", as shown below (naming
conventions, etc. TBD):
Terrain_Patches:
* region_uuid (varchar)
* x_pos (short)
* y_pos (short)
* blob? (16x16 float?)
Moving the actual elevation data out of the "terrain" table leaves it as
basically a header table.
terrain:
* RegionUUID (varchar)
* Revision (int) <-- 28?
* Heightfield (x_size (short), y_size (short)) <-- no height data here
When a region is terraformed, the already-existing taint logic can be used
to determine which patches need to be persisted. By adding a second taint
array ("m_db_taint"...?), and setting an element every time an "m_taint"
element is set, there will always be an up-to-date list of patches
requiring persistence. No need to re-write an entire region when only a few
patches changed. Removing the all-or-nothing requirement for loading
terrain can help prevent the immense packet sizes required by large regions.
I lack the skills to prototype this, so I'm throwing it out to the mailing
list for comments. Obviously, more re-work would be required in the code to
stitch together the patches, etc... This email is more about concept than
details.
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
