<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I am not familiar enough with the code to say if it can be done, but I like the idea of handling smaller patches of terrain instead of the entire region.<div class=""><br class=""></div><div class="">Frank</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 8, 2015, at 10:28 PM, Dev Random <<a href="mailto:digimancy+opensim@gmail.com" class="">digimancy+opensim@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">
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 <a href="http://opensimulator.org/wiki/Varregion" target="_blank" class="">http://opensimulator.org/wiki/Varregion</a> .<br class=""><br class="">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.<div class=""><br class=""></div><div class=""><span style="background-color:rgb(255,255,255)" class=""><br class=""></span></div><div class=""><span style="background-color:rgb(255,255,255)" class="">Here's what I'm thinking:</span><br class=""></div><div class=""><br class="">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.<br class=""><div class=""><br class=""></div><div class="">Start by adding a new table "Terrain_Patches", as shown below (naming conventions, etc. TBD):<br class=""><br class="">Terrain_Patches:<br class="">* region_uuid (varchar)<br class="">* x_pos (short)<br class="">* y_pos (short)<br class="">* blob? (16x16 float?)<br class=""><br class="">Moving the actual elevation data out of the "terrain" table leaves it as basically a header table.<br class=""><br class="">terrain:<br class="">* RegionUUID (varchar)<br class="">* Revision (int) <-- 28?<br class="">* Heightfield (x_size (short), y_size (short)) <-- no height data here<br class=""><br class="">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.</div><div class=""><br class=""></div><div class="">I lack the skills to prototype this, so I'm throwing it out to the mailing list for comments. <span style="background-color:rgb(255,255,255)" class="">Obviously, more re-work would be required in the code to stitch together the patches, etc... This email is more about concept than details.</span></div><div class=""><br class=""></div></div></div>
_______________________________________________<br class="">Opensim-dev mailing list<br class=""><a href="mailto:Opensim-dev@opensimulator.org" class="">Opensim-dev@opensimulator.org</a><br class="">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<br class=""></div></blockquote></div><br class=""></div></body></html>