OpenSimulator - User contributions [en]

ExtendedPhysics

2023-05-25T17:28:55Z

Misterblue: Add description of axis lock functions

= ExtendedPhysics =

'''ExtendedPhysics''' is an OpenSimulator module that adds
LSL functions and constants that provide
physics engine extension functions.

The module is designed so to work with any physics engine
but, at the moment, only '''BulletSim''' implements these functions.
These functions can be called when using any physics engine but
nothing will change.

The OpenSimulator default configuration has '''ExtendedPhysics'''
disabled. To enable '''ExtendedPhysics''', add the following
to any of the configuration INI files:

<pre>
[ExtendedPhysics]
Enabled = true
</pre>

== Informational Functions ==

This request returns the type of the physics engine.
This function returns the same as <code>osGetPhysicsEngineType</code>
which is a string identifying the type of the physics engine.

The BulletSim physics engine returns the string "BulletSim".

The function <code>osGetPhysicsEngineName</code> returns a string
that has additional information than just the type.
For instance, version numbers or types of accelerators being used.

<pre>
string physType = physGetEngineType();
string morePhysType = osGetPhysicsEngineName();
llOwnerSay(0, "Physics engine type = " + physType);
llOwnerSay(0, "Physics engine type again = " + morePhysType);
</pre>

== Disable Deactivation Function ==

Disable physics deactivation on the containing physical object.

The Bullet physics engine saves CPU cycles by only
checking "active" physical objects. Physical objects start out
active and are deactivated when their linear or angular velocity
falls below some threshold. For instance, if a scene has 100
physical balls that are dropped and roll around, the physics
engine has to test each of the 100 balls multiple times a second
to compute their movement. As some of the balls slow down and
stop moving, the balls are stopped and "deactivated" and thus
the physics engine doesn't need to check the stopped physical
object any more.

Physical objects are re-activated when another physical object
bumps into them but otherwise, they stay still.

This deactivation is usually a great CPU saver but there are cases
where it causes objects with small movements or movements that are
effected by non-physical objects. A ball on a tilting surface, for
instance.

This function disables deactivation -- setting "true" means the object
will never be deactivated.

<code>
<pre>
physDisableDeactivation(TRUE);
</pre>
</code>

== Axis Lock Functions ==

These requests effect the movement of a physical object around its
various axis.

The effect of these requests is to create a constraint on one or more
of the axis of the physics object.

The constraints are given as a list of parameters. Some of the functions
take no parameters and some take two. Multiple constraints can be set in
one request and they are processed from left to right.

For instance, the following request constrains a physical object to
only move along its local Z axis with no rotation:

<code>
<pre>
physAxisLock(PHYS_AXIS_LOCK_ANGULAR, PHYS_AXIS_LOCK_LINEAR_Y, PHYS_AXIS_LOCK_LINEAR_X);
</pre>
</code>

There are code that clear all of the settings -- <code>PHYS_AXIS_UNLOCK</code> unlocks all the linear
and angular constraints, for instance.

{|
|-
! Code || Description
|-
| PHYS_AXIS_LOCK_LINEAR || Lock all linear motion. No parameters.
|-
| PHYS_AXIS_LOCK_LINEAR_X || Lock all linear motion along the local X axis. No parameters.
|-
| PHYS_AXIS_LIMIT_LINEAR_X || Limit linear motion along the local X axis. Two parameters giving low and high relative X position.
|-
| PHYS_AXIS_LOCK_LINEAR_Y || Lock all linear motion along the local Y axis. No parameters.
|-
| PHYS_AXIS_LIMIT_LINEAR_Y || Limit linear motion along the local Y axis. Two parameters giving low and high relative Y position.
|-
| PHYS_AXIS_LOCK_LINEAR_Z || Lock all linear motion along the local Z axis. No parameters.
|-
| PHYS_AXIS_LIMIT_LINEAR_Z || Limit linear motion along the local Y axis. Two parameters giving low and high relative Z position.
|-
| PHYS_AXIS_LOCK_ANGULAR || Lock all angular motion. No parameters.
|-
| PHYS_AXIS_LOCK_ANGULAR_X || Lock all angular motion around the local X axis. No parameters.
|-
| PHYS_AXIS_LIMIT_ANGULAR_X || Limit angular motion around the local X axis. Two parameters giving low and high values in radians.
|-
| PHYS_AXIS_LOCK_ANGULAR_Y || Lock all angular motion around the local Y axis. No parameters.
|-
| PHYS_AXIS_LIMIT_ANGULAR_Y || Limit angular motion around the local Y axis. Two parameters giving low and high values in radians.
|-
| PHYS_AXIS_LOCK_ANGULAR_Z || Lock all angular motion around the local Z axis. No parameters.
|-
| PHYS_AXIS_LIMIT_ANGULAR_Z || Limit angular motion around the local Z axis. Two parameters giving low and high values in radians.
|-
| PHYS_AXIS_UNLOCK_LINEAR || Unlock all linear motion constraints
|-
| PHYS_AXIS_UNLOCK_LINEAR_X || Unlock any linear motion constraint on the X axis
|-
| PHYS_AXIS_UNLOCK_LINEAR_Y || Unlock any linear motion constraint on the Y axis
|-
| PHYS_AXIS_UNLOCK_LINEAR_Z || Unlock any linear motion constraint on the Z axis
|-
| PHYS_AXIS_UNLOCK_ANGULAR || Unlock all angular motion constraints
|-
| PHYS_AXIS_UNLOCK_ANGULAR_X || Unlock any angular motion constraints around the X axis
|-
| PHYS_AXIS_UNLOCK_ANGULAR_Y || Unlock any angular motion constraints around the Y axis
|-
| PHYS_AXIS_UNLOCK_ANGULAR_Z || Unlock any angular motion constraints around the Z axis
|-
| PHYS_AXIS_UNLOCK || Unlock all linear and angular constraints
|}

For instance, constraining
movement along the X axis,
not allowing any movement on the Z axis,
and limiting rotation around the Y axis
would be accomplished with:

<code>
<pre>
physLockAxis(PHYS_AXIS_LIMIT_LINEAR_X, 0, 5.5, PHYS_AXIS_LOCK_LINEAR_Z, PHYS_LIMIT_ANGULAR_Y, -0.785, 0.785);
</pre>
</code>

== Linkset Manipulation Functions ==

<pre>
PHYS_LINKSET_TYPE_CONSTRAINT = 0;
PHYS_LINKSET_TYPE_COMPOUND = 1;
PHYS_LINKSET_TYPE_MANUAL = 2;

public int physSetLinksetType(int linksetType)

int lsType = physGetLinksetType();

PHYS_LINK_TYPE_FIXED = 1234;
PHYS_LINK_TYPE_HINGE = 4;
PHYS_LINK_TYPE_SPRING = 9;
PHYS_LINK_TYPE_6DOF = 6;
PHYS_LINK_TYPE_SLIDER = 7;

physChangeLinkType(int linkNum, int lType)

physGetLinkType(int linkNum)

physChangeLinkFixed(int linkNum)

PHYS_PARAM_FRAMEINA_LOC = 14401;
PHYS_PARAM_FRAMEINA_ROT = 14402;
PHYS_PARAM_FRAMEINB_LOC = 14403;
PHYS_PARAM_FRAMEINB_ROT = 14404;
PHYS_PARAM_LINEAR_LIMIT_LOW = 14405;
PHYS_PARAM_LINEAR_LIMIT_HIGH = 14406;
PHYS_PARAM_ANGULAR_LIMIT_LOW = 14407;
PHYS_PARAM_ANGULAR_LIMIT_HIGH = 14408;
PHYS_PARAM_USE_FRAME_OFFSET = 14409;
PHYS_PARAM_ENABLE_TRANSMOTOR = 14410;
PHYS_PARAM_TRANSMOTOR_MAXVEL = 14411;
PHYS_PARAM_TRANSMOTOR_MAXFORCE = 14412;
PHYS_PARAM_CFM = 14413;
PHYS_PARAM_ERP = 14414;
PHYS_PARAM_SOLVER_ITERATIONS = 14415;
PHYS_PARAM_SPRING_AXIS_ENABLE = 14416;
PHYS_PARAM_SPRING_DAMPING = 14417;
PHYS_PARAM_SPRING_STIFFNESS = 14418;
PHYS_PARAM_LINK_TYPE = 14419;
PHYS_PARAM_USE_LINEAR_FRAMEA = 14420;
PHYS_PARAM_SPRING_EQUILIBRIUM_POINT = 14421;

PHYS_AXIS_ALL = -1;
PHYS_AXIS_LINEAR_ALL = -2;
PHYS_AXIS_ANGULAR_ALL = -3;
PHYS_AXIS_LINEAR_X = 0;
PHYS_AXIS_LINEAR_Y = 1;
PHYS_AXIS_LINEAR_Z = 2;
PHYS_AXIS_ANGULAR_X = 3;
PHYS_AXIS_ANGULAR_Y = 4;
PHYS_AXIS_ANGULAR_Z = 5;

physChangeLinkParams(params ....)
</pre>

ExtendedPhysics

2023-05-25T14:52:58Z

Misterblue: ExtendedPhysics module documentation

Next Gen

2022-02-15T17:17:03Z

Misterblue: Initial talking about what should be done by Misterblue

A wiki area to discuss a possible next generation OpenSimulator.

There are many people and groups who have forks and OpenSim side projects.
MisterBlue on 14-Feb-2022 suggested puling these side projects together and
make a new and improved future OpenSimulator.

MisterBlue is creating a new protocol and viewer that initially works with OpenSim.
A new viewer is a first step toward breaking away from the chains of Second Life
compatibility.

The list of requested features from attendees of [http://conference.opensimulator.org/2021/ OpenSimulator Community Conference 2021 (OSCC21)] is a good starting point.

* [[OSCC21_Suggestions|OSCC21 Audience Feature Suggestions]]

Misterblue 20220215: This effort is to invigorate and advance OpenSimulator for the most recent rediscovery of metaverses.
The goal is not to re-engineer everything to create the ultimate metaverse.
The goal is to address large features that are limiting OpenSimulator's deployment and use.
In the end, there will be a divergence from complete mimicking of SL.

There will be incorporation of technologies like:

* popular asset creation tools (mesh editors, UI designers, etc.),
* standards (identity, avatar formats, asset formats, etc.),
* modern infrastructures (containers, monitors, etc),
* encryption (end-to-end encrypted chat, signed storage, etc), and
* storage systems.

That's all grand vision, but on more practical grounds, the OSCC21 feature suggestions break into:

* Use of popular asset formats for world and avatars (FBX, GLTF, VRM, etc)
* Use of popular external asset creation tools (Blender, etc)
* Updated user documentation
* Improved in-world asset representations (trees, PBM materials, etc)
* Incorporation of hyped metaverse tech (VR, text-to-speech, etc)

And add to these operational features:

* Easy to install and operate (db management, etc)
* Better access control (connection control, user management, etc)
* Security (for inter-grid and inter-user communication)

== Standards and Metaverse Standard Groups That Might Be Interesting ==

* [https://vrm-consortium.org VRM Avatars], [https://github.com/vrm-c Github]: humanoid avatar format popular with vtubers, VRChat, etc
* [http://infinitemetaverse.com/ Infinite Metaverse Alliance]
* [https://omigroup.org/home/ Open Metaverse Interoperability Group]

Development Team

2017-04-11T18:51:48Z

Misterblue:

__NOTOC__ {{Quicklinks}}

== Active Core Developers ==

Developers who have commit access to our central server, are [http://www.ohloh.net/projects/4753/contributors regular contributors] to the codebase, and have voting rights over development and process issues of the OpenSimulator project. See [[Organization]].

* '''Only voted in developers are listed here, please do not list yourself'''

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Melanie T|Melanie_T]]
| Melanie
| Melanie Milland
| 
| +1
| Independent
| Scripting, Prims/Scene, Life, The Universe, and Everything
|-
| [[User:Diva|Diva]]
| Crista Lopes
| Diva Canto
| Crista Lopes / Diva Canto
| -8
| University of California, Irvine
| Everything, except databases
|-
| [[User:BlueWall|BlueWall]]
| James Hughes
| BlueWall Slade
| BlueWall Slade
| -5
| BlueWall Information Technologies, LLC
| Various parts
|-
| [[User:Nebadon|Nebadon]]
| Michael Emory Cerquoni
| Nebadon Izumi
| Nebadon Izumi
| -5 New Jersey
| Oni Kenkon Creations, Encitra, 4Dialog, Avacon
| Building, Scripting, Testing
|-
| misterblue
| Robert Adams
| misterblue waves
| misterblue waves
| -8 Oregon, USA
| self
| simulator devel, physics (BulletSim), protocol, alt viewers
|-
| orenh
| Oren Hurvitz
|
|
| +2
| Kitely
|
|-
| Plugh
| Kevin Cozens
| Andrew Hellershanks
| Andrew Hellershanks
| -5
| Virtual Highway
| Building, Scripting
|-
| AliciaRaven
| Alicia Richardson
| ClaudiaDLioncourt
| Alicia Raven (Spellscape)
| 0 GMT
| Spellscape Ltd http://www.spellscape.co.uk
|
|-
| Ubit
|
|
|
|
|
|
|}

 

== Core Developers Following the White Rabbit ==

Core developers who have temporarily (we hope) gone chasing the white rabbit. They are in all similar to the active core developers, except that they haven't been that active lately, so their voting rights are awaiting their come back.

* '''Only voted in developers are listed here, please do not list yourself'''

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Lbsa71|lbsa71]]
| Stefan Andersson
| Tribal Skytower
| OSG:Stefan Andersson TN:Stefan Andersson
| +1
| [http://tribalmedia.se/ Tribal Media AB]
| Web Integration
|-
| [[User:MW|MW]]
| Darren
| Wright Juran
|
| 0
|
| Everything
|-
| [[User:Adam Frisby|Adam Frisby]]
| Adam Frisby
| Adam Zaius
|
| +8
| DeepThink Pty Ltd
| Terrain, Performance
|-
| ckrinke
| Charles Krinke
| Charlesk Bing
|
| -8
|  
| Reliability/Grid servers/ll-functions
|-
| [[User:Mikem|mikem]]
| Mike Mazur
| 
| 
| +9
| Independent
| Patches, scripting improvements, LSL compiler
|-
| [[User:HomerHorwitz|homerh]]
| Homer Horwitz
| Homer Horwitz
| 
| +2
| Independent
| Rev. engineering, "now, that's funny" problems, but still interested in all parts of it
|-
| [[User:Nlin|nlin]]
| N Lin
| Standard Drucker
| 
| +9
| [http://www.3di.jp/en/ 3Di Inc, Japan] http://www.3di.jp/en/
| Physics, scripting, more to come
|-
| [[User:Arthursv|arthursv]]
| Arthur Valadares
|
| NONE
| -8
| University of California, Irvine
| Unit testing, database plugins, bug fixes, general
|-
| [[User:DrScofield|drscofld]]
| Dirk Husemann
| Dr Scofield
|
| +1
| [http://xyzzyxyzzy.net/ xyzzyxyzzy.net]
| Reliability, networking protocols, inventory, assets, remote control, voice, and pretty much everything else :-)
|
|-
| [[User:Teravus|Teravus]]
| Daniel Olivares
| Teravus Ousley
|
| -5
| W3z
| Physics & Admin tools, A working sim.
|-
| [[User:Chi11ken|chi11ken]]
| Jeff Ames
| Chillken Proto
| 
| +9
| [http://www.genkii.com Genkii]
| 
|-
| [[User:Marck|Marck00]]
| M. Kirsch
| Marck Kjeller
|
| +1
| Independent
| Everything that catches my attention and that I can get my head around.
|
|-
| [[User:Snoopy2|Snoopy2]]
| Snoopy Pfeffer
| Snoopy Pfeffer
| Snoopy Pfeffer
|
| [http://www.dreamlandmetaverse.com/ http://www.dreamlandmetaverse.com/]
| OpenSim region and grid hosting
|-
| [[User:Justincc|justincc]]
| Justin Clark-Casey
| Lulworth Beaumont
| Justin Clark-Casey (all other grids)
| 0
| OSVW Consulting [http://justincc.org/blog justincc's OpenSimulator blog]
| Grid, performance & reliability, inventory (avatar and object), assets, scenes, OARs, etc. Generally speaking, my main interest is to create infrastructure that other people can build on top of.
|-
| [[User:Dslake|dslake]]
| Dan Lake
| Dan Lake
| ScienceSim
| -8 / -7
| Intel
| Scalability, Performance, Network stack
|-
| cmickeyb
| Mic Bowman
| Mic Bowman
| ScienceSim
| -8 / -7
| Intel
|
|}

== Retired Core Developers ==

Core developers who have transcended our mortal plane, i.e. they are no longer directly engaged with the project. Thank you forever for your contributions!

* '''Only formerly voted in developers are listed here, please do not list yourself'''

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Babblefrog|babblefrog]]
| Brian McBee
| Dogen Coldstream
| Babblefrog Ballistic (osgrid)
| -8
| Disorganized
|  
|-
| [[User:Danx0r|danx0r]]
| Dan Miller
| Albert Pascal
|
| -8
| squiggle.com
| PHEEZIKS; everything
|-
| Tleiades
|  
| Tleiades Hax
|
| +1
|  
| Grid servers/Database
|-
| [[User:Darok|Darok]]
|  
| Darok Kaminski
|
| +1
|  
| Physics engines (especially BulletX)
|-
| Gareth / Gwen
| Gareth Nelson
| Gareth Ellison
| Gareth Nelson (on everywhere but SL)
| BST (UTC+1)
| Litesim Ltd
| Grid servers, sim border crossing, avatar animations
|-
| [[User:Dalien|dalien]]
| Dalien Talbot
| Dalien Talbot
|
| +1
| Mostly TCP-based
| Small fixes; rev.eng./prototyping; nightlies; git-keeper
|-
| [[Alondria]]
|
| Alondria LeFay
| Alondria LeFay (OSGrid)
| -8
| Independent
| Implementation of LSL functions and other scripting tidbits.
|-
| [[User:SeanDague|sdague]]
| Sean Dague
| Neas Bade
|
| -5
| IBM
| Database, Linux, Testing, Misc
|-
| [[User:MingChen|MingChen]]
| Mike/Michael Ortman
| Ming Chen
|
| -6 (-5 in Summer)
| DeepThink Pty Ltd
| Estate/Parcel Support/Modules/Keeping things all neat and tidy.
|-
| [[User:Tedd|Tedd]]
| Tedd Hansen
| Tedd Maa
|
| +1
| Tedd Hansen
| Programming/Scripting/Architecture
|-
| [[User:Adjohn|adjohn]]
| Adam Johnson
| Zeuz Zenovka
| 
| +9
| [http://www.genkii.com Genkii]
| 
|-
| [[User:Joha1|joha1]]
| Johan Berntsson
| Joppi Brandenburg
| 
| +9
|  
| Performance, packet handling/libSL
|-
| jhurliman
| John Hurliman
| John Hurliman
|
|
|
|
|-
| [[User:Dahlia|dahlia]]
| T. Hoff
| Dahlia Trimble
|
| -8 / -7
| Independent
| Collision geometry, various math and physics issues, occasional bug fixes and random enhancements
|-
|}

== Wiki Sysops ==

Along with the core developers, these people help manage the OpenSimulator wiki as well as make other contributions (see Areas of Interest).

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Makopoppo|Makopoppo]]
| Makiko Nomura
| Mako Nozaki
| Everywhere
| +9 Tokyo, Japan
| As an individual developer
| Everything for improving usability and connectability - wiki/issue management, documentation, localization(Japanese), modifying the interface mainly of core modules
|-
| [[User:Fritigern|Fritigern]]
| S-E-C-R-E-T
| Fritigern Gothly
| SecondLife, OSGrid
| +1 GMT
|
| My interests are many, and extremely varied. One thing that i am very interested in, is seeing OpenSimulator grow, mature, and develop into something that really does rival SL/LL.
|}

== Additional Developers/Testers/Contributors ==

These people have contributed and/or are contributing bug reports, patches, testing, and all sorts of other goodies to the project. '''Newcomers please add yourself to bottom of the list!''' 

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Jtclark48|jclark4]]
| Jay Clark
| Jay Clarke
|
| -5
| IBM
| Physics, Grid Host, AI, Scripting, Testing
|-
| [[User:AdamStevenson|BigFootAg]]
| Adam Stevenson
| Adamus Petrov
|
| -6
| Texas A&M University
| AI, Skynet, Evolving Systems, Biology
|-
| [[User:Jeff1564|Jeff1564]]
| Jeff
| Potter Taurog
| Potter Taurog
| -8
| http://myopengrid.com
| Building, Scripting, Testing
|-
| Rock_Vacirca
| Colin Withers
| Rock Vacirca
|  
| +1
| http://rock-vacirca.blogspot.com
| Testing, building, scripting, maintaining an opensim blog.
|-
| simsim
| caocao
|  
|  
| +9
|  
| Testing whole functions of OpenSimulator system,working with OpenSim-Engine,reporting on OpenSimulator
|-
| [[User:Vicero Lambert|Vicero Lambert]]
|  
|  
|
|  
|  
|  
|-
| [[User:Magi|Magi]]
| Andy Agnew
| Magi Merlin
|
| +10
| Spun Pty Ltd
| 3D Web Integration, Database stuff and playing with the odds and ends box.
|-
| [[User:ClarkZone|ClarkZone]]
| Troy Admin(@ClarkZone)
| Troy Childs
| Troy Admin (ClarkZone)
| -5
| Http://clarkzone.dyndns.org
| Tester and Grid Host
|-
| [[User:Aiaustin|aiaustin]]
| Ai Austin
| Ai Austin
| Ai Austin
| +0
| AIAI, Virtual University of Edinburgh http://www.aiai.ed.ac.uk/~ai/ http://vue.ed.ac.uk/openvue/
| Windows tests Content testing Use of multiple VWs
|-
| Marc Manders
| Marc Manders
|  
|  
| +6
| marcmanders@gmail.com
| Creative features
|-
| [[User:Balthazar|balthazar]]
| Trevor Brooks
| Balthazar Sin
|
| -5
| None
| Terrains, testing and some small coding tasks
|-
| [[User:Jimbo2120|jimbo2120]]
| Michael Osias
| Illuminous Beltran
|
| -5
| IBM
| Grid, AI, Skynet, coding and testing
|-
| ZeroPoint
|  
| Guilderoy Dench
|
| -5
|  
| Programming/Database
|-
| [[User:DerekTang|DerekTang]]
| Derek Tang
| Derek Timeless
| Derek Tang (ChineseGrid)
| +8
| http://ChineseGrid.net
| Running a public WINDOWS sim for testing, Docs, Helping Chinese users to enjoy OpenSim; building Chinese OpenSimulator communities. In construction...
|-
| [[User:TayB|TayB]]
| Earl Balai
| Taylor Dae
|
| -10
| WhynGrid
| Grid Host,Networking,Contributions & Testing.
|-
| [[User:JamieDav|JamieDav]]
| Jamie David
| Jamie David
|
| +7
| Forum
| Grid, Sim, Avitar, Functionality
|-
| [[User:Krtaylor|Krtaylor]]
| Kurt Taylor
| Kurt Stringer
|
| -6
| IBM
| Grid, Networking, Monitoring, Scripting, Inventory, Testing
|-
| [[User:Nink|Nink]]
| Peter Finn
| Nink Noonan
|
| -5
| IBM
| Disruptive Influence.
|-
| [[User:Bruce|Bruce]]
| Bruce Meerson
| Bruce Meerson
|
| +8
| HiPiHi
| Watching.
|-
| [[User:Darb|DarbD]]
| Brian B. Quinn
| Darb Dabney
| regions near Marin
| PST/SLT (-7 or -8)
| County of Marin, California http://blog.3dmap.me
| LiDAR-based sculpties, real-world terrain, pursuit of civic paraverses, virtual Emergency Operations Centers
|-
| [[User:Charlie Omega|CharlieO]]
| Dan
| Charlie Omega
|
|  
|  
| Mild coding/tweaking/simple feature adds, Stress testing/break stuff, Testing limits of existing code. Making sure [[LSL Status]] is up to date
|-
| oobscure
|  
| Opensource Obscure
|
| +1
| http://www.opensim.it
| Running a public Linux sim for testing, Docs, Helping italian users, Building opensim communities, Watching
|-
| pitman
| Mike Pitman
| Rez Tone
|
|  
| IBM
| Scientific visualization schemes, virt world product design, persistant workspaces, virt world based big biz
|-
| Shenlei
| Shenlei Winkler
| Shenlei Flasheart, Shenlei Winkler
|
|  
| Fashion Research Institute
| Product Design and Development, Apparel industry, and o yes, I wrote the book ;)
|-
| cmu
| Christopher Mumme
| Snook Destiny
|
| +1
| http://www.cmu-develop.de/ and research group "Collaboration Systems and CSCW" at Clausthal University of Technology
| Testing OpenSim, working with OpenSim-Engine, reporting on OpenSimulator
|-
| [[Silpol]]
| Andriy Tymchenko
| Andy Tir
|
| EET (+2/3)
| http://silpol.blogspot.com/ (also visible at Nokia)
| Highly uncoordinated mess with elements of palace games, under-table diplomacy, rebellion, coup d'état and mutiny. optionally pirate
|-
| [[User:Grumly|Grumly]]
|
| Forest Klaar
| Grumly TheBear
| GMT+1
| .NET MCAD Dev/Arch/Trainer http://www.devoteam.com
| Trying to get into OpenSimulator code for now. Particularly interrested in data persistence. blog (Hello, Avatar!): http://lslblog.free.fr
|-
| [[User:DaTwitch|DaTwitch]]
| James G. Stallings II
| Lazarus Longstaff
| Hiro Protagonist (OSGrid)
| -5
| House Husband
| OSGrid Region owner, OSGrid Operator, Forum Admin, sometime wiki editor
|-
| gryc
| Gryc Ueusp
| Gryc Uriza
| Gryc Uriza(OSGrid)
| -6
|
| PHP scripting, web interfaces, interconnectivity, cross-platformedness
|-
| [[User:Phrearch|Phrearch]]
| Jeroen van Veen
| Phrearch Miles
| Phrearch Miles(OSGrid)
| Amsterdam/Paris
|
| HWIOS, WiXTD, Wikidoc, Moo, User interfaces
|-
| [[User:Burnman|Burnman]]
| Allen
| Burnman Bedlam
|
| Boston, USA
|
| Testing, testing, and more testing! Getting familiar with the source, interested in all aspects of the project.
|-
| [[User:Krisbfunk|krisbfunk]]
| Kris Bulman
| Krisbfunk Vought
| Krisbfunk Nocturnal(OSGrid)
| PE, Canada (-4)
| Edactive Technologies NocturnalEye Productions UPEI
| Currently: Testing, bug reports, wiki updating, building on OSGrid
|-
| [[User:HashBox|HashBox]]
|  
| Sibariel Darkstone
| Sibariel Darkstone (OSGrid)
| New Zealand (+12)
|
| Testing, bug reports, and updating the wiki.
|-
| [[User:Kinoc|Kinoc]]
| Kino Coursey
| Daxxon Jaxxon
| Daxxon Kinoc (OSgrid)
| -6
| Daxtron Laboratories http://www.daxtron.com University of North Texas
| AI, Semantic web, Ontologies, Natural Laanguage Processing, Cyc, Bots, NPC
|-
| [[User:Trapuh|trapuh]]
| Pedro Ribeiro
| Vaiten Forder
|
| GMT
| University Student, Escola Superior de Educação de Viseu, Portugal
| Testing, eventual bug reports and wiki. Music, web/digital arts and php+sql.
|-
| [[User:SonicViz|SonicViz]]
| Paul Cohen
| Komuso Tokugawa
|
| +9
| Http://sonicviz.com
| Audio/Music, Interactive Music, Control Protocols, Interfaces, VisualFX, Procedural animation/Generative systems + testing and general dev
|-
| [[User:Mokele|mokele]]
| Scott Norman
| Mokelembembe Mokeev
|
| -8 (Southern California)
| Web Developer (PHP and MySQL)
| Interested in seeing running on PowerPC Macs which it is. So, when I can, I'll compile and test on PowerPC Mac (PowerBook G4) and submit reports and then update the wiki if need on installing on Mac. Also have a Ubuntu 7.10 server that I can do testing on too.
|-
| [[User:Devalnor|devalnor]]
| Devalnor
| M. Watkin
|
| +1 (Belgium)
|
| Small Patch code, bug reports, and updating the wiki.
|-
| [[User:Ezekiel|Ezekiel]]
| Ezekiel
| Ezekiel Zabelin
|
| +1
| http://www.yosims.com
| Concepts, business aspects of virtual worlds - web developer (PHP, MySQL, Javascript, LSL)
|-
| [[User:Buggmaster|Buggmaster]]
| Mike D
| Bug Master
| None
| -8
| http://www.adultmetaverse.com
| Grid, Data/Web PHP/PERL/MySQL
|-
| [[User:Nixnerd|nixnerd]]
|
| Dangerously Moody
| None
| GMT
| http://www.integratedtechnologies.eu
| Cross Platform Testing, Feedback, Bug Reporting
|-
| [[User:MoHax|mohax]]
| Mo Hax
| Mo Hax
|
| -5 Eastern
| IBM
| Testing, Feedback, Content Contributions, Bug Reporting, Documenting, Development
|-
| [[User:Webmage|webmage]]
| webmage
| Leyla Masala
| Web Mage
| +1
| IBM
| Testing, terrain
|-
| [[User:NLStitch|NLStitch]]
| Marijn Oosterveld
| Stitch Seale
| NYA
| GMT +1 Amsterdam
| Twingate Systems (http://www.twingate.nl) HanzeHogeschool Groningen, Netherlands
| Programming, Photography, AI
|-
| [[User:Ideia Boa|Ideia Boa]]
| Joao Lopes
| Ideia Boa
| Ideia Boa or Boa Ideia in some grids
| GTM+1 Stockholm/Sweden
| WorldSimTERRA - Virtual World that speaks Portuguese too http://www.worldsimterra.com
| Testing and more testing! Updating the original wiki and translating the OpenSimulator Wiki into Portuguese and reporting on OpenSimulator
|-
| [[User:Lulurun|lulurun]]
| liu
| 
| 
| +9
| 3Di Inc, Japan http://www.3di.jp
| Patches, openid, server performance, UGAI
|-
| [[User:Carlosroundel|Carlosrounde]]
| Carlosroundel
| Carlos Roundel
| 
| +1
| Cyberlandia Italy http://www.cyberlandia.net
| Grid, programmer, database, tester
|-
| [[User:Mikebert|Mikebert]]
| Michael Strunck
| Mikebert Miles
| Mikebert M34
| +1
| OpenSIM Wiki, Germany http://www.opensim.de
| German Wiki, Translater, Server Performance (Linux/Windows), Tester, Feedback, Bug Reporting, Server-Hosting
|-
| Taoki
| Mircea Kitsune / Taoki Vixen
| Mircea Kitsune (OSGrid) / Mircea Lobo (LL grid)
| 
| GMT +2
| 
| Usually testing and bug reporting but I also make smaller patches where I know what to do.
|-
| [[User:Patnad|Patnad]]
| Patrick
| Patnad Babii
| Patnad Babii (OSGrid)
| GMT -5
| RezzMe Technologies http://www.rezzme.com
| Bug testing and reporting, I code C# and have submitted a few patches
|-
| [[User:^DarkMan|^DarkMan]]
| Brian Adair
| Patrick Ouachita
| Brian Adair | Patrick Meta
| -6 CST
| RealMetaLife | B&H Networking
| Building, Scripting, Testing, etc.
|-
| [[User:Tlaukkan|Tommi Laukkanen]]
| Tommi Laukkanen
|  
| Tommi Laukkanen
| +2 GMT
| http://www.bubblecloud.org
| Protocols ([http://www.bubblecloud.org MXP]), NHibernate, Scrip API, Map Generation, Bug Fixes, Grid Hosting
|-
| [[User:Mystical|Mystical]]
| Kevin Tweedy
| Mystical Demina
| Mystical Demina
| -5
| Extreme Reality Grid http://www.XRGrid.com
| Windows Communication Framework, Windows Workflow,Entity Framework, MSSQL Enhancements,Commerce, Content,DotNetNuke based portal, development services
|-
| [[User:Godfrey|Godfrey]]
| Jeff Lee
| Warin Cascabel
|
| -5 (EST5EDT)
|
| Testing, minor bugfixes. Scripting, building, animating
|-
| Jamenai
| Christopher Händler
| Jamenai Luik
| Jamenai Luik
| +1
| Playneko Grid | XIMDEX Jamenai http://www.playneko.de http://www.ximdex.de
| Performance,Bug Reporting, Hosting, Grid-Owner,(PHP, MySQL, Perl, JavaScript, LSL)
|-
| [[User:Bikcmp|bikcmp]]
| Jason
| Jake1500 Allen
| Jason Helios (The Helios Grid)
| EST
| Blue Software
| Search, groups, land, and currency
|-
| [[User:Mark.malewski|Slipaway]]
| Mark Malewski
| Chris Rock
|
| -6 (-5 during summer - CDT)
| NexTECH / Joopla
| Web development & systems integration, terrain, WIKI documentation, tutorials, testing, bug reporting and feedback.
|-
| barakademi
| Steve Topp
| barakademi Barzane
| same avi on baragrid OSgrid Grid4us sciencesim
| utc+1 (CET) paris
| http://xbot-sl.barakademi.org http://vps.barakademi.org/oswi http://vps.barakademi.org/oswi/loginscreen.php
| Music LiveMusic MetaverseMusic Opensim Libomv Mono-2.4 Linux (suse,debian,ubuntu) Admin Scripting Automating Development Intergration php mysql bash nant +++
|-
| [[User:Robert d|robert_d]]
| Robert Dzikowski
|
| OSGrid: robert_d 13
| UTC+1
| [http://blog.rd-it.net http://blog.rd-it.net]
| Region Modules, Tutorials
|-
| john_
| John Moyer
| VAJohn GeekSquad or Matthew Kendal
|
| -5
| Best Buy/Geek Squad
| Tester
|-
| [[User:W!cKeD|_WicKeD]]
| Maik
| Maik Galaxy
| El Diablo
| +1 Germany
| Creatio Inc. / [http://www.OpenSimGerman.us/ OpenSimGerman.us]
| German Support, Translator, Building, Scripting, Testing, Hosting
|-
| [[User:Stevie Wakowski|Stevie Wakowksi]]
| Steve Roberts
| Stevie Wakowski
|
| +10 Australia
| IBM
| OpenSimulator builds, Linux, Modrex, bug reporting, evangalist for OpenSimulator in business applications.
|-
| Revolution
| Matthew
| Revolution Smythe
| Revolution Smythe
| -6 Central USA
| None
| Script engine, physics engine, general odd bugs, interesting and odd things
|-
| [[User:ClemsonGS|clemsonGS]]
| Brian Cass
| BC Sands
| Brian Cass (VWC Grid)
| -5
| http://www.cvwconline.org/
| Developing virtual worlds for use in higher education
|-
|
| AlexRa
|
|
|
| Independent
|
|-
|
|
| Mikko Pallari
|
|
| Realxtend
|
|-
|
| StrawberryFride
| Chris Hart
|
|
| ReactionGrid
|
|-
| [[User:RemedyTomm|RemedyTomm]]
| Tom Grimshaw
| Tomm Remedy
| KGrid: Casper Warden OSGrid: Tomm Remedy
| UTC+0 (BST)
| Remedy Communications
| Texture pipeline, Groups, ObjectUpdates
|-
|
|
| Rob Smart
|
|
| IBM
|
|-
| MicheilMerlin
| Micheil Merlin
| Micheil Merlin
| Micheil Merlin
| -6
| Independent [http://www.iliveisl.com/ http://www.iliveisl.com/]
| Scripting, patches, and testcases
|-
| Pato Donald
| Pato Donald
| Morgam Biedermann
| Pato Donald
| -3
| Independent [http://www.matheusmk3.co.cc/ http://www.matheusmk3.co.cc/
| Groups, Scripts, Physics, Communication, Integration
|-
|
| Sera Marx
| Darkfire Soulstar
|
| +12
| Radiance promotions
| Grid Host, Commissioner. ~ Anyone looking for work related to the development of Opensimulator or Viewers please contact me. Any work undertaken for me will be returned to Opensimulator unless made strictly for my Grid
|-
|[[User:dz|dz]]
| Doug Osborn
| ydoo magic
| delta zed @ OSGRID Doug Osborn @ ScienceSim & MOSES grids
| PST/SLT (-7 or -8)
| CEO OpenSimian
| Performance testing, advanced scripting, high prim count builds, Client and server side bots, Animation Overrides, MANTIS maintenance.
|-
| [[User:Hallow Palmer|Hallow Palmer]]
| Markus
| Hallow Palmer
| 
| +1
| Grid4Us http://www.grid4us.net
| Server Performance (Windows), Tester, Feedback, Business concepts,Bug Reporting, Server-Hosting
|-
| [[User:LenaVanilli|LenaVanilli]]
| Lena Vanilli
| Lena Vanilli
| Lena Vanilli
| +1 Germany
| [http://www.hypergrid.org http://www.hypergrid.org]
| Grid-Management, Testing Testing Testing, Region Hosting
|-
| [[User:Aduffy70|aduffy70]]
| Aaron Duffy
| Aeran Stipe
| Aaron Duffy @ScienceSim
| -7
| USU
| Scientific visualization & education, Region modules, Heavily scripted regions
|-
|
| Erich Bremer
| Erich Bremer
|
Erich Bremer@OSGrid

| -5
| http://www.ebremer.com
| Semantic Web, Data Visualization
|-
| [[User:MarkIDCAS|MarkIDCAS]]
| Mark Bannon
| Mark IDCAS
| 3D Grid Association, AtMeeting, Valhalla Virtual and IDCAS.
| GMT
| [http://www.valhallavirtual.com http://www.valhallavirtual.com]
| Grid Management & systems integration. Scripting. WIKI documentation, tutorials, bug reporting and feedback.
|-
| [[User:Allquixotic|allquixotic]]
| Sean McNamara
| Tiyuk Quellmalz
| OSG: Tiyuk Quellmalz
| -5
| None
| Bugfixing; networking; performance; data integrity; LSL; auto-backup; null DB (eventual consistency).
|-
| [[User:Orenh|orenh]]
| Oren Hurvitz
|
| Oren Hurvitz (Kitely)
| +2
| Kitely
|
|-
| [[User:Randomhuman|randomhuman]]
| Kevin Houlihan
| random Radikal
| random human (OSGrid)
| WET/IST
| CrimsonCookie
| RemoteAdmin module; On-demand grids; web integration.
|
|-
| [[User:Oddball Otoole|oddball otoole]]
| J.v.Hogeloon
| Oddball Otoole
| Oddball Otoole (OSGrid
| +1 (The Netherlands
| None
| Building, scripting, testing, social stuff.
|-
| [[User:Pixel|Pixel Tomsen]]
| Christian Kurzhals
| Pixel Tomsen
| Pixel Tomsen OSGrid
| +1 (Germany
| see my profil
| Dev, Building, scripting, sim-hosting, some modules, patches, osgrid
|-
| [[User:kenearlg|kenearlg]]
| Ken Grunke
| Key Grau
| Key Gruin (Osgrid)
| -6 CST
| http://www.osgrid.org/
| testing, moderating, inworld games & recreation, wiki spam control
|-
| [[User:CG4Life|CG4Life]]
| CG Anderson
| Cyn Hak
|
| -8 PST
| Little Dogs Media
| Networking, Security, Performance (parallelization, compression, encryption), physics, 3D manipulation, bugfixing, documentation. Just getting into the code base, so will start with compression/parallelizatoin ideas and bugfixing, then other stuff later.
|-
| [[User:vegaslon|vegaslon]]
| Adam Ivie
| vegaslon plutonian
|
| -5 EST
| Independent
| Physics, Vehicles, Advanced Scripting, Testing, Advanced Land Usage.
|-
| [[User:AliciaRaven|AliciaRaven]]
| Alicia Richardson
| ClaudiaDLioncourt
| Alicia Raven (Spellscape)
| 0 GMT
| Spellscape Ltd http://www.spellscape.co.uk
|
|}

== Retired Additional Developers ==

Additional developers who are no longer working on the OpenSimulator project. Thank you forever for your contributions!

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Fly-man-|Fly-Man-]]
| Laurence
|
| OSGrid: Fly Man
| GMT +1
| Private Company
| Testing, OpenSimSearch, OpenSimProfile
|-
|}

[[Category:Development]]
[[Category:Tech Reference]]
[[Category:Help]]

Development Team

2017-04-11T18:50:48Z

Misterblue: update 'misterblue' entry from 'radams'

__NOTOC__ {{Quicklinks}}

== Active Core Developers ==

Developers who have commit access to our central server, are [http://www.ohloh.net/projects/4753/contributors regular contributors] to the codebase, and have voting rights over development and process issues of the OpenSimulator project. See [[Organization]].

* '''Only voted in developers are listed here, please do not list yourself'''

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Melanie T|Melanie_T]]
| Melanie
| Melanie Milland
| 
| +1
| Independent
| Scripting, Prims/Scene, Life, The Universe, and Everything
|-
| [[User:Diva|Diva]]
| Crista Lopes
| Diva Canto
| Crista Lopes / Diva Canto
| -8
| University of California, Irvine
| Everything, except databases
|-
| [[User:BlueWall|BlueWall]]
| James Hughes
| BlueWall Slade
| BlueWall Slade
| -5
| BlueWall Information Technologies, LLC
| Various parts
|-
| [[User:Nebadon|Nebadon]]
| Michael Emory Cerquoni
| Nebadon Izumi
| Nebadon Izumi
| -5 New Jersey
| Oni Kenkon Creations, Encitra, 4Dialog, Avacon
| Building, Scripting, Testing
|-
| misterblue
| Robert Adams
| misterblue waves
| misterblue waves
| -8 Oregon, USA
| self
| simulator devel
|-
| orenh
| Oren Hurvitz
|
|
| +2
| Kitely
|
|-
| Plugh
| Kevin Cozens
| Andrew Hellershanks
| Andrew Hellershanks
| -5
| Virtual Highway
| Building, Scripting
|-
| AliciaRaven
| Alicia Richardson
| ClaudiaDLioncourt
| Alicia Raven (Spellscape)
| 0 GMT
| Spellscape Ltd http://www.spellscape.co.uk
|
|-
| Ubit
|
|
|
|
|
|
|}

 

== Core Developers Following the White Rabbit ==

Core developers who have temporarily (we hope) gone chasing the white rabbit. They are in all similar to the active core developers, except that they haven't been that active lately, so their voting rights are awaiting their come back.

* '''Only voted in developers are listed here, please do not list yourself'''

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Lbsa71|lbsa71]]
| Stefan Andersson
| Tribal Skytower
| OSG:Stefan Andersson TN:Stefan Andersson
| +1
| [http://tribalmedia.se/ Tribal Media AB]
| Web Integration
|-
| [[User:MW|MW]]
| Darren
| Wright Juran
|
| 0
|
| Everything
|-
| [[User:Adam Frisby|Adam Frisby]]
| Adam Frisby
| Adam Zaius
|
| +8
| DeepThink Pty Ltd
| Terrain, Performance
|-
| ckrinke
| Charles Krinke
| Charlesk Bing
|
| -8
|  
| Reliability/Grid servers/ll-functions
|-
| [[User:Mikem|mikem]]
| Mike Mazur
| 
| 
| +9
| Independent
| Patches, scripting improvements, LSL compiler
|-
| [[User:HomerHorwitz|homerh]]
| Homer Horwitz
| Homer Horwitz
| 
| +2
| Independent
| Rev. engineering, "now, that's funny" problems, but still interested in all parts of it
|-
| [[User:Nlin|nlin]]
| N Lin
| Standard Drucker
| 
| +9
| [http://www.3di.jp/en/ 3Di Inc, Japan] http://www.3di.jp/en/
| Physics, scripting, more to come
|-
| [[User:Arthursv|arthursv]]
| Arthur Valadares
|
| NONE
| -8
| University of California, Irvine
| Unit testing, database plugins, bug fixes, general
|-
| [[User:DrScofield|drscofld]]
| Dirk Husemann
| Dr Scofield
|
| +1
| [http://xyzzyxyzzy.net/ xyzzyxyzzy.net]
| Reliability, networking protocols, inventory, assets, remote control, voice, and pretty much everything else :-)
|
|-
| [[User:Teravus|Teravus]]
| Daniel Olivares
| Teravus Ousley
|
| -5
| W3z
| Physics & Admin tools, A working sim.
|-
| [[User:Chi11ken|chi11ken]]
| Jeff Ames
| Chillken Proto
| 
| +9
| [http://www.genkii.com Genkii]
| 
|-
| [[User:Marck|Marck00]]
| M. Kirsch
| Marck Kjeller
|
| +1
| Independent
| Everything that catches my attention and that I can get my head around.
|
|-
| [[User:Snoopy2|Snoopy2]]
| Snoopy Pfeffer
| Snoopy Pfeffer
| Snoopy Pfeffer
|
| [http://www.dreamlandmetaverse.com/ http://www.dreamlandmetaverse.com/]
| OpenSim region and grid hosting
|-
| [[User:Justincc|justincc]]
| Justin Clark-Casey
| Lulworth Beaumont
| Justin Clark-Casey (all other grids)
| 0
| OSVW Consulting [http://justincc.org/blog justincc's OpenSimulator blog]
| Grid, performance & reliability, inventory (avatar and object), assets, scenes, OARs, etc. Generally speaking, my main interest is to create infrastructure that other people can build on top of.
|-
| [[User:Dslake|dslake]]
| Dan Lake
| Dan Lake
| ScienceSim
| -8 / -7
| Intel
| Scalability, Performance, Network stack
|-
| cmickeyb
| Mic Bowman
| Mic Bowman
| ScienceSim
| -8 / -7
| Intel
|
|}

== Retired Core Developers ==

Core developers who have transcended our mortal plane, i.e. they are no longer directly engaged with the project. Thank you forever for your contributions!

* '''Only formerly voted in developers are listed here, please do not list yourself'''

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Babblefrog|babblefrog]]
| Brian McBee
| Dogen Coldstream
| Babblefrog Ballistic (osgrid)
| -8
| Disorganized
|  
|-
| [[User:Danx0r|danx0r]]
| Dan Miller
| Albert Pascal
|
| -8
| squiggle.com
| PHEEZIKS; everything
|-
| Tleiades
|  
| Tleiades Hax
|
| +1
|  
| Grid servers/Database
|-
| [[User:Darok|Darok]]
|  
| Darok Kaminski
|
| +1
|  
| Physics engines (especially BulletX)
|-
| Gareth / Gwen
| Gareth Nelson
| Gareth Ellison
| Gareth Nelson (on everywhere but SL)
| BST (UTC+1)
| Litesim Ltd
| Grid servers, sim border crossing, avatar animations
|-
| [[User:Dalien|dalien]]
| Dalien Talbot
| Dalien Talbot
|
| +1
| Mostly TCP-based
| Small fixes; rev.eng./prototyping; nightlies; git-keeper
|-
| [[Alondria]]
|
| Alondria LeFay
| Alondria LeFay (OSGrid)
| -8
| Independent
| Implementation of LSL functions and other scripting tidbits.
|-
| [[User:SeanDague|sdague]]
| Sean Dague
| Neas Bade
|
| -5
| IBM
| Database, Linux, Testing, Misc
|-
| [[User:MingChen|MingChen]]
| Mike/Michael Ortman
| Ming Chen
|
| -6 (-5 in Summer)
| DeepThink Pty Ltd
| Estate/Parcel Support/Modules/Keeping things all neat and tidy.
|-
| [[User:Tedd|Tedd]]
| Tedd Hansen
| Tedd Maa
|
| +1
| Tedd Hansen
| Programming/Scripting/Architecture
|-
| [[User:Adjohn|adjohn]]
| Adam Johnson
| Zeuz Zenovka
| 
| +9
| [http://www.genkii.com Genkii]
| 
|-
| [[User:Joha1|joha1]]
| Johan Berntsson
| Joppi Brandenburg
| 
| +9
|  
| Performance, packet handling/libSL
|-
| jhurliman
| John Hurliman
| John Hurliman
|
|
|
|
|-
| [[User:Dahlia|dahlia]]
| T. Hoff
| Dahlia Trimble
|
| -8 / -7
| Independent
| Collision geometry, various math and physics issues, occasional bug fixes and random enhancements
|-
|}

== Wiki Sysops ==

Along with the core developers, these people help manage the OpenSimulator wiki as well as make other contributions (see Areas of Interest).

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Makopoppo|Makopoppo]]
| Makiko Nomura
| Mako Nozaki
| Everywhere
| +9 Tokyo, Japan
| As an individual developer
| Everything for improving usability and connectability - wiki/issue management, documentation, localization(Japanese), modifying the interface mainly of core modules
|-
| [[User:Fritigern|Fritigern]]
| S-E-C-R-E-T
| Fritigern Gothly
| SecondLife, OSGrid
| +1 GMT
|
| My interests are many, and extremely varied. One thing that i am very interested in, is seeing OpenSimulator grow, mature, and develop into something that really does rival SL/LL.
|}

== Additional Developers/Testers/Contributors ==

These people have contributed and/or are contributing bug reports, patches, testing, and all sorts of other goodies to the project. '''Newcomers please add yourself to bottom of the list!''' 

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Jtclark48|jclark4]]
| Jay Clark
| Jay Clarke
|
| -5
| IBM
| Physics, Grid Host, AI, Scripting, Testing
|-
| [[User:AdamStevenson|BigFootAg]]
| Adam Stevenson
| Adamus Petrov
|
| -6
| Texas A&M University
| AI, Skynet, Evolving Systems, Biology
|-
| [[User:Jeff1564|Jeff1564]]
| Jeff
| Potter Taurog
| Potter Taurog
| -8
| http://myopengrid.com
| Building, Scripting, Testing
|-
| Rock_Vacirca
| Colin Withers
| Rock Vacirca
|  
| +1
| http://rock-vacirca.blogspot.com
| Testing, building, scripting, maintaining an opensim blog.
|-
| simsim
| caocao
|  
|  
| +9
|  
| Testing whole functions of OpenSimulator system,working with OpenSim-Engine,reporting on OpenSimulator
|-
| [[User:Vicero Lambert|Vicero Lambert]]
|  
|  
|
|  
|  
|  
|-
| [[User:Magi|Magi]]
| Andy Agnew
| Magi Merlin
|
| +10
| Spun Pty Ltd
| 3D Web Integration, Database stuff and playing with the odds and ends box.
|-
| [[User:ClarkZone|ClarkZone]]
| Troy Admin(@ClarkZone)
| Troy Childs
| Troy Admin (ClarkZone)
| -5
| Http://clarkzone.dyndns.org
| Tester and Grid Host
|-
| [[User:Aiaustin|aiaustin]]
| Ai Austin
| Ai Austin
| Ai Austin
| +0
| AIAI, Virtual University of Edinburgh http://www.aiai.ed.ac.uk/~ai/ http://vue.ed.ac.uk/openvue/
| Windows tests Content testing Use of multiple VWs
|-
| Marc Manders
| Marc Manders
|  
|  
| +6
| marcmanders@gmail.com
| Creative features
|-
| [[User:Balthazar|balthazar]]
| Trevor Brooks
| Balthazar Sin
|
| -5
| None
| Terrains, testing and some small coding tasks
|-
| [[User:Jimbo2120|jimbo2120]]
| Michael Osias
| Illuminous Beltran
|
| -5
| IBM
| Grid, AI, Skynet, coding and testing
|-
| ZeroPoint
|  
| Guilderoy Dench
|
| -5
|  
| Programming/Database
|-
| [[User:DerekTang|DerekTang]]
| Derek Tang
| Derek Timeless
| Derek Tang (ChineseGrid)
| +8
| http://ChineseGrid.net
| Running a public WINDOWS sim for testing, Docs, Helping Chinese users to enjoy OpenSim; building Chinese OpenSimulator communities. In construction...
|-
| [[User:TayB|TayB]]
| Earl Balai
| Taylor Dae
|
| -10
| WhynGrid
| Grid Host,Networking,Contributions & Testing.
|-
| [[User:JamieDav|JamieDav]]
| Jamie David
| Jamie David
|
| +7
| Forum
| Grid, Sim, Avitar, Functionality
|-
| [[User:Krtaylor|Krtaylor]]
| Kurt Taylor
| Kurt Stringer
|
| -6
| IBM
| Grid, Networking, Monitoring, Scripting, Inventory, Testing
|-
| [[User:Nink|Nink]]
| Peter Finn
| Nink Noonan
|
| -5
| IBM
| Disruptive Influence.
|-
| [[User:Bruce|Bruce]]
| Bruce Meerson
| Bruce Meerson
|
| +8
| HiPiHi
| Watching.
|-
| [[User:Darb|DarbD]]
| Brian B. Quinn
| Darb Dabney
| regions near Marin
| PST/SLT (-7 or -8)
| County of Marin, California http://blog.3dmap.me
| LiDAR-based sculpties, real-world terrain, pursuit of civic paraverses, virtual Emergency Operations Centers
|-
| [[User:Charlie Omega|CharlieO]]
| Dan
| Charlie Omega
|
|  
|  
| Mild coding/tweaking/simple feature adds, Stress testing/break stuff, Testing limits of existing code. Making sure [[LSL Status]] is up to date
|-
| oobscure
|  
| Opensource Obscure
|
| +1
| http://www.opensim.it
| Running a public Linux sim for testing, Docs, Helping italian users, Building opensim communities, Watching
|-
| pitman
| Mike Pitman
| Rez Tone
|
|  
| IBM
| Scientific visualization schemes, virt world product design, persistant workspaces, virt world based big biz
|-
| Shenlei
| Shenlei Winkler
| Shenlei Flasheart, Shenlei Winkler
|
|  
| Fashion Research Institute
| Product Design and Development, Apparel industry, and o yes, I wrote the book ;)
|-
| cmu
| Christopher Mumme
| Snook Destiny
|
| +1
| http://www.cmu-develop.de/ and research group "Collaboration Systems and CSCW" at Clausthal University of Technology
| Testing OpenSim, working with OpenSim-Engine, reporting on OpenSimulator
|-
| [[Silpol]]
| Andriy Tymchenko
| Andy Tir
|
| EET (+2/3)
| http://silpol.blogspot.com/ (also visible at Nokia)
| Highly uncoordinated mess with elements of palace games, under-table diplomacy, rebellion, coup d'état and mutiny. optionally pirate
|-
| [[User:Grumly|Grumly]]
|
| Forest Klaar
| Grumly TheBear
| GMT+1
| .NET MCAD Dev/Arch/Trainer http://www.devoteam.com
| Trying to get into OpenSimulator code for now. Particularly interrested in data persistence. blog (Hello, Avatar!): http://lslblog.free.fr
|-
| [[User:DaTwitch|DaTwitch]]
| James G. Stallings II
| Lazarus Longstaff
| Hiro Protagonist (OSGrid)
| -5
| House Husband
| OSGrid Region owner, OSGrid Operator, Forum Admin, sometime wiki editor
|-
| gryc
| Gryc Ueusp
| Gryc Uriza
| Gryc Uriza(OSGrid)
| -6
|
| PHP scripting, web interfaces, interconnectivity, cross-platformedness
|-
| [[User:Phrearch|Phrearch]]
| Jeroen van Veen
| Phrearch Miles
| Phrearch Miles(OSGrid)
| Amsterdam/Paris
|
| HWIOS, WiXTD, Wikidoc, Moo, User interfaces
|-
| [[User:Burnman|Burnman]]
| Allen
| Burnman Bedlam
|
| Boston, USA
|
| Testing, testing, and more testing! Getting familiar with the source, interested in all aspects of the project.
|-
| [[User:Krisbfunk|krisbfunk]]
| Kris Bulman
| Krisbfunk Vought
| Krisbfunk Nocturnal(OSGrid)
| PE, Canada (-4)
| Edactive Technologies NocturnalEye Productions UPEI
| Currently: Testing, bug reports, wiki updating, building on OSGrid
|-
| [[User:HashBox|HashBox]]
|  
| Sibariel Darkstone
| Sibariel Darkstone (OSGrid)
| New Zealand (+12)
|
| Testing, bug reports, and updating the wiki.
|-
| [[User:Kinoc|Kinoc]]
| Kino Coursey
| Daxxon Jaxxon
| Daxxon Kinoc (OSgrid)
| -6
| Daxtron Laboratories http://www.daxtron.com University of North Texas
| AI, Semantic web, Ontologies, Natural Laanguage Processing, Cyc, Bots, NPC
|-
| [[User:Trapuh|trapuh]]
| Pedro Ribeiro
| Vaiten Forder
|
| GMT
| University Student, Escola Superior de Educação de Viseu, Portugal
| Testing, eventual bug reports and wiki. Music, web/digital arts and php+sql.
|-
| [[User:SonicViz|SonicViz]]
| Paul Cohen
| Komuso Tokugawa
|
| +9
| Http://sonicviz.com
| Audio/Music, Interactive Music, Control Protocols, Interfaces, VisualFX, Procedural animation/Generative systems + testing and general dev
|-
| [[User:Mokele|mokele]]
| Scott Norman
| Mokelembembe Mokeev
|
| -8 (Southern California)
| Web Developer (PHP and MySQL)
| Interested in seeing running on PowerPC Macs which it is. So, when I can, I'll compile and test on PowerPC Mac (PowerBook G4) and submit reports and then update the wiki if need on installing on Mac. Also have a Ubuntu 7.10 server that I can do testing on too.
|-
| [[User:Devalnor|devalnor]]
| Devalnor
| M. Watkin
|
| +1 (Belgium)
|
| Small Patch code, bug reports, and updating the wiki.
|-
| [[User:Ezekiel|Ezekiel]]
| Ezekiel
| Ezekiel Zabelin
|
| +1
| http://www.yosims.com
| Concepts, business aspects of virtual worlds - web developer (PHP, MySQL, Javascript, LSL)
|-
| [[User:Buggmaster|Buggmaster]]
| Mike D
| Bug Master
| None
| -8
| http://www.adultmetaverse.com
| Grid, Data/Web PHP/PERL/MySQL
|-
| [[User:Nixnerd|nixnerd]]
|
| Dangerously Moody
| None
| GMT
| http://www.integratedtechnologies.eu
| Cross Platform Testing, Feedback, Bug Reporting
|-
| [[User:MoHax|mohax]]
| Mo Hax
| Mo Hax
|
| -5 Eastern
| IBM
| Testing, Feedback, Content Contributions, Bug Reporting, Documenting, Development
|-
| [[User:Webmage|webmage]]
| webmage
| Leyla Masala
| Web Mage
| +1
| IBM
| Testing, terrain
|-
| [[User:NLStitch|NLStitch]]
| Marijn Oosterveld
| Stitch Seale
| NYA
| GMT +1 Amsterdam
| Twingate Systems (http://www.twingate.nl) HanzeHogeschool Groningen, Netherlands
| Programming, Photography, AI
|-
| [[User:Ideia Boa|Ideia Boa]]
| Joao Lopes
| Ideia Boa
| Ideia Boa or Boa Ideia in some grids
| GTM+1 Stockholm/Sweden
| WorldSimTERRA - Virtual World that speaks Portuguese too http://www.worldsimterra.com
| Testing and more testing! Updating the original wiki and translating the OpenSimulator Wiki into Portuguese and reporting on OpenSimulator
|-
| [[User:Lulurun|lulurun]]
| liu
| 
| 
| +9
| 3Di Inc, Japan http://www.3di.jp
| Patches, openid, server performance, UGAI
|-
| [[User:Carlosroundel|Carlosrounde]]
| Carlosroundel
| Carlos Roundel
| 
| +1
| Cyberlandia Italy http://www.cyberlandia.net
| Grid, programmer, database, tester
|-
| [[User:Mikebert|Mikebert]]
| Michael Strunck
| Mikebert Miles
| Mikebert M34
| +1
| OpenSIM Wiki, Germany http://www.opensim.de
| German Wiki, Translater, Server Performance (Linux/Windows), Tester, Feedback, Bug Reporting, Server-Hosting
|-
| Taoki
| Mircea Kitsune / Taoki Vixen
| Mircea Kitsune (OSGrid) / Mircea Lobo (LL grid)
| 
| GMT +2
| 
| Usually testing and bug reporting but I also make smaller patches where I know what to do.
|-
| [[User:Patnad|Patnad]]
| Patrick
| Patnad Babii
| Patnad Babii (OSGrid)
| GMT -5
| RezzMe Technologies http://www.rezzme.com
| Bug testing and reporting, I code C# and have submitted a few patches
|-
| [[User:^DarkMan|^DarkMan]]
| Brian Adair
| Patrick Ouachita
| Brian Adair | Patrick Meta
| -6 CST
| RealMetaLife | B&H Networking
| Building, Scripting, Testing, etc.
|-
| [[User:Tlaukkan|Tommi Laukkanen]]
| Tommi Laukkanen
|  
| Tommi Laukkanen
| +2 GMT
| http://www.bubblecloud.org
| Protocols ([http://www.bubblecloud.org MXP]), NHibernate, Scrip API, Map Generation, Bug Fixes, Grid Hosting
|-
| [[User:Mystical|Mystical]]
| Kevin Tweedy
| Mystical Demina
| Mystical Demina
| -5
| Extreme Reality Grid http://www.XRGrid.com
| Windows Communication Framework, Windows Workflow,Entity Framework, MSSQL Enhancements,Commerce, Content,DotNetNuke based portal, development services
|-
| [[User:Godfrey|Godfrey]]
| Jeff Lee
| Warin Cascabel
|
| -5 (EST5EDT)
|
| Testing, minor bugfixes. Scripting, building, animating
|-
| Jamenai
| Christopher Händler
| Jamenai Luik
| Jamenai Luik
| +1
| Playneko Grid | XIMDEX Jamenai http://www.playneko.de http://www.ximdex.de
| Performance,Bug Reporting, Hosting, Grid-Owner,(PHP, MySQL, Perl, JavaScript, LSL)
|-
| [[User:Bikcmp|bikcmp]]
| Jason
| Jake1500 Allen
| Jason Helios (The Helios Grid)
| EST
| Blue Software
| Search, groups, land, and currency
|-
| [[User:Mark.malewski|Slipaway]]
| Mark Malewski
| Chris Rock
|
| -6 (-5 during summer - CDT)
| NexTECH / Joopla
| Web development & systems integration, terrain, WIKI documentation, tutorials, testing, bug reporting and feedback.
|-
| barakademi
| Steve Topp
| barakademi Barzane
| same avi on baragrid OSgrid Grid4us sciencesim
| utc+1 (CET) paris
| http://xbot-sl.barakademi.org http://vps.barakademi.org/oswi http://vps.barakademi.org/oswi/loginscreen.php
| Music LiveMusic MetaverseMusic Opensim Libomv Mono-2.4 Linux (suse,debian,ubuntu) Admin Scripting Automating Development Intergration php mysql bash nant +++
|-
| [[User:Robert d|robert_d]]
| Robert Dzikowski
|
| OSGrid: robert_d 13
| UTC+1
| [http://blog.rd-it.net http://blog.rd-it.net]
| Region Modules, Tutorials
|-
| john_
| John Moyer
| VAJohn GeekSquad or Matthew Kendal
|
| -5
| Best Buy/Geek Squad
| Tester
|-
| [[User:W!cKeD|_WicKeD]]
| Maik
| Maik Galaxy
| El Diablo
| +1 Germany
| Creatio Inc. / [http://www.OpenSimGerman.us/ OpenSimGerman.us]
| German Support, Translator, Building, Scripting, Testing, Hosting
|-
| [[User:Stevie Wakowski|Stevie Wakowksi]]
| Steve Roberts
| Stevie Wakowski
|
| +10 Australia
| IBM
| OpenSimulator builds, Linux, Modrex, bug reporting, evangalist for OpenSimulator in business applications.
|-
| Revolution
| Matthew
| Revolution Smythe
| Revolution Smythe
| -6 Central USA
| None
| Script engine, physics engine, general odd bugs, interesting and odd things
|-
| [[User:ClemsonGS|clemsonGS]]
| Brian Cass
| BC Sands
| Brian Cass (VWC Grid)
| -5
| http://www.cvwconline.org/
| Developing virtual worlds for use in higher education
|-
|
| AlexRa
|
|
|
| Independent
|
|-
|
|
| Mikko Pallari
|
|
| Realxtend
|
|-
|
| StrawberryFride
| Chris Hart
|
|
| ReactionGrid
|
|-
| [[User:RemedyTomm|RemedyTomm]]
| Tom Grimshaw
| Tomm Remedy
| KGrid: Casper Warden OSGrid: Tomm Remedy
| UTC+0 (BST)
| Remedy Communications
| Texture pipeline, Groups, ObjectUpdates
|-
|
|
| Rob Smart
|
|
| IBM
|
|-
| MicheilMerlin
| Micheil Merlin
| Micheil Merlin
| Micheil Merlin
| -6
| Independent [http://www.iliveisl.com/ http://www.iliveisl.com/]
| Scripting, patches, and testcases
|-
| Pato Donald
| Pato Donald
| Morgam Biedermann
| Pato Donald
| -3
| Independent [http://www.matheusmk3.co.cc/ http://www.matheusmk3.co.cc/
| Groups, Scripts, Physics, Communication, Integration
|-
|
| Sera Marx
| Darkfire Soulstar
|
| +12
| Radiance promotions
| Grid Host, Commissioner. ~ Anyone looking for work related to the development of Opensimulator or Viewers please contact me. Any work undertaken for me will be returned to Opensimulator unless made strictly for my Grid
|-
|[[User:dz|dz]]
| Doug Osborn
| ydoo magic
| delta zed @ OSGRID Doug Osborn @ ScienceSim & MOSES grids
| PST/SLT (-7 or -8)
| CEO OpenSimian
| Performance testing, advanced scripting, high prim count builds, Client and server side bots, Animation Overrides, MANTIS maintenance.
|-
| [[User:Hallow Palmer|Hallow Palmer]]
| Markus
| Hallow Palmer
| 
| +1
| Grid4Us http://www.grid4us.net
| Server Performance (Windows), Tester, Feedback, Business concepts,Bug Reporting, Server-Hosting
|-
| [[User:LenaVanilli|LenaVanilli]]
| Lena Vanilli
| Lena Vanilli
| Lena Vanilli
| +1 Germany
| [http://www.hypergrid.org http://www.hypergrid.org]
| Grid-Management, Testing Testing Testing, Region Hosting
|-
| [[User:Aduffy70|aduffy70]]
| Aaron Duffy
| Aeran Stipe
| Aaron Duffy @ScienceSim
| -7
| USU
| Scientific visualization & education, Region modules, Heavily scripted regions
|-
|
| Erich Bremer
| Erich Bremer
|
Erich Bremer@OSGrid

| -5
| http://www.ebremer.com
| Semantic Web, Data Visualization
|-
| [[User:MarkIDCAS|MarkIDCAS]]
| Mark Bannon
| Mark IDCAS
| 3D Grid Association, AtMeeting, Valhalla Virtual and IDCAS.
| GMT
| [http://www.valhallavirtual.com http://www.valhallavirtual.com]
| Grid Management & systems integration. Scripting. WIKI documentation, tutorials, bug reporting and feedback.
|-
| [[User:Allquixotic|allquixotic]]
| Sean McNamara
| Tiyuk Quellmalz
| OSG: Tiyuk Quellmalz
| -5
| None
| Bugfixing; networking; performance; data integrity; LSL; auto-backup; null DB (eventual consistency).
|-
| [[User:Orenh|orenh]]
| Oren Hurvitz
|
| Oren Hurvitz (Kitely)
| +2
| Kitely
|
|-
| [[User:Randomhuman|randomhuman]]
| Kevin Houlihan
| random Radikal
| random human (OSGrid)
| WET/IST
| CrimsonCookie
| RemoteAdmin module; On-demand grids; web integration.
|
|-
| [[User:Oddball Otoole|oddball otoole]]
| J.v.Hogeloon
| Oddball Otoole
| Oddball Otoole (OSGrid
| +1 (The Netherlands
| None
| Building, scripting, testing, social stuff.
|-
| [[User:Pixel|Pixel Tomsen]]
| Christian Kurzhals
| Pixel Tomsen
| Pixel Tomsen OSGrid
| +1 (Germany
| see my profil
| Dev, Building, scripting, sim-hosting, some modules, patches, osgrid
|-
| [[User:kenearlg|kenearlg]]
| Ken Grunke
| Key Grau
| Key Gruin (Osgrid)
| -6 CST
| http://www.osgrid.org/
| testing, moderating, inworld games & recreation, wiki spam control
|-
| [[User:CG4Life|CG4Life]]
| CG Anderson
| Cyn Hak
|
| -8 PST
| Little Dogs Media
| Networking, Security, Performance (parallelization, compression, encryption), physics, 3D manipulation, bugfixing, documentation. Just getting into the code base, so will start with compression/parallelizatoin ideas and bugfixing, then other stuff later.
|-
| [[User:vegaslon|vegaslon]]
| Adam Ivie
| vegaslon plutonian
|
| -5 EST
| Independent
| Physics, Vehicles, Advanced Scripting, Testing, Advanced Land Usage.
|-
| [[User:AliciaRaven|AliciaRaven]]
| Alicia Richardson
| ClaudiaDLioncourt
| Alicia Raven (Spellscape)
| 0 GMT
| Spellscape Ltd http://www.spellscape.co.uk
|
|}

== Retired Additional Developers ==

Additional developers who are no longer working on the OpenSimulator project. Thank you forever for your contributions!

{| cellspacing="0" cellpadding="2" border="1" class="sortable"
|-
! IRC Nick
! Name
! SL Avatar
! Other Grid
! Time Zone (UTC)
! Org
! Areas of Interest
|-
| [[User:Fly-man-|Fly-Man-]]
| Laurence
|
| OSGrid: Fly Man
| GMT +1
| Private Company
| Testing, OpenSimSearch, OpenSimProfile
|-
|}

[[Category:Development]]
[[Category:Tech Reference]]
[[Category:Help]]

0.9 Bug List

2016-06-23T17:39:34Z

Misterblue:

Count down to 0.9 release

Generic bugs:
* Check [http://opensimulator.org/mantis/view.php?id=7908 HG TP problems with newer version of mono] (maybe a different root cause?)
* Check [http://opensimulator.org/mantis/view.php?id=7872 CHANGED_OWNER is not triggered on rez after changing object's ownership] Problem with CHANGED (i have not tested myself)
* Check [http://opensimulator.org/mantis/view.php?id=7848 Timestamps and potential wrong use by groups v2 core module of Unix timestamps in OpenSim MySql databases] (ongoing bug)
* Check [http://opensimulator.org/mantis/view.php?id=7904 Long delays when accessing task inventory] (ongoing bug, low priority)
* (WIP) Check [http://opensimulator.org/mantis/view.php?id=7910 Setting PRIM_FLEXIBLE with llSetPrimitiveParams corrupts PRIM_TYPE] related to [http://opensimulator.org/mantis/view.php?id=7896 this] has patch incl
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7932 llRezObject with vel] (ongoing bug)</strike> (not a bug)
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7929 Deeding full perm object to group makes it not available for sale] (ongoing bug)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7861 llEdgeOfWorld fails most of the time in a 1x1 region] also an issue in varregions. [http://opensimulator.org/mantis/view.php?id=7860 Here] (ongoing bug)</strike>

Regressions (worked in 0.8.2 but doesn't work in 0.9 dev):
* Check [http://opensimulator.org/mantis/view.php?id=7819 volume detect and collisions do not work proprely]
* Check [http://opensimulator.org/mantis/view.php?id=7836 Next owner permissions are not able to be set in inventory] Should work either way: on rezzed object or from inventory
* Check [http://opensimulator.org/mantis/view.php?id=7933 UserTitle is not working] (regression)
* Check [http://opensimulator.org/mantis/view.php?id=7934 Telehubs and grid gods/ region owners] (regression)
* Check [http://opensimulator.org/mantis/view.php?id=7935 Assets not being transferred on HG TPs] (regression)
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7928 show grid size reporting 0 km squared] This works in 0.8 but fails in 0.9 (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7858 llDie() leaves prim in region] Seems the prims are deleted but the viewer isn't getting updated. (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7874 Parcel properties don't take effect when entering parcel] should be an easy fix, solution in mantis. (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7915 Objects are not set to the group, when they are rezzed or created] Noticed this and also some llDetectedGroup issues (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7923 Edit particle beam is missing again] (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7917 PrimLimitsModule does not work correctly after selling land] Previously worked fine on 0.8.x (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7920 Joined group does not display in viewer until after a relog] More group issues. another update issue? (regression)</strike>

0.9 Bug List

2016-06-23T17:39:04Z

Misterblue: add #7819

Count down to 0.9 release

Generic bugs:
* Check [http://opensimulator.org/mantis/view.php?id=7908 HG TP problems with newer version of mono] (maybe a different root cause?)
* Check [http://opensimulator.org/mantis/view.php?id=7872 CHANGED_OWNER is not triggered on rez after changing object's ownership] Problem with CHANGED (i have not tested myself)
* Check [http://opensimulator.org/mantis/view.php?id=7848 Timestamps and potential wrong use by groups v2 core module of Unix timestamps in OpenSim MySql databases] (ongoing bug)
* Check [http://opensimulator.org/mantis/view.php?id=7904 Long delays when accessing task inventory] (ongoing bug, low priority)
* (WIP) Check [http://opensimulator.org/mantis/view.php?id=7910 Setting PRIM_FLEXIBLE with llSetPrimitiveParams corrupts PRIM_TYPE] related to [http://opensimulator.org/mantis/view.php?id=7896 this] has patch incl
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7932 llRezObject with vel] (ongoing bug)</strike> (not a bug)
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7929 Deeding full perm object to group makes it not available for sale] (ongoing bug)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7861 llEdgeOfWorld fails most of the time in a 1x1 region] also an issue in varregions. [http://opensimulator.org/mantis/view.php?id=7860 Here] (ongoing bug)</strike>

Regressions (worked in 0.8.2 but doesn't work in 0.9 dev):
* Check http://opensimulator.org/mantis/view.php?id=7819 volume detect and collisions do not work proprely]
* Check [http://opensimulator.org/mantis/view.php?id=7836 Next owner permissions are not able to be set in inventory] Should work either way: on rezzed object or from inventory
* Check [http://opensimulator.org/mantis/view.php?id=7933 UserTitle is not working] (regression)
* Check [http://opensimulator.org/mantis/view.php?id=7934 Telehubs and grid gods/ region owners] (regression)
* Check [http://opensimulator.org/mantis/view.php?id=7935 Assets not being transferred on HG TPs] (regression)
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7928 show grid size reporting 0 km squared] This works in 0.8 but fails in 0.9 (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7858 llDie() leaves prim in region] Seems the prims are deleted but the viewer isn't getting updated. (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7874 Parcel properties don't take effect when entering parcel] should be an easy fix, solution in mantis. (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7915 Objects are not set to the group, when they are rezzed or created] Noticed this and also some llDetectedGroup issues (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7923 Edit particle beam is missing again] (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7917 PrimLimitsModule does not work correctly after selling land] Previously worked fine on 0.8.x (regression)</strike>
* <strike>Check [http://opensimulator.org/mantis/view.php?id=7920 Joined group does not display in viewer until after a relog] More group issues. another update issue? (regression)</strike>

Monitoring Module

2016-06-21T21:25:25Z

Misterblue: Add note about this module being deprecated with a pointer to the pages for the newer interfaces.

{{Quicklinks}}

=Introduction=

This facility provides a way to retrieve data per region.

NOTE: This feature is deprecated and may be removed in future versions of the simulator. Refer to [[Monitoring]] for information on the current monitoring interfaces.

= Enabling =

In OpenSimulator 0.7.2 it is always active. In current development code it is active by default but can be disabled by setting

[Monitoring]
Enabled = false

= Retrieving data =
== OpenSimulator 0.7.2 and earlier ==
In OpenSimulator 0.7.2 and earlier, each region will register a URL on the built-in OpenSimulator HTTP server with the format

/monitorstats/<region-uuid>

If you type

show http-handlers

on the region console you'll see something like this in the HTTP section

/monitorstats/dd5b77f8-bf88-45ac-aace-35bd76426c81
/SStats/
/CAPS/VS/
regionImagedd5b77f8bf8845acaace35bd76426c81
/monitorstats/dd5b77f8-bf88-45ac-aace-35bd76426c82
regionImagedd5b77f8bf8845acaace35bd76426c82

where the UUID following monitorstats corresponds to the region ID.

== OpenSimulator development code ==
In OpenSimulator development code, the region data can also be accessed via region name. Therefore, typing

show http-handlers

will return something like

/monitorstats/dd5b77f8-bf88-45ac-aace-35bd76426c81
/monitorstats/test
/SStats/
/CAPS/VS/
regionImagedd5b77f8bf8845acaace35bd76426c81
/monitorstats/dd5b77f8-bf88-45ac-aace-35bd76426c82
/monitorstats/test2
regionImagedd5b77f8bf8845acaace35bd76426c82

where the data can also be retrieved via region name (test and test2).

= Retrieved data =

== General ==

{| border="1"
! Stat name !! Descriptoin
|-
| AgentCountMonitor || Number of avatars in the region.
|-
| ChildAgentCountMonitor || Number of child agents in the region. These are used by viewers with avatars in neighbouring regions in order to see into and effect the neighbouring region.
|-
| GCMemoryMonitor || Amount of memory currently allocated to the virtual machine garbage collector.
|-
| ObjectCountMonitor || Number of prims in the region.
|-
| PWSMemoryMonitor || Virtual Machine Private Working Set memory
|-
| ThreadCountMonitor || Number of threads used by the current process. May be unimplemented (hence always zero) on Mono.
|-
| TotalFrameMonitor || Time taken in milliseconds for the last frame. In OpenSimulator 0.7.3.1 and before this did not include the spare frame time. In later versions of OpenSimulator this does include the spare frame time.
|-
| EventFrameMonitor || Event processing time in milliseconds for the last frame.
|-
| LandFrameMonitor || Land related processing time in milliseconds for the last frame.
|-
| LastFrameTimeMonitor || The number of milliseconds since the last region frame was completed.
|-
| TimeDilationMonitor || Time dilation of physics processing compared to main scene processing.
|-
| SimFPSMonitor || Frames per second processed by the scene.
|-
| AgentUpdatesPerSecondMonitor || Updates sent to viewers per second.
|-
| ActiveObjectCountMonitor || Objects subject to physics.
|-
| ActiveScriptsMonitor || Scripts running in the region
|-
| ScriptEventsPerSecondMonitor || Script events processed per second.
|-
| InPacketsPerSecondMonitor || UDP packets from viewers processed per second.
|-
| OutPacketsPerSecondMonitor || UDP packets sent to viewers per second
|-
| UnackedBytesMonitor || Bytes that haven't yet been acked by viewers. A persistent high number indicates poor network connections between the viewers and the simulator.
|-
| PendingDownloadsMonitor || Downloads pending from simulator to viewers. Not currently implemented, will always be zero.
|-
| PendingUploadsMonitor || Pending uploads from viewers to simulator. Not currently implemented, will always be zero.
|-
| TotalFrameTimeMonitor || Average time taken in milliseconds for frames in the last 3 seconds. In OpenSimulator 0.7.3.1 and before this did not include the spare frame time and wrongly referred to the total amount of a second that constituted non-spare frame time. In later versions of OpenSimulator this correctly refers to the frame time and includes the spare frame time.
|-
| NetFrameTimeMonitor || Average time taken in milliseconds for network activities in frames in the last 3 seconds. Not currently used.
|-
| SimulationFrameTimeMonitor || Average time taken in milliseconds for frame-related simulation activity in the last 3 seconds. In OpenSimulator 0.7.3.1 and before this wrongly referred to the total amount of a second that constituted simulation time.
|-
| AgentFrameTimeMonitor || Average time taken in milliseconds for agent-related activity in the last 3 seconds. In OpenSimulator 0.7.3.1 and before this wrongly referred to the total amount of a second that constituted agent time.
|-
| ImagesFrameTimeMonitor || Not used by OpenSimulator
|-
| LastReportedObjectUpdates || Currently unused.
|}

== Physics ==

All per frame times here relate to an average taken over the last 3 second period.

The following stats are always present.

{| border="1"
| PhysicsFPSMonitor || Frames per second processed by physics code.
|-
| PhysicsFrameMonitor || Obsolete. Same as PhysicsFrameTimeMonitor
|-
| PhysicsFrameTimeMonitor || Average time taken by physics processing.
|}

The following stats are only present if collect_stats = true in the [ODEPhysicsSettings] section of OpenSim.ini as of git master 6375db1 (post OpenSimulator 0.7.3.1 development code). These statistics are experimental and may change.

{| border="1"
| ODETotalFrameMS || ODE physics processing. This should match PhysicsFrameTimeMonitor.
|-
| ODEAvatarTaintFrameMS || Avatar taint processing.
|-
| ODEPrimTaintFrameMS || Prim taint processing.
|-
| ODEAvatarForcesFrameMS || Avatar forces calculations.
|-
| ODEPrimForcesFrameMS || Prim forces calculations.
|-
| ODERaycastingFrameMS || Raycasting.
|-
| ODENativeStepFrameMS || Time taken to perform a physics step by ODE native code.
|-
| ODENativeSpaceCollisionFrameMS || Calculation of possible collisions via spaces in ODE native code.
|-
| ODENativeGeomCollisionFrameMS || Resolution of actual collisions between geometries in ODE native code.
|-
| ODEOtherCollisionFrameMS || Processing of collisions not covered by the other 'Native' measures. This mainly covers operations done in the OpenSimulator's plugin itself, though some calls to native ODE functions are still made.
|-
| ODECollisionNotificationFrameMS || Notification of other parts of OpenSimulator of collisions that is performed outside of the ODE plugin.
|-
| ODEAvatarUpdateFrameMS || Time taken to process avatar updates from the physics code.
|-
| ODEPrimUpdateFrameMS || Time taken to process prim updates from the physics code.
|-
| ODEAvatarContacts || Number of avatar caused collision contacts in the last 3 second period. There can be more than one contact per collision.
|-
| ODEPrimContacts || Number of prim caused collision contacts in the last 3 second period. There can be more than one contact per collision.
|-
| ODETotalAvatars || Number of avatars modelled by physics. This should match AgentCountMonitor.
|-
| ODETotalPrims || Number of non-phantom prims. This covers both physics prims and prims which are not subject to physics but are still collidable. It does not cover phantom prims as these have no representation in the physics scene.
|-
| ODEActivePrims || Number of prims subject to physics. This should match ActiveObjectCountMonitor.
|}

== Examples ==
=== OpenSimulator 0.7.2 and earlier ===
On OpenSimulator 0.7.2 and earlier, fetching

<pre>http://192.168.1.2:9000/dd5b77f8-bf88-45ac-aace-35bd76426c81</pre>

will return something like

<pre>
<?xml version="1.0"?>
<data>
<AgentCountMonitor>0</AgentCountMonitor>
<ChildAgentCountMonitor>0</ChildAgentCountMonitor>
<GCMemoryMonitor>32358400</GCMemoryMonitor>
<ObjectCountMonitor>0</ObjectCountMonitor>
<PhysicsFrameMonitor>0</PhysicsFrameMonitor>
<PhysicsUpdateFrameMonitor>0</PhysicsUpdateFrameMonitor>
<PWSMemoryMonitor>354172928</PWSMemoryMonitor>
<ThreadCountMonitor>0</ThreadCountMonitor>
<TotalFrameMonitor>1</TotalFrameMonitor>
<EventFrameMonitor>0</EventFrameMonitor>
<LandFrameMonitor>0</LandFrameMonitor>
<LastFrameTimeMonitor>87</LastFrameTimeMonitor>
</data>
</pre>

=== OpenSimulator 0.7.3 and later ===
In current development code, more statistics have been added, so instead you'll see something like

<pre>
<?xml version="1.0"?>
<data>
<AgentCountMonitor>0</AgentCountMonitor>
<ChildAgentCountMonitor>0</ChildAgentCountMonitor>
<GCMemoryMonitor>32358400</GCMemoryMonitor>
<ObjectCountMonitor>0</ObjectCountMonitor>
<PhysicsFrameMonitor>0</PhysicsFrameMonitor>
<PhysicsUpdateFrameMonitor>0</PhysicsUpdateFrameMonitor>
<PWSMemoryMonitor>354172928</PWSMemoryMonitor>
<ThreadCountMonitor>0</ThreadCountMonitor>
<TotalFrameMonitor>1</TotalFrameMonitor>
<EventFrameMonitor>0</EventFrameMonitor>
<LandFrameMonitor>0</LandFrameMonitor>
<LastFrameTimeMonitor>87</LastFrameTimeMonitor>
<TimeDilationMonitor>1</TimeDilationMonitor>
<SimFPSMonitor>56.6666679382324</SimFPSMonitor>
<PhysicsFPSMonitor>46.9475212097168</PhysicsFPSMonitor>
<AgentUpdatesPerSecondMonitor>0</AgentUpdatesPerSecondMonitor>
<ActiveObjectCountMonitor>0</ActiveObjectCountMonitor>
<ActiveScriptsMonitor>0</ActiveScriptsMonitor>
<ScriptEventsPerSecondMonitor>0</ScriptEventsPerSecondMonitor>
<InPacketsPerSecondMonitor>0</InPacketsPerSecondMonitor>
<OutPacketsPerSecondMonitor>0</OutPacketsPerSecondMonitor>
<UnackedBytesMonitor>0</UnackedBytesMonitor>
<PendingDownloadsMonitor>0</PendingDownloadsMonitor>
<PendingUploadsMonitor>0</PendingUploadsMonitor>
<TotalFrameTimeMonitor>0</TotalFrameTimeMonitor>
<NetFrameTimeMonitor>0</NetFrameTimeMonitor>
<PhysicsFrameTimeMonitor>0</PhysicsFrameTimeMonitor>
<SimulationFrameTimeMonitor>0</SimulationFrameTimeMonitor>
<AgentFrameTimeMonitor>0</AgentFrameTimeMonitor>
<ImagesFrameTimeMonitor>0</ImagesFrameTimeMonitor>
</data>
</pre>

BulletSim

2015-03-01T01:29:15Z

Misterblue: /* Adjusting Avatar Height */ Changing default values to zero to reflect OpenSimDefaults.ini settings

'''BulletSim'''

__TOC__
BulletSim is the module for OpenSimulator that creates virtual world physics using the [http://bulletphysics.org Bullet Physics Engine]. This module provides high performance physics as well as physical vehicle performance compatible with [http://secondlife.com Second Life].

== Project Information ==

[[BulletSim/Functionality]] lists the possible physical operations, their implementation state and any notes on their use. This is particularly useful for vehicle operations.

== Building ==

== BulletSim Architecture ==

=== BSScene ===
Stuff on simulation stepper. Step events (pre-step event, post-step event).

Requirement for controlling physics engine modifications with taint system (regular taints, post-taint taints).

Detail logging system.

Parameter system.

=== BSPhysObject ===

Children classes of BSPrim and BSCharacter.

=== Terrain ===

=== Constraints ===

=== Bullet Implementations ===
BulletSim is a wrapper for the Bullet physics engine. The interface from the virtual world adapting BulletSim to the physics engine is described by the abstract class <code>BSAPITemplate</code>. There are two instances of this class, <code>BSAPIXNA</code> and <code>BSAPIUnman</code>.

<code>BSAPIUnman</code> contains the connection to the unmanaged DLL/SO that is the C++ version of the Bullet physics engine. The sources and build instructions are available at <code>git://opensimulator.org/git/opensim-libs/trunk/unmanaged/BulletSim</code>.

<code>BSAPIXNA</code> is the connection to a C# version of Bullet the sources of which are hosted at <code>https://code.google.com/p/bullet-xna/</code>.

The selection of physics engine happens at region start time. It is specified per simulator with the following INI settings:
<pre>
[Startup]
physics = BulletSim
[BulletSim]
BulletEngine = BulletUnmanaged ; The default
; BulletEngine = BulletXNA ; uncomment this line for C# version of Bullet
</pre>

=== Managed/Unmanaged Interface ===

== Linksets ==

== "Actor" Architecture and the Actors ==
Each BulletSim physical object can have any number of "actors" attached to it. The actors register for simulation events (usually to be called before each simulation step) and change the physical parameters of the object. The currently implemented actors are:
* BSActorAvatarMove: controls movement and stairs walking of avatars;
* BSActorHover: implements vertical hovering for objects and avatars;
* BSActorLockAxis: applies a constraint to physical objects to lock one or more angular axis movement;
* BSActorMoveToTarget: moves a physical object to a location;
* BSActorSetForce: applies a continuous force to a physical object;
* BSActorSetTorque: applies a continuous torque to a physical object;
* BSDynamic (name will change): implements SecondLife(r) vehicle model.

== Vehicles ==

[[BulletSim/Vehicles]]

[[BulletSim/VehicleTuning]]

== BulletSim Script Extension Functions ==

The physics extension interface is used by BulletSim to implement many new physics functions. The [[OSSL_Script_Library/ModInvoke|mod_invoke]] interface must be enabled for these functions to work.

[[BulletSim/ScriptFunctions]]

== Avatar Walking Up Stairs ==
The avatar movement actor include special checks to allow avatars to move up stepped objects (think stairs). The code works by checking for collisions close to the avatar's feet and, if trying to walk forward and not flying, pushing the avatar up to get over the object. This is a different algorithm than ODE which relies on the curvature of the avatar's capsule to move up and over low obstacles.

There are five INI parameters that control stairs:
{| class="wikitable" |
|AvatarStepHeight
|The maximum height of a step. If the avatar collides with something of less than this height, it will be considered a step and the avatar will consider moving up to get over it;
|-
|AvatarStepAngle
|The maximum angle of the collision surface to consider it a step. If set to zero, for instance, the step faces must be perfectly vertical before it would be considered a step surface. Typical value is 0.3f which allows some step variability;
|-
|AvatarStepGroundFudge
|A small fudge factor subtracted from the computed base of the avatar when checking if the collision is close to the avatar's feet. The base of the avatar computation can be a little high (above the ground) so this factor allows comparing lower for the step. This can prevent small bumps on the ground being too small to be considered a step (which causes the bump to act like a wall);
|-
|AvatarApproachFactor
|The angle the step must be approached. This is the radians of the angle between the avatar and the colliding step surface. This prevents walking up things when approached from a wide angle. The default of 0.6 is about a 45 degree approach angle. Setting this down to 0.3, for instance, requires the avatar to be walking nearly directly into the step to get the up actions.
|-
|AvatarStepUpCorrectionFactor
|A multiplication factor for changing the avatar's position to get over the step. The height of the collision with the step is multiplied by this factor and that number is added to the avatar's Z coordinate. This moves the avatar up in relation to the step. If this factor is less than zero, the AvatarStepHeight is used.
|-
|AvatarStepForceFactor
|A force factor to push the avatar up to get over the step. An up force of the step collision height times the avatar mass times this factor is applied to the avatar. These last two factors can be used in combination for moving the avatar when a step is collided with.
|-
|AvatarStepSmoothingSteps
|when an avatar walks up the steps, collisions go on and off as the steps are hit and moved over. This is the number of simulator ticks (about 10 per second) that walking up steps will still be performed after the last step collision is sensed. This smooths out the action a little.
|-
|}

The default values are:
<code><pre>
[BulletSim]
AvatarStepHeight = 0.6
AvatarStepGroundFudge = 0.1
AvatarStepApproachFactor = 0.6
AvatarStepUpCorrectionFactor = 1.0
AvatarStepForceFactor = 2.0
AvatarStepSmoothingSteps = 1
</pre></code>

== Other Notes ==

=== Adjusting Avatar Height ===

As of May 13, 2013, BulletSim uses the Bullet capsule shape to approximate a standing avatar. One oddity of the capsule is its height which doesn't scale nicely in the way OpenSimulator would like. To fix this, several adjustment parameters are available to correct the avatar capsule height so that an avatar properly appears to be standing on the ground rather than floating over or sunk into the ground.

These parameters are:
{| class="wikitable" |
|-
! INI varaible
! Default
! Description
|-
| AvatarHeightMidFudge
| 0.0
| This is a fudge factor added to the 50% avatar height (about 1.87 meters). This number is added to the total height so adjusting this number moves the whole capsule up and down by roughly this distance.
|-
| AvatarHeightLowFudge
| 0.0
| This factor is added to the height at the low end of the height scale ("0%" height which is about 1.62 meters). This number is scaled proportionally from the mid height to the low height. Adjusting this number adjusts the height of the capsule for small shapes.
|-
| AvatarHeightHighFudge
| 0.0
| This is similar to AvatarHeightLowFudge but it is applied to the high end of height ("100%" height which is about 2.12 meters). It is also added proportionally from the mid height to the large height.
|}

BulletSim

2015-01-07T14:37:09Z

Misterblue: Added AvatarStepAngle to walking up steps description

'''BulletSim'''

__TOC__
BulletSim is the module for OpenSimulator that creates virtual world physics using the [http://bulletphysics.org Bullet Physics Engine]. This module provides high performance physics as well as physical vehicle performance compatible with [http://secondlife.com Second Life].

== Project Information ==

[[BulletSim/Functionality]] lists the possible physical operations, their implementation state and any notes on their use. This is particularly useful for vehicle operations.

== Building ==

== BulletSim Architecture ==

=== BSScene ===
Stuff on simulation stepper. Step events (pre-step event, post-step event).

Requirement for controlling physics engine modifications with taint system (regular taints, post-taint taints).

Detail logging system.

Parameter system.

=== BSPhysObject ===

Children classes of BSPrim and BSCharacter.

=== Terrain ===

=== Constraints ===

=== Bullet Implementations ===
BulletSim is a wrapper for the Bullet physics engine. The interface from the virtual world adapting BulletSim to the physics engine is described by the abstract class <code>BSAPITemplate</code>. There are two instances of this class, <code>BSAPIXNA</code> and <code>BSAPIUnman</code>.

<code>BSAPIUnman</code> contains the connection to the unmanaged DLL/SO that is the C++ version of the Bullet physics engine. The sources and build instructions are available at <code>git://opensimulator.org/git/opensim-libs/trunk/unmanaged/BulletSim</code>.

<code>BSAPIXNA</code> is the connection to a C# version of Bullet the sources of which are hosted at <code>https://code.google.com/p/bullet-xna/</code>.

The selection of physics engine happens at region start time. It is specified per simulator with the following INI settings:
<pre>
[Startup]
physics = BulletSim
[BulletSim]
BulletEngine = BulletUnmanaged ; The default
; BulletEngine = BulletXNA ; uncomment this line for C# version of Bullet
</pre>

=== Managed/Unmanaged Interface ===

== Linksets ==

== "Actor" Architecture and the Actors ==
Each BulletSim physical object can have any number of "actors" attached to it. The actors register for simulation events (usually to be called before each simulation step) and change the physical parameters of the object. The currently implemented actors are:
* BSActorAvatarMove: controls movement and stairs walking of avatars;
* BSActorHover: implements vertical hovering for objects and avatars;
* BSActorLockAxis: applies a constraint to physical objects to lock one or more angular axis movement;
* BSActorMoveToTarget: moves a physical object to a location;
* BSActorSetForce: applies a continuous force to a physical object;
* BSActorSetTorque: applies a continuous torque to a physical object;
* BSDynamic (name will change): implements SecondLife(r) vehicle model.

== Vehicles ==

[[BulletSim/Vehicles]]

[[BulletSim/VehicleTuning]]

== BulletSim Script Extension Functions ==

The physics extension interface is used by BulletSim to implement many new physics functions. The [[OSSL_Script_Library/ModInvoke|mod_invoke]] interface must be enabled for these functions to work.

[[BulletSim/ScriptFunctions]]

== Avatar Walking Up Stairs ==
The avatar movement actor include special checks to allow avatars to move up stepped objects (think stairs). The code works by checking for collisions close to the avatar's feet and, if trying to walk forward and not flying, pushing the avatar up to get over the object. This is a different algorithm than ODE which relies on the curvature of the avatar's capsule to move up and over low obstacles.

There are five INI parameters that control stairs:
{| class="wikitable" |
|AvatarStepHeight
|The maximum height of a step. If the avatar collides with something of less than this height, it will be considered a step and the avatar will consider moving up to get over it;
|-
|AvatarStepAngle
|The maximum angle of the collision surface to consider it a step. If set to zero, for instance, the step faces must be perfectly vertical before it would be considered a step surface. Typical value is 0.3f which allows some step variability;
|-
|AvatarStepGroundFudge
|A small fudge factor subtracted from the computed base of the avatar when checking if the collision is close to the avatar's feet. The base of the avatar computation can be a little high (above the ground) so this factor allows comparing lower for the step. This can prevent small bumps on the ground being too small to be considered a step (which causes the bump to act like a wall);
|-
|AvatarApproachFactor
|The angle the step must be approached. This is the radians of the angle between the avatar and the colliding step surface. This prevents walking up things when approached from a wide angle. The default of 0.6 is about a 45 degree approach angle. Setting this down to 0.3, for instance, requires the avatar to be walking nearly directly into the step to get the up actions.
|-
|AvatarStepUpCorrectionFactor
|A multiplication factor for changing the avatar's position to get over the step. The height of the collision with the step is multiplied by this factor and that number is added to the avatar's Z coordinate. This moves the avatar up in relation to the step. If this factor is less than zero, the AvatarStepHeight is used.
|-
|AvatarStepForceFactor
|A force factor to push the avatar up to get over the step. An up force of the step collision height times the avatar mass times this factor is applied to the avatar. These last two factors can be used in combination for moving the avatar when a step is collided with.
|-
|AvatarStepSmoothingSteps
|when an avatar walks up the steps, collisions go on and off as the steps are hit and moved over. This is the number of simulator ticks (about 10 per second) that walking up steps will still be performed after the last step collision is sensed. This smooths out the action a little.
|-
|}

The default values are:
<code><pre>
[BulletSim]
AvatarStepHeight = 0.6
AvatarStepGroundFudge = 0.1
AvatarStepApproachFactor = 0.6
AvatarStepUpCorrectionFactor = 1.0
AvatarStepForceFactor = 2.0
AvatarStepSmoothingSteps = 1
</pre></code>

== Other Notes ==

=== Adjusting Avatar Height ===

As of May 13, 2013, BulletSim uses the Bullet capsule shape to approximate a standing avatar. One oddity of the capsule is its height which doesn't scale nicely in the way OpenSimulator would like. To fix this, several adjustment parameters are available to correct the avatar capsule height so that an avatar properly appears to be standing on the ground rather than floating over or sunk into the ground.

These parameters are:
{| class="wikitable" |
|-
! INI varaible
! Default
! Description
|-
| AvatarHeightMidFudge
| 0.1
| This is a fudge factor added to the 50% avatar height (about 1.87 meters). This number is added to the total height so adjusting this number moves the whole capsule up and down by roughly this distance.
|-
| AvatarHeightLowFudge
| -0.2
| This factor is added to the height at the low end of the height scale ("0%" height which is about 1.62 meters). This number is scaled proportionally from the mid height to the low height. Adjusting this number adjusts the height of the capsule for small shapes.
|-
| AvatarHeightHighFudge
| 0.1
| This is similar to AvatarHeightLowFudge but it is applied to the high end of height ("100%" height which is about 2.12 meters). It is also added proportionally from the mid height to the large height.
|}

BulletSim

2015-01-07T04:38:58Z

Misterblue: fix table formatting error (hate markdown)

'''BulletSim'''

__TOC__
BulletSim is the module for OpenSimulator that creates virtual world physics using the [http://bulletphysics.org Bullet Physics Engine]. This module provides high performance physics as well as physical vehicle performance compatible with [http://secondlife.com Second Life].

== Project Information ==

[[BulletSim/Functionality]] lists the possible physical operations, their implementation state and any notes on their use. This is particularly useful for vehicle operations.

== Building ==

== BulletSim Architecture ==

=== BSScene ===
Stuff on simulation stepper. Step events (pre-step event, post-step event).

Requirement for controlling physics engine modifications with taint system (regular taints, post-taint taints).

Detail logging system.

Parameter system.

=== BSPhysObject ===

Children classes of BSPrim and BSCharacter.

=== Terrain ===

=== Constraints ===

=== Bullet Implementations ===
BulletSim is a wrapper for the Bullet physics engine. The interface from the virtual world adapting BulletSim to the physics engine is described by the abstract class <code>BSAPITemplate</code>. There are two instances of this class, <code>BSAPIXNA</code> and <code>BSAPIUnman</code>.

<code>BSAPIUnman</code> contains the connection to the unmanaged DLL/SO that is the C++ version of the Bullet physics engine. The sources and build instructions are available at <code>git://opensimulator.org/git/opensim-libs/trunk/unmanaged/BulletSim</code>.

<code>BSAPIXNA</code> is the connection to a C# version of Bullet the sources of which are hosted at <code>https://code.google.com/p/bullet-xna/</code>.

The selection of physics engine happens at region start time. It is specified per simulator with the following INI settings:
<pre>
[Startup]
physics = BulletSim
[BulletSim]
BulletEngine = BulletUnmanaged ; The default
; BulletEngine = BulletXNA ; uncomment this line for C# version of Bullet
</pre>

=== Managed/Unmanaged Interface ===

== Linksets ==

== "Actor" Architecture and the Actors ==
Each BulletSim physical object can have any number of "actors" attached to it. The actors register for simulation events (usually to be called before each simulation step) and change the physical parameters of the object. The currently implemented actors are:
* BSActorAvatarMove: controls movement and stairs walking of avatars;
* BSActorHover: implements vertical hovering for objects and avatars;
* BSActorLockAxis: applies a constraint to physical objects to lock one or more angular axis movement;
* BSActorMoveToTarget: moves a physical object to a location;
* BSActorSetForce: applies a continuous force to a physical object;
* BSActorSetTorque: applies a continuous torque to a physical object;
* BSDynamic (name will change): implements SecondLife(r) vehicle model.

== Vehicles ==

[[BulletSim/Vehicles]]

[[BulletSim/VehicleTuning]]

== BulletSim Script Extension Functions ==

The physics extension interface is used by BulletSim to implement many new physics functions. The [[OSSL_Script_Library/ModInvoke|mod_invoke]] interface must be enabled for these functions to work.

[[BulletSim/ScriptFunctions]]

== Avatar Walking Up Stairs ==
The avatar movement actor include special checks to allow avatars to move up stepped objects (think stairs). The code works by checking for collisions close to the avatar's feet and, if trying to walk forward and not flying, pushing the avatar up to get over the object. This is a different algorithm than ODE which relies on the curvature of the avatar's capsule to move up and over low obstacles.

There are five INI parameters that control stairs:
{| class="wikitable" |
|AvatarStepHeight
|The maximum height of a step. If the avatar collides with something of less than this height, it will be considered a step and the avatar will consider moving up to get over it;
|-
|AvatarStepGroundFudge
|A small fudge factor subtracted from the computed base of the avatar when checking if the collision is close to the avatar's feet. The base of the avatar computation can be a little high (above the ground) so this factor allows comparing lower for the step. This can prevent small bumps on the ground being too small to be considered a step (which causes the bump to act like a wall);
|-
|AvatarApproachFactor
|The angle the step must be approached. This is the radians of the angle between the avatar and the colliding step surface. This prevents walking up things when approached from a wide angle. The default of 0.6 is about a 45 degree approach angle. Setting this down to 0.3, for instance, requires the avatar to be walking nearly directly into the step to get the up actions.
|-
|AvatarStepUpCorrectionFactor
|A multiplication factor for changing the avatar's position to get over the step. The height of the collision with the step is multiplied by this factor and that number is added to the avatar's Z coordinate. This moves the avatar up in relation to the step. If this factor is less than zero, the AvatarStepHeight is used.
|-
|AvatarStepForceFactor
|A force factor to push the avatar up to get over the step. An up force of the step collision height times the avatar mass times this factor is applied to the avatar. These last two factors can be used in combination for moving the avatar when a step is collided with.
|-
|AvatarStepSmoothingSteps
|when an avatar walks up the steps, collisions go on and off as the steps are hit and moved over. This is the number of simulator ticks (about 10 per second) that walking up steps will still be performed after the last step collision is sensed. This smooths out the action a little.
|-
|}

The default values are:
<code><pre>
[BulletSim]
AvatarStepHeight = 0.6
AvatarStepGroundFudge = 0.1
AvatarStepApproachFactor = 0.6
AvatarStepUpCorrectionFactor = 1.0
AvatarStepForceFactor = 2.0
AvatarStepSmoothingSteps = 1
</pre></code>

== Other Notes ==

=== Adjusting Avatar Height ===

As of May 13, 2013, BulletSim uses the Bullet capsule shape to approximate a standing avatar. One oddity of the capsule is its height which doesn't scale nicely in the way OpenSimulator would like. To fix this, several adjustment parameters are available to correct the avatar capsule height so that an avatar properly appears to be standing on the ground rather than floating over or sunk into the ground.

These parameters are:
{| class="wikitable" |
|-
! INI varaible
! Default
! Description
|-
| AvatarHeightMidFudge
| 0.1
| This is a fudge factor added to the 50% avatar height (about 1.87 meters). This number is added to the total height so adjusting this number moves the whole capsule up and down by roughly this distance.
|-
| AvatarHeightLowFudge
| -0.2
| This factor is added to the height at the low end of the height scale ("0%" height which is about 1.62 meters). This number is scaled proportionally from the mid height to the low height. Adjusting this number adjusts the height of the capsule for small shapes.
|-
| AvatarHeightHighFudge
| 0.1
| This is similar to AvatarHeightLowFudge but it is applied to the high end of height ("100%" height which is about 2.12 meters). It is also added proportionally from the mid height to the large height.
|}

BulletSim

2015-01-07T03:46:25Z

Misterblue: Add description of AvatarStepGroundFudge. Correct default values to match code.

'''BulletSim'''

__TOC__
BulletSim is the module for OpenSimulator that creates virtual world physics using the [http://bulletphysics.org Bullet Physics Engine]. This module provides high performance physics as well as physical vehicle performance compatible with [http://secondlife.com Second Life].

== Project Information ==

[[BulletSim/Functionality]] lists the possible physical operations, their implementation state and any notes on their use. This is particularly useful for vehicle operations.

== Building ==

== BulletSim Architecture ==

=== BSScene ===
Stuff on simulation stepper. Step events (pre-step event, post-step event).

Requirement for controlling physics engine modifications with taint system (regular taints, post-taint taints).

Detail logging system.

Parameter system.

=== BSPhysObject ===

Children classes of BSPrim and BSCharacter.

=== Terrain ===

=== Constraints ===

=== Bullet Implementations ===
BulletSim is a wrapper for the Bullet physics engine. The interface from the virtual world adapting BulletSim to the physics engine is described by the abstract class <code>BSAPITemplate</code>. There are two instances of this class, <code>BSAPIXNA</code> and <code>BSAPIUnman</code>.

<code>BSAPIUnman</code> contains the connection to the unmanaged DLL/SO that is the C++ version of the Bullet physics engine. The sources and build instructions are available at <code>git://opensimulator.org/git/opensim-libs/trunk/unmanaged/BulletSim</code>.

<code>BSAPIXNA</code> is the connection to a C# version of Bullet the sources of which are hosted at <code>https://code.google.com/p/bullet-xna/</code>.

The selection of physics engine happens at region start time. It is specified per simulator with the following INI settings:
<pre>
[Startup]
physics = BulletSim
[BulletSim]
BulletEngine = BulletUnmanaged ; The default
; BulletEngine = BulletXNA ; uncomment this line for C# version of Bullet
</pre>

=== Managed/Unmanaged Interface ===

== Linksets ==

== "Actor" Architecture and the Actors ==
Each BulletSim physical object can have any number of "actors" attached to it. The actors register for simulation events (usually to be called before each simulation step) and change the physical parameters of the object. The currently implemented actors are:
* BSActorAvatarMove: controls movement and stairs walking of avatars;
* BSActorHover: implements vertical hovering for objects and avatars;
* BSActorLockAxis: applies a constraint to physical objects to lock one or more angular axis movement;
* BSActorMoveToTarget: moves a physical object to a location;
* BSActorSetForce: applies a continuous force to a physical object;
* BSActorSetTorque: applies a continuous torque to a physical object;
* BSDynamic (name will change): implements SecondLife(r) vehicle model.

== Vehicles ==

[[BulletSim/Vehicles]]

[[BulletSim/VehicleTuning]]

== BulletSim Script Extension Functions ==

The physics extension interface is used by BulletSim to implement many new physics functions. The [[OSSL_Script_Library/ModInvoke|mod_invoke]] interface must be enabled for these functions to work.

[[BulletSim/ScriptFunctions]]

== Avatar Walking Up Stairs ==
The avatar movement actor include special checks to allow avatars to move up stepped objects (think stairs). The code works by checking for collisions close to the avatar's feet and, if trying to walk forward and not flying, pushing the avatar up to get over the object. This is a different algorithm than ODE which relies on the curvature of the avatar's capsule to move up and over low obstacles.

There are five INI parameters that control stairs:
{| class="wikitable" |
|AvatarStepHeight
|The maximum height of a step. If the avatar collides with something of less than this height, it will be considered a step and the avatar will consider moving up to get over it;
|-
|AvatarStepGroundFudge
|A small fudge factor subtracted from the computed base of the avatar when checking if the collision is close to the avatar's feet. The base of the avatar computation can be a little high (above the ground) so this factor allows comparing lower for the step. This can prevent small bumps on the ground being too small to be considered a step (which causes the bump to act like a wall);
|-|AvatarApproachFactor
|The angle the step must be approached. This is the radians of the angle between the avatar and the colliding step surface. This prevents walking up things when approached from a wide angle. The default of 0.6 is about a 45 degree approach angle. Setting this down to 0.3, for instance, requires the avatar to be walking nearly directly into the step to get the up actions.
|-
|AvatarStepUpCorrectionFactor
|A multiplication factor for changing the avatar's position to get over the step. The height of the collision with the step is multiplied by this factor and that number is added to the avatar's Z coordinate. This moves the avatar up in relation to the step. If this factor is less than zero, the AvatarStepHeight is used.
|-
|AvatarStepForceFactor
|A force factor to push the avatar up to get over the step. An up force of the step collision height times the avatar mass times this factor is applied to the avatar. These last two factors can be used in combination for moving the avatar when a step is collided with.
|-
|AvatarStepSmoothingSteps
|when an avatar walks up the steps, collisions go on and off as the steps are hit and moved over. This is the number of simulator ticks (about 10 per second) that walking up steps will still be performed after the last step collision is sensed. This smooths out the action a little.
|-
|}

The default values are:
<code><pre>
[BulletSim]
AvatarStepHeight = 0.6
AvatarStepGroundFudge = 0.1
AvatarStepApproachFactor = 0.6
AvatarStepUpCorrectionFactor = 1.0
AvatarStepForceFactor = 2.0
AvatarStepSmoothingSteps = 1
</pre></code>

== Other Notes ==

=== Adjusting Avatar Height ===

As of May 13, 2013, BulletSim uses the Bullet capsule shape to approximate a standing avatar. One oddity of the capsule is its height which doesn't scale nicely in the way OpenSimulator would like. To fix this, several adjustment parameters are available to correct the avatar capsule height so that an avatar properly appears to be standing on the ground rather than floating over or sunk into the ground.

These parameters are:
{| class="wikitable" |
|-
! INI varaible
! Default
! Description
|-
| AvatarHeightMidFudge
| 0.1
| This is a fudge factor added to the 50% avatar height (about 1.87 meters). This number is added to the total height so adjusting this number moves the whole capsule up and down by roughly this distance.
|-
| AvatarHeightLowFudge
| -0.2
| This factor is added to the height at the low end of the height scale ("0%" height which is about 1.62 meters). This number is scaled proportionally from the mid height to the low height. Adjusting this number adjusts the height of the capsule for small shapes.
|-
| AvatarHeightHighFudge
| 0.1
| This is similar to AvatarHeightLowFudge but it is applied to the high end of height ("100%" height which is about 2.12 meters). It is also added proportionally from the mid height to the large height.
|}

Stats Manager

2015-01-01T17:25:34Z

Misterblue: example of JSON response

=Introduction=
The OpenSimulator stats manager system is the most modern stats implementation in OpenSimulator and will eventually replace all legacy systems. It allows statistics to be added, updated and removed at runtime. Statistics can be viewed via the console "[[show stats]]" command and recorded periodically to file for later analysis.

=General Concepts=
StatsManager acts as the interface between code that have statistics and modules that want to access and display those statistics. At startup, code register their statistics with StatsManager. Then, any code that wishes to access the statistics (whether to display them on the console, put them in databases, or make them available over the network) requests the values from StatsManager. This architecture allows multiple statistic display and analysis systems while also removing the burden of code instrumentation from the display systems. Also, once code is instrumented and registering statistics, those statistics are available to all display systems.

At initialization, code registers its statistics with StatsManager. The full name of a stat has three components, separated by periods (.). In order, these are

* '''category''' - The category of the stat (e.g. server, scene)
* '''container''' - The containing object for this stat. For example, on scene this is the scene name (e.g. region 1). For server, this is the component to which the stat relates (e.g. memory, processor).
* '''name''' - The stat itself. For example, ClientLogoutsDueToNoReceives or SimFPS.

Full names must be unique.

Registered statistics are generally of two types:
* '''pull''' - the value of the statistic is "pulled" when the value is requested (using a closure to access the true value location); and
* '''push''' - the value is periodically stored in the statistic by the monitored code. There are two types of "push" statistics - the kind that just store a value and those that record events.

In the namespace <tt>Opensim.Framework.Monitoring</tt>, there is the basic <tt>Stats</tt> class (invocation described below) that provides the basic push or pull statistic. There is also a <tt>CounterStat</tt> class designed for routines that want to track events. <tt>CounterStats</tt> can have <tt>EventHistogram</tt> classes added to keep histograms of events over time. This latter feature is good for tracking statistics that can change more quickly than any external sampling.

= Programmatic Interface =
== Creating a stat ==
A statistic is represented by an instance of the OpenSim.Framework.Monitoring.Stat class or one of its descendant classes. Here's an example that creates a stat for recording all the HTTP requests served by the webserver embedded in OpenSimulator.

<source lang="csharp">
m_requestsProcessedStat
= new Stat(
"HTTPRequestsServed",
"Number of inbound HTTP requests processed",
"The number of inbound HTTP requests processed by the builtin HTTP server.",
"requests",
"httpserver",
Port.ToString(),
StatType.Pull,
MeasuresOfInterest.AverageChangeOverTime,
stat => stat.Value = RequestNumber,
StatVerbosity.Debug);
</source>

This breaks down as follows

* '''HTTPRequestsServed''' - The short name of this stat. This is the name used when the stat is displayed or recorded.
* '''Number of inbound HTTP requests processed''' - The full name of this stat.
* '''The number of inbound HTTP requests processed by the builtin HTTP server.''' - A description of this stat.
* '''requests''' - The unit name for this stat.
* '''httpserver''' - The category for this stat.
* '''container''' - The container for this stat within the category. In this case, we use the port number as the "container" since this distinguishes this data from similar stats on other ports. Another example of a distinguishing container is the region name.
* '''StatType.Pull''' - The statistic type. This is either Pull or Push. If Pull, then when a stat is required (e.g. if the user requests the information or it needs to be recorded), then it is gathered by the given pullAction (of which more below). If a statistic if push, then the pull action is null (or will be ignored) and the code registering the stat is responsible for updating the value directly on an ongoing basis.
* '''MeasuresOfInterest.AverageChangeOverTime''' - This can be None or ChangeOverTime. If None, then only the raw stat is recorded. If ChangeOverTime, then StatsManager also derives the moving average over the last 24 samples.
* '''stat => stat.Value = RequestNumber''' - This is the anonymous function used to generate the stat on a pull request. In this case, the RequestNumber within the HTTP management code is inserted into the stat value.
* '''StatVerbosity.Debug''' - StatVerbosity can be Debug or Info. Info should be used for stats that the user will always be interested in seeing (e.g. number of users on a region) and Debug for debugging stats (such as HTTP requests served). However, right now stat display is not filtered on verbosity.

== Registering a stat==
A created stat must then be registered with the StatsManager. In the case of our example above, this is done as follows.

<source lang="csharp">
StatsManager.RegisterStat(m_requestsProcessedStat);
</source>

== Deregistering a stat==
If your code is never disabled during runtime then you don't need to worry about deregistering the stat. However, if it can be removed (e.g. because it is in a region module) then you can deregister a stat as follows.

<source lang="csharp">
StatsManager.DeregisterStat(m_requestsProcessedStat);
</source>

== Fetching stats ==
There are several interfaces for fetching stats. The easiest is:
<source lang="csharp">
StatsManager.TryGetStats(string category, string container, string shortStatName, out Stat)
</source>
which accepts the name of a category, container, and the short version of the stat name and returns the statistic. Null is returned if the stat is not found.

There are also methods to return all of the stats within a category (<tt>TryGetStatsForCategory</tt>) and within a container (<tt>GetStatsForEachContainer</tt>).

= Statistics from the console =

From the console, there are several ways to display the stats:
* <tt>show stats</tt> returns simulator statistics in a legacy format
* <tt>show stats all</tt> displays all the registered stats one line per stat.
* <tt>show stats category container</tt> displays all the stats within a particular category/container

= Web access to stats =

If <tt>[Startup]ManagedStatsRemoteFetchURI</tt> is defined and set to some value, the simulator statistics are available over the web via HTTP GET operations. The URL is the simulator's HTTP server URL appended with the value in <tt>ManagedStatsRemoteFetchURI</tt>.

The URL fetched accepts four different query parameters:

* '''cat''' which specifies a category to fetch. If no category is given, the special category "all" is use which return all categories;
* '''cont''' specified a container. If not specified, the special container "all" is used to return all containers
* '''stat''' specifies the name of the particular stat. If not specified, the stat "all" is used to return all stats.
* '''callback''' specifies if the returned JSON data is to be wrapped in a callback function.

For instance, for a simulator at IP address 10.1.1.4 with the INI settings:

<pre>
[network]
http_listener_port=9000
[Startup]
ManagedStatsremoteFetchURI=ManagedStats
</pre>

example data fetches are:

; wget http://10.1.1.4:9000/ManagedStats/
: returns all stats registered in the simulator
; wget http://10.1.1.4:9000/ManagedStats/?cat=server
: returns all stats registered with the category "server"
; wget http://10.1.1.4:9000/ManagedStats/?cat=server&cont=threadpool
: returns all stats for the "threadpool" container within the "server" category
; wget http://10.1.1.4:9000/ManagedStats/?cat=server&cont=threadpool&stat=STPMinThreads
: returns the value for the specific stat

The data is returned in JSON format grouped as you might expect with maps of categories containing maps of containers containing maps of stats. For instance, the response to <tt>http://10.1.1.4:9000/ManagedStats/?cat=server&cont=threadpool</tt> might look like:

<pre>
{"server":
{"threadpool":
{"BuiltinThreadpoolIOCPThreadsAvailable":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"BuiltinThreadpoolIOCPThreadsAvailable",
"Name":"BuiltinThreadpoolIOCPThreadsAvailable",
"Description":"BuiltinThreadpoolIOCPThreadsAvailable",
"UnitName":"threads",
"Value":1000.0
},
"BuiltinThreadpoolWorkerThreadsAvailable":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"BuiltinThreadpoolWorkerThreadsAvailable",
"Name":"BuiltinThreadpoolWorkerThreadsAvailable",
"Description":"BuiltinThreadpoolWorkerThreadsAvailable",
"UnitName":"threads",
"Value":499.0
},
"STPActiveThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPActiveThreads",
"Name":"STPActiveThreads",
"Description":"STPActiveThreads",
"UnitName":"threads",
"Value":15.0
},
"STPConcurrency":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPConcurrency",
"Name":"STPConcurrency",
"Description":"STPConcurrency",
"UnitName":"threads",
"Value":45.0
},
"STPInUseThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPInUseThreads",
"Name":"STPInUseThreads",
"Description":"STPInUseThreads",
"UnitName":"threads",
"Value":0.0
},
"STPMaxThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPMaxThreads",
"Name":"STPMaxThreads",
"Description":"STPMaxThreads",
"UnitName":"threads",
"Value":45.0
},
"STPMinThreads":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPMinThreads",
"Name":"STPMinThreads",
"Description":"STPMinThreads",
"UnitName":"threads",
"Value":15.0
},
"STPWorkItemsWaiting":
{"StatType":"Stat",
"Category":"server",
"Container":"threadpool",
"ShortName":"STPWorkItemsWaiting",
"Name":"STPWorkItemsWaiting",
"Description":"STPWorkItemsWaiting",
"UnitName":"threads",
"Value":0.0
}
}
}
}
</pre>

Stats Manager

2015-01-01T17:22:11Z

Misterblue: examples of fetching from web

Stats Manager

2015-01-01T06:25:44Z

Misterblue: more info on fetching stats

Stats Manager

2014-12-31T21:21:34Z

Misterblue: description of two stats types

Stats Manager

2014-12-31T21:14:03Z

Misterblue: General architectural description added to 'General Concepts'

PhysicsEngines

2014-06-08T17:57:09Z

Misterblue: Added note that BulletSim is now the default physics engine

{{Quicklinks}}
== Introduction ==
'''Note: Much of this page was written in November 2009. The OpenDynamicsEngine OpenSimulator plugin is not currently under any significant active development as the [[BulletSim]] physics plugin will likely become the default in the next release of OpenSimulator. However, as of OpenSimulator 0.7.6, [[BulletSim]] is still considered experimental.''' -- [[User:Justincc|Justincc]] 20:45, 19 November 2013 (UTC)

'''Note: [[BulletSim]] has become the default. Refer to the [[BulletSim]] pages for setup and operation''' -- [[User:Misterblue|Misterblue]] 17:54, 06 June 2014 (UTC)

The physics engines currently available for use in OpenSimulator are "basicphysics", "POS" and "OpenDynamicsEngine". As of OpenSimulator 0.6.9, the plugin "OpenDynamicsEngine" is the default and can be seen in the <tt>OpenSim.ini</tt> file.

ODE has received the bulk of testing. As of 2010 it supports collisions with all prims (cubes, spheres, cylinders etc) with any combination of distortions including hollow, taper, twist, path cut etc. In combination with Meshmerizer it also supports correctly colliding with sculpted prims.

== ODE Plugin ==
'''In Linux you should consider using included shell script, <tt>opensim-ode.sh</tt> or type <tt>ulimit -s 262144</tt> before running mono OpenSim.exe if you plan on having a large number of physics objects (each avatar is a physics object, as well as those which have the physics flag set on the simulator). The ulimit -s 262144 in Linux protects you against stack collisions and corrupted memory when there are a large amount of physical objects roaming around.'''

Currently, the ODE Plugin suports collisions Av2Av, Av2Prim and Prim2Prim. Avies and (active)physical prim movement supported.

The currently collision behavior is:
* For avies, a capsule of .2m of radius and a length based on the avatar height and 80Kg of mass
* For prims, like a Box or Sphere with a mass of a Box of = 0.5Kg/l = 0.5Kg/dm3 = 500Kg/m3.

* Prim are separated into ~30m space islands with their own bounding box to speed 'near' calculation.

* friction is reduced on avatar to object/ground collisions when the avatar is moving

=== To-do list (next changes) ===
* This plugin is not currently under active development. However, patches which implement extra functionality without any danger of regressions are still welcome.

=== Known bugs ===
* Vehicle support is incomplete.

=== Recent changes ===

=== Compiling from source ===

OpenSimulator currently bundles r1755 of ODE (a revision post 0.11.1). The code is in the [[Opensim-libs git repository]], in the trunk/unmanaged/OpenDynamicsEngine-r1755/ directory. This directory has a few patches applied to ODE specifically for OpenSimulator ("git log" to see information about these). It also has instructions on how to build the code and install for OpenSimulator.

==== Old compile instructions ====

(Kept for now for comparison and historical purposes).

===== Linux =====

Ensure that the file ../ou/bootstrap is executable and then bootstrap the build process as follows:

It might be necessary to make the bootstrap file executable(if it is not) with this optional next step:

$ cd ou
$ chmod +x bootstrap

Now get ready and run autogen

$ sh autogen.sh

and compile it as shown below. Depending on how permissions are setup, you may need to sudo for the make install step:

./configure --enable-shared --disable-demos --disable-asserts
make
make install
cp /usr/local/lib/libode.so /my/opensim/production/dir

If you run into issues after doing this try the debug library by using the following line;

./configure --enable-shared --disable-demos

(I used to suggest --with-trimesh=gimpact, but no longer. As of ODE 0.9, Opcode is the preferred and best-supported collision library)

This should create a <tt>libode.a</tt> and <tt>lidode.so</tt> file in the <tt>src/ode</tt> subdirectory. Copy these two files to the opensim <tt>bin</tt> directory (after having backed up the original files there). [er, I don't think the .a file is necessary to put in bin!]

Try to play a bit with the avatar-settings in OpenSim.ini, if the avatar has it's feet stick in the terrain or if the basic-position is crouching.
These settings seem to work on Linux64: (Note that these are old settings and may not work with the latest OpenSimulator versions)
av_capsule_radius = 0.68
av_capsule_standup_tensor_linux = 1900000
av_density = 90

===== Mac OS X =====

You can use essentially the same build process on OS X as on Linux,
but there are a couple of minor differences.

First, the <tt>autogen.sh</tt> script tries to automatically determine
the name of the libtoolize binary (which is named glibtoolize on OS
X). To do this, it uses the <tt>which</tt> command under bash, but
the error code returned by <tt>which</tt> is always 0 in bash. If you
see an error message like this:

autogen.sh: line 44: no: command not found

then open autogen.sh in a text editor and change the first
<pre>LIBTOOLIZE=`which libtoolize`</pre> to <pre>LIBTOOLIZE=`which glibtoolize`</pre>
and re-run it.

Also, you must have automake 1.10 or later. You can check your
current version with:

automake --version

You can get version 1.10 from [http://www.macports.org/ MacPorts] or
[http://www.finkproject.org/ fink] if yours is older. Be sure to
place the new binary directories ahead of your system binary
directories in your PATH. You may have to open a new shell for your
changes to take effect.

Then you can follow the Linux instructions to build the library. When it has built, copy the <tt>ode/src/.libs/libode.dylib</tt> file to the OpenSimulator <tt>bin</tt> directory.

===== Windows =====

The standard distribution has a build directory, in which you will find subdirs for several Microsoft compilers.

The standard .sln files (at least for VS2005) compile ode.dll such that it depends on at least two Microsoft runtime dll's. This can cause failure and confusion, so do the following:
Right-click on ode in Solution Explorer, and select properties.
under Configuration Properties/General, change "Use of MFC" to read "Use MFC in a Static Library"

Under Configuration Properties/Linker/System. Change Stack Reserve Size to 262144000. Click the OK button then compile as usual.

== POS Plugin ==
POS is Physics Of Simplicity. It is BasicPhysics with collisions.

I took out my old wiki stuff because it was just plain wrong. The algorithm which is implemented in POS does ''not'' model the avatar as a sphere; rather, it models it as a rectilinear solid, same as the prims. However, collision detection is always done in the rotational frame of the prim, so depending on which prim you check against, the avatar is actually oriented differently.

=== To-do list (next changes) ===
* TODO

=== Known bugs ===
* TODO

== Old plugins ==

These are plugins that are no longer maintained and have been removed from OpenSimulator.

=== BulletX Plugin in OpenSim: Modified BulletX ===
As of 2007 Bullet supported box-shaped prims and appears stable; there had been little testing, and it is known to have issues with friction (you skate around on non-level surfaces)

BulletX Plugin in OpenSimulator runs the modified version of BulletX. The original version of BulletX runs under and has code-dependencies with MS.XNA. The orginal BulletX can be found at [http://www.codeplex.com/xnadevru XNADev.ru]. The modified version removes all code dependencies with MS.XNA. On the other hand, it needs another library to work. This library is based on Mono.Xna and it's called MonoCompactMaths. The modified BulletX and the MonoXnaCompactMaths can be found on the svn of OpenSimulator. Because its code independency of MS.XNA, the modified BulletX should can be run under either MS.Net or Mono and, therefore, either Windows or Linux (obviously you can combine Windows + Mono)

Currently, BulletX Plugin suports collisions Av2Av, Av2Prim and Prim2Prim. Prims and avies movement supported. By the way, collisions needs tunning. The currently collision's behavoir are:
* For avies, like and sphere of 1m of radious and 50Kg of mass
* For prims, like a Box of the prim-size and a mass that it depends of its sizes. The mass it's the mass of Box of water with density = 1Kg/l = 1Kg/dm3 = 1000Kg/m3 (Be water my friend! :D).

==== To-do list (next changes) ====
* Tune collision
* Introduce Prim Shape Type to have more than the box shape.
* More than 1 region in a Sim and then more than 1 sim (grid)
* Fix bugs

==== Known bugs ====
* Icy bug: ''an avatar acts like it is on ice and tends to drift off the edge of the sim after a while''
* Crash on BulletX. You will find the next message in console sometimes: ''Overflow in AABB, object removed from simulation If you can reproduce this, please email bugs@continuousphysics.com Please include above information, your Platform, version of OS. Thanks.''
* <del>Rotation doesn't seem to work</del> 

== Physics Testing Videos ==

=== ODE ===
* ODE 25 Physical Spheres on Windows Server 2008 Dual Pentium 3 1000mhz with 1 gb of ram. [01/24/2008 rev.3170]
QuickTime > http://www.nebadonizumi.com/vid/opensim/windows2008_ODE_2.mov
YouTube > http://www.youtube.com/watch?v=DGyhne2llRI
* 360 Physical Prims (Sim Crashes) [11/08/2007 rev.2308] 
QuickTime > http://www.nebadonizumi.com/vid/opensim/opensim_ODE_physics_test_01.mov
Stage6 > http://stage6.divx.com/user/3dlibre/video/1847652/
YouTube > http://www.youtube.com/watch?v=Y0olsWlTc0A
* 180 Physical Prims (Sim Does Not Crash) [11/08/2007 rev.2308] 
QuickTime > http://www.nebadonizumi.com/vid/opensim/opensim_ODE_physics_test_02.mov
Stage6 > http://stage6.divx.com/user/3dlibre/video/1847715/
YouTube > http://www.youtube.com/watch?v=9lR_2H7VODU
* 90 Physical Prims (Sim Does Not Crash) [11/08/2007 rev.2308] 
Quicktime > http://www.nebadonizumi.com/vid/opensim/opensim_ODE_physics_test_03.mov
Stage6 > http://stage6.divx.com/user/3dlibre/video/1847731/
YouTube > http://www.youtube.com/watch?v=t9ulYO8I26Q

=== BulletX ===
* 360 Physical Prims (Sim Crashes) [11/08/2007 rev.2308] 
QuickTime > http://www.nebadonizumi.com/vid/opensim/opensim_BulletX_physics_test_01.mov
Stage6 > http://stage6.divx.com/user/3dlibre/video/1847745/
* 180 Physical Prims (Sim Crashes) [11/08/2007 rev.2308] 
QuickTime > http://www.nebadonizumi.com/vid/opensim/opensim_BulletX_physics_test_02.mov
* 90 Physical Prims (Sim Crashes) [11/08/2007 rev.2308] 
QuickTime > http://www.nebadonizumi.com/vid/opensim/opensim_BulletX_physics_test_03.mov

=== Second Life Havok 1 ===
* 360 Physical Prims [11/08/2007] 
http://www.nebadonizumi.com/vid/opensim/SecondLife_physics_test_01.mov

=== Second Life Havok 4 ===
* 360 Physical Prims [11/08/2007] 
http://www.nebadonizumi.com/vid/opensim/SecondLifeBetaHavok_physics_test_01.mov
* 1000 Physical Prims [11/09/2007] 
http://www.nebadonizumi.com/vid/opensim/SecondLifeBetaHavok_physics_test_02.mov
* 1000 Physical Prims [11/09/2007] 
http://www.nebadonizumi.com/vid/opensim/SecondLifeBetaHavok_physics_test_03.mov

[[Category:Development]]

Varregion

2014-06-08T17:50:13Z

Misterblue: Update 'todo' list

{{MainPageQuicklinks}}

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

This is different from the older [[Megaregions]] large region feature which does not require extra viewer support (above that already implemented by Linden Lab) but which relies on a number of fragile hacks to make a viewer work in a way that Linden Lab never supported. Megaregions also contain a number of extant simulator-side bugs.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There seems to be a viewer problem where, if regions of different size are within view distance, crashes can happen. Consider having regions of only the same size 'in view'. Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. As of 20140128, BulletSim has been modified to force heightmap terrain implementation if region size is greater than 256 on any side. The setting can be forced by adding to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

* Because there is a lot of terrain in a varregion, it can take a while for the terrain to load into the viewer. You should set the following parameter so terrain is only loaded within an avatar's view distance and so the terrain is loaded from the avatar's position outward (rather than the 'lawn mower' pattern from the outside of the region:
<pre>
[Terrain]
SendTerrainUpdatesByViewDistance = true
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

For llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 512.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, [[Load_Oar|load oar]] now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcel
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcel
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcel
</pre>

Note the new "--force-terrain" and "--force-parcel" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

As of January 27, 2014, varregion is a feature of the 'master' repository branch.

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2014-06-08T17:38:26Z

Misterblue: Add note about setting SendTerrainUpdatesByViewDistance

{{MainPageQuicklinks}}

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

This is different from the older [[Megaregions]] large region feature which does not require extra viewer support (above that already implemented by Linden Lab) but which relies on a number of fragile hacks to make a viewer work in a way that Linden Lab never supported. Megaregions also contain a number of extant simulator-side bugs.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There seems to be a viewer problem where, if regions of different size are within view distance, crashes can happen. Consider having regions of only the same size 'in view'. Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. As of 20140128, BulletSim has been modified to force heightmap terrain implementation if region size is greater than 256 on any side. The setting can be forced by adding to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>
** Because there is a lot of terrain in a varregion, it can take a while for the terrain to load into the viewer. You should set the following parameter so terrain is only loaded within an avatar's view distance and so the terrain is loaded from the avatar's position outward (rather than the 'lawn mower' pattern from the outside of the region:
<pre>
[Terrain]
SendTerrainUpdatesByViewDistance = true
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

For llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 512.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, 'load oar' now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four
OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel
load oar oar10.oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel
load oar oar11.oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel
</pre>

Note the new "--forceterrain" and "--forceparcel" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

As of January 27, 2014, varregion is a feature of the 'master' repository branch.

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region. (mostly done)
* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide if to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use in ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
* Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

==Tips on Migrating Existing Sims to VarRegions==
* When you start the sim, you have to have either no regions nearby, or identical sized regions. otherwise, it locks your movement to the size of the smallest region
* When you load your oars, it's like Aurora sim. You need to load them by displacement first, load each one in place to get the terrains.
* When you merge, you lose the terrain.
* The second round, you reload each oar, this time with merge to load the objects.
* If you don't use merge, you lose all the objects with each oar load.
* When you load your oars, in format "<0,0,0>" the first number is east/west, or x, the second number is north/south, or y, and the third number is up or down, or z.
* The location must be in increments of 256.
* Using ROBUST for xbakes takes a significant load off the server; textures load quickly

Load Oar

2014-06-08T17:19:15Z

Misterblue: Added examples of using 'load oar'

{{Quicklinks}}

= Load Oar Console Command =
Once you have saved regions in OAR files, the 'load oar' console command will load the OAR file into the current region. There are many parameters that enable replacing the region's current contents or merging the OAR file's contents with the objects and terrain already in the region.

== Parameters ==
The load oar command has the format:

<tt>load oar [parameters] OARFILE</tt>

where "OARFILE" is the path to the OAR file to read in, and "[parameters]" is zero or more optional parameters from the following list:

{| class="wikitable"
! style="width: 10em" | Parameter
! Since
! Description
|-
| --merge
| 0.6.8
| Specify to merge the contents of the reading OAR with the existing contents in the region.
|-
| --skip-assets
| 0.6.9
| If set, this will not load any of the assets from the OAR, though all other data will be loaded. This saves a lot of time and database operations if loading an OAR multiple times on a grid -- specify <tt>--skip-assets</tt> after the first time the OAR is loaded on a grid as the assets would have already been loaded the first time the OAR files was loaded.
|-
| --displacement
| dev
| Specify a displacement that is added to all objects in the OAR file as they are added to the region. The displacement MUST be specified as "<x,y,z>". So, for instance, to load an OAR from a 256x256 region into the middle of a larger 512x512 region, the parameter would be <tt>--displacement "<128,128,0>"</tt>. Note that you can specify a "Z" displacement which will move the objects up or down. Thus <tt>--displacement "<0,0,1000>"</tt> will put all the OAR's objects up high for a sky box.

The displacement is also applied to the terrain if it is included. The 'z' component is added to the terrain's heights.
|-
| --rotation
| dev
| The degrees to rotate all the objects loaded from the OAR.
|-
| --rotation-center
| dev
| The center around which to rotate objects on load.
|-
| --no-objects
| dev
| Don't load any scene objects.
|-
| --force-terrain
| dev
| Force terrain loading on --merge. Normally, --merge does not overwrite the existing region's terrain.
|-
| --force-parcels
| dev
| Force parcel loading on --merge. Normally, --merge does not overwrite the existing region's parcel data.
|}

== Notes On Regions of Different Sizes ==
With the addition of [[VarRegions]] there is the possibility of loading OARs to and from regions of different sizes. In general, loading an OAR from a smaller region into a larger region will do what you expect. Trying to load a larger region into a smaller region will generate many errors although, if you have adjacent smaller regions, some of the objects will be loaded into the adjacent regions. Try at your own risk.

= Example Uses =

== Replacing a region's contents with what's in an OAR file ==
Replacing a region with an OAR file for a region of the same size is as simple as:

<tt>load oar NewRegion.oar</tt>

== Merging together four region's worth of contents ==
Say you have four adjacent 256x256 region ('Region00.oar', 'Region01.oar', ...) and you want to load them into a new 512x512 [[VarRegion]] ('BiggerRegion'). The commands would be:

<tt>change region BiggerRegion</tt>
<tt>load oar Region0.oar</tt>
<tt>load oar --merge --force-terrain --displacement <0,256,0> Region01.oar</tt>
<tt>load oar --merge --force-terrain --displacement <256,0,0> Region10.oar</tt>
<tt>load oar --merge --force-terrain --displacement <256,256,0> Region11.oar</tt>

== Loading a 256x256 region's contents into the middle of a 512x512 sized region ==
If you have an OAR file for a 256x256 region ('LegacyRegion.oar' for instance) and you want to set it into the middle of a 512x512 region with the loaded region rotated by 30 degrees without messing up the rest of the larger region, the command would be:

<tt>load oar --merge --force-terrain --force-parcels --displacement <128,128,0> --rotation 30.0 --rotation-center <128,128,0> LegacyRegion.oar</tt>

Load Oar

2014-02-03T06:22:50Z

Misterblue: Clean up table. Add --no-objects parameter.

Load Oar

2014-02-03T03:51:51Z

Misterblue: description of some of the parameters

Load Oar

2014-02-03T03:06:00Z

Misterblue: Initial version of page for 'load oar'

OpenSim Archives

2014-02-03T02:51:15Z

Misterblue: add references and links to 'Load Oar' page

{{Quicklinks}}

= How do I use the OpenSimulator Archive Function? =

== Introduction ==

The OpenSimulator Archive (OAR) function has existed since OpenSimulator 0.5.9. The facility does a similar job to load-xml2/save-xml2 in that it saves prims so that they can be later reloaded. However, OpenSimulator archives (OAR) go a step further in that they can save all the necessary asset data so that you may fully restore the terrain, region parcel data, the textures of objects and their inventories when loaded onto a completely different system using a different asset database.

== Usage ==

From the region console, one can type

save oar [--noassets] [-h|--home=<url>] [--publish] [--perm=<permissions>] [--all] [<filename>]

to save an OpenSimulator archive. If no filename is given, then the name region.oar is used in the current directory.

'''EXAMPLES:'''
save oar
save oar my.oar
save oar c:/mybackups/filename.oar
save oar oars/11nov.oar

To load an archive, type

load oar [--merge] [--skip-assets] [<location>]

at the console. The location can be a filesystem path (as for "save oar") or an HTTP address to load an oar directly over the web. If no location is given, then the server looks for a file called region.oar in the current directory. See detailed "load oar" documentation at [[Load Oar]].

'''EXAMPLES:'''
load oar
load oar my.oar
load oar my.oar
load oar --merge oars/3rd-party.oar
load oar http://path.to/oarfile.oar

By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. It's like being in the Matrix (when they swap environments), except much slower (all the scene objects are slowly deleted before the new environment is loaded :-)

When an archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSimulator installation's user database. Otherwise, prim ownership will default to the master avatar for the region.

I recommend that you use filenames with the extension '''.oar'''. The filename extension of the download links on this page is '''.tar.gz''' which illustrates that the '''.oar''' format is actually a zipped tar file.

=== Switches ===
==== Saving ====

===== --publish =====

If set, then objects in the saved oar are stripped of owner and last owner information, though not of creator information.

This is useful if you are publishing OARs (rather than using them for backup) where those OARs might be loaded to the same grid from which you published.

As of OpenSimulator 0.7.4, this switch will also strip ownership information from land parcels.

===== --noassets =====

If the --noassets option is specified then the oar will be saved without assets. This can be handy if you're backing up the asset database separately and don't want the expense of including all the assets in each OAR.

===== --home =====

(formerly known as --profile up to 0.7.3)

If the --home option is specified then all names of creators from this world will be appended with links to their home world. It is not required that the service be operational; the information will be added and it will be available in all worlds that import this OAR.

<url> is the URL of this world's profile service.

Example:
save oar --home=http://mygrid.com my.oar

===== --perm =====

If the --perm option is specified then objects with insufficient permissions will not be saved to the OAR. The user whose permissions are checked is the estate owner. This can be useful for grids that allow their customers to export their regions to OARs, because it ensures that exporting to OAR can't be used to bypass content permissions.

<permissions> specifies which permissions are required. It's a string that contains one or more of these characters:
* "C" = Copy
* "T" = Transfer

Example:
save oar --perm=CT my.oar

===== --all =====

If the --all option is specified then the OAR will contain all the regions in the simulator. If this option isn't specified (which is the default) then the OAR will contain only the current region.

==== Loading ====
This is an overview of the most common parameters. There are many more documented at [[Load Oar]].

===== --skip-assets =====

If set, this will not attempt to load any of the assets from the OAR, though all other data will be loaded. This can be useful if you are loading the OAR back into a grid that you know already contains the assets.

===== --merge =====

If the --merge option is specified then the oar will be merged with the existing region objects rather than replace them. The existing terrain, region settings and parcels will be left in place.

== Multi-Region OARs ==

By default, the save-oar command saves only the current region into the OAR (using OAR Format 0.8). However, if the --all option is specified then all the regions in the simulator are saved into a multi-region OAR file (using OAR Format 1.0). This is useful when saving a build that spans multiple regions.

The load-oar command supports both OAR formats (0.x and 1.x). When it's given a 1.x OAR file it loads all the regions in the OAR into the corresponding regions in the simulator, according to their position relative to the root region. If the simulator doesn't have a region in a location that is present in the OAR then that region isn't loaded.

For historical context, see [[Feature_Proposals/Multi-Region_OARs]] and [http://opensimulator.org/mantis/view.php?id=6105 Mantis 6105]

==== OAR Format Compatibility ====

OAR Format 1.0 isn't backwards-compatible, so it can only be read in OpenSim 0.7.5 and above. However, since most current instances of OpenSim can't read this format, there is a transition period in which OpenSim still saves single-region OARs using OAR Format 0.8. This means that the most common behavior (save-oar for a single region) creates OARs that are readable by all instances of OpenSim. The new OAR Format 1.0 is only used when using the --all option.

== Example OARs ==

[http://www.secondlifelab.it/downloads/cyberlandia.tar.gz cyberlandia.tar.gz] - cyberlandia landscape designed by the architect Simone Riccardi aka turboy. Contemporary architecture surrounded with a natural/synthetic context [http://www.flickr.com/photos/8905571@N05/3182585775/ image_1] [http://www.flickr.com/photos/8905571@N05/3171070049/ image_2] (work under [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons by attribution]).

=== OpenVCE 3D Assets OAR ===

The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.

http://openvce.net/resources/downloads/

Get file "opensim-openvce.oar" from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A "full" set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via "opensim-openvce-full.oar". Images of the buildings in place in Opensim are at:
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]

=== Others ===

Please feel free to place links to other environments here, though unfortunately you'll have to host them on some other site.

[http://www.hypergridbusiness.com/2011/06/where-to-get-content-for-opensim/ Where to get content for OpenSim] -- Hypergrid Business page, regularly updated, containing links to major OAR sites. Also has download links to individual OAR files.

[http://www.lindakellie.com/myoars.htm LindaKellie.com]

[http://opensim-creations.com/category/regions/oars/ OpenSimulator Creations]

[http://www.opensimworlds.com/index.php?part=worlds http://www.opensimworlds.com/index.php?part=worlds]

[http://forums.osgrid.org/viewforum.php?f=20 http://forums.osgrid.org/viewforum.php]

== Further Information ==

* [http://justincc.org/blog/category/oars/ http://justincc.org/blog/category/oars/] - various OAR related articles from justincc, including background information and possible future development.

== Use cases ==

Possible current uses are

1. To migrate data from an SQLite region database to one based on MySQL

2. To distribute entire regions to other people.

== Current limitations ==

* Performance is not very good, especially with large archives. This will be addressed in the future
* Loading large OARs using the default SQLite database plugin will take a very very long time (in the order of many hours). I highly recommend that you switch to MySQL if you want to load large archives.

== OAR Format ==

The region [[OpenSim Archives|OpenSimulator Archive (OAR)]] format is designed with three aims in mind:

# Make it easy for people to read and change individual objects, assets, etc. within an archive.
# Make it easy to compose two region archives into a single region archive.
# Make it easy to compose archives from scratch.

Therefore, all the different entities (assets, objects, terrains, etc.) are packaged in individual files (e.g. one for each asset) with human readable filenames and machine readable extensions (e.g. .jp2 for textures, .txt for notecards).

* [[OAR Format 0.1]]
* [[OAR Format 0.2]]
* [[OAR Format 0.6]]
* [[OAR Format 0.7]]
* [[OAR Format 0.8]] - the current default OAR save format.
* [[OAR Format 1.0]]

== FAQ ==

1. What is this .tar.gz format you are using for the internal OAR format? Why not zip?

.tar.gz is a standard unix way of zipping up files into a single larger compressed file for distribution. Windows users should be able to open these files using freeware programs such as [http://www.7-zip.org/ 7-zip].

I'm using .tar.gz because all the zip (and tar) libraries for .net are licensed either under the GPL (with exception) or under the MSPL. Unfortunately, not all members of the OpenSimulator development team are comfortable with the MSPL, so these libaries are not currently an option. It is also significantly easier to write code to create and read tar archives than zip archives.

Also, if you're only ever loading and saving oars (rather than pulling them apart and putting them back together), then you don't need to worry about the internal format at all :)

2. Can you load and save multiple regions to an archive?

Yes, since OpenSim 0.7.5. See [[OpenSim Archives#Multi-Region OARs]]

3. Can you load and save parts of a region to an archive?

Not yet.

== Bugs ==

* Due to a possible bug in the Mono 1.2.4 libraries, this feature may cause a debug dump when used (the problem appears to be in writing out a compressed stream). Mono 1.2.6 is okay. Since Mono 1.2.4 is fairly old now, this bug will not be addressed.

== Current Status ==

Operational. Bug reports are appreciated [[User:Justincc|Justincc]] 14:53, 14 September 2009 (UTC)

Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please don't rely on these archives as the only backup for regions.

[[Category:Users]]
[[Category:Support]]
[[Category:Tech Reference]]
[[Category:Help]]
[[Category:Configuration]]
[[Category:Getting Started]]
[[Category:Development]]

Varregion

2014-02-02T15:01:20Z

Misterblue: Updated confusing restriction on adjacent regions

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There seems to be a viewer problem where, if regions of different size are within view distance, crashes can happen. Consider having regions of only the same size 'in view'. Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. As of 20140128, BulletSim has been modified to force heightmap terrain implementation if region size is greater than 256 on any side. The setting can be forced by adding to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, 'load oar' now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four
OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel oar01.oar
load oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel oar10.oar
load oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel oar11.oar
</pre>

Note the new "--forceterrain" and "--forceparcel" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

As of January 27, 2014, varregion is a feature of the 'master' repository branch.

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region. (mostly done)
* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
* Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2014-01-30T16:42:22Z

Misterblue: /* Restrictions */ comment about BulletSim forcing terrain heightmap implementation for large regions

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region). Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. As of 20140128, BulletSim has been modified to force heightmap terrain implementation if region size is greater than 256 on any side. The setting can be forced by adding to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, 'load oar' now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four
OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel oar01.oar
load oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel oar10.oar
load oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel oar11.oar
</pre>

Note the new "--forceterrain" and "--forceparcel" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

As of January 27, 2014, varregion is a feature of the 'master' repository branch.

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region. (mostly done)
* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
* Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2014-01-30T16:39:44Z

Misterblue: /* Implementation Notes */ remove 'branch in the repository' since varregion is now in mastert

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region). Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, 'load oar' now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four
OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel oar01.oar
load oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel oar10.oar
load oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel oar11.oar
</pre>

Note the new "--forceterrain" and "--forceparcel" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

As of January 27, 2014, varregion is a feature of the 'master' repository branch.

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region. (mostly done)
* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
* Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2014-01-27T17:53:40Z

Misterblue: removed map problems from /* Things Known to be Broken */

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region). Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, 'load oar' now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four
OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel oar01.oar
load oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel oar10.oar
load oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel oar11.oar
</pre>

Note the new "--forceterrain" and "--forceparcel" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

===Branch in the Repository===
As of January 17, 2014, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region. (mostly done)
* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
* Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2014-01-20T05:11:56Z

Misterblue: Updated OAR section. Updated list of TODO and 'Known Not To Work'

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region). Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==
The objects and terrain are stored in an OAR file as if it was one region. That is, if you save a 1024x1024 region in an OAR file, you can later restore the objects and terrain into a 1024x1024 sized region. If you load an OAR file from a smaller region into a larger region, the unspecified terrain space will default to 25m.

To make conversion to varregions easier, 'load oar' now has a '--displacement "<x,y,z>"' parameter. This displaces all of the objects and the terrain from the oar file when loading them into the new region. For instance, say you have four
OAR files from four adjacent 256x256 regions (oar00.oar, oar01.oar, oar10.oar, and oar11.oar). You create a new 512x512 varregion named 'bigregion'. The following commands place the four regions of objects, terrains and parcels
into the new larger region:

<pre>
change region bigregion
load oar oar00.oar
load oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel oar01.oar
load oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel oar10.oar
load oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel oar11.oar
</pre>

Note the new "--forceterrain" and "--forceparcel" parameters. "--merge", used by itself, is for merging together the objects from multiple OARs. Merging also suppresses the loading of terrain and parcel data which is just what you want when merging objects. But, if loading multiple OARs to create a new, larger region, the terrain and parcel information must be loaded. Thus the new parameters.

==Things Known to be Broken==
* There is some problem with teleporting in an out of larger region. It works for some configurations and not others.
* The viewer Map dialog cannot specify locations outside of 256x256 in larger regions
* While adjacent regions are usually viewable, sometimes they are not. They appear when you cross over into the region.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Implementation Notes==

===Branch in the Repository===
As of January 17, 2014, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region. (mostly done)
* ITerrainLoader implementations (mostly done)
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
* Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New overlay types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's
** consider creating structures for world and region coordinates so there can be compile time checking

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2014-01-19T23:53:13Z

Misterblue: Update to restrictions and information on loading terrain with console commands

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256 and less than or equal to 8192.
* The dimensions must be square (as of 20131104)
* Adjacent regions must be the same size. For instance, you can have multiple 512x512 regions adjacent (and see into the other region and border cross). There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region). Remember that the region coordinates are specified in 256m region count so a group of four 512x512 regions would be specified at 8000/8000, 8000/8002, 8002/8000, and 8002/8002, for instance.
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
The usual terrain console commands work with varregions. If you have set up a larger region, you can load BMP/RAW/PNG heightmap files of the dimensions of the region and fill the whole region. For instance, a 1024x1024 region terrain would be completely initialized by "terrain load 1024.bmp" if '1024.bmp is a 1024x1024 bitmap.

==Varregions and OAR Files==

TODO: Discussion on saving and restoring varregions.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Things Known to be Broken==
* Rezzing a prim from inventory at greater than <256,256>
* Saving/restoring heightmap when restarting region
** Start large region, edit large part, restart region, see that edits are not saved

==Implementation Notes==

===Branch in the Repository===
As of November 4, 2013, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region.
* ITerrainLoader implementations
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
*Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* Blog entry on moving terrain info into class
** Moving class from OpenSim.Region.Framework into OpenSim.Framework
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New layer types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Ward3DMap/TerrainSplat.cs is filled with "256"s.
** Doesn't even bother to use the symbolic constants.
* Warp3DMap/Warp3DImageModule.cs is filled with "256"s
* WorldMap/WorldMapModules.cs is filled with "256"S
* Services/MapImageService/MapImageService.cs relies on a constant width of 256
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion/Protocol

2013-12-29T18:37:14Z

Misterblue: add HelloNeighbor sim-to-sim message

'''Varregion Protocol'''

__TOC__
The communication protocols need extensions to pass around the size of the regions. These extensions are in the simulator to client protocols, the simulator to simulator protocols and the simulator to grid service protocols. This page documents most of the changes.

==Simulator to Client Protocol==

* EnableSimulator event message: add integers 'RegionSizeX' and 'RegionSizeY'
* CrossRegion event message: add integers 'RegionSizeX' and 'RegionSizeY' to 'RegionData' section.
* TeleportFinish event message: add integers 'RegionSizeX' and 'RegionSizeY' to 'Info' section.
* EstablishAgentCommunication event message: add integers 'region-size-x' and 'region-size-y'.

===Terrain Patch===
===Cloud Patch===
===Wind Patch===

==Simulator to Grid Service Protocol==

==Simulator to Simulator Protocol==

* HelloNeighbor message: add 'region_size_x' and 'region_size_y' to region info.

Varregion/Protocol

2013-12-29T17:46:35Z

Misterblue: info on EstablishAgentCommunication

Varregion/Protocol

2013-12-29T17:44:53Z

Misterblue: event message additions

'''Varregion Protocol'''

__TOC__
The communication protocols need extensions to pass around the size of the regions. These extensions are in the simulator to client protocols, the simulator to simulator protocols and the simulator to grid service protocols. This page documents most of the changes.

==Simulator to Client Protocol==

* EnableSimulator event message: add integers 'RegionSizeX' and 'RegionSizeY'
* CrossRegion event message: add integers 'RegionSizeX' and 'RegionSizeY' to 'RegionData' section.
* TeleportFinish event message: add integers 'RegionSizeX' and 'RegionSizeY' to 'Info' section.

===Terrain Patch===
===Cloud Patch===
===Wind Patch===

==Simulator to Grid Service Protocol==

==Simulator to Simulator Protocol==

Varregion

2013-12-29T16:25:13Z

Misterblue: add link to Singularity commit for varregion

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256
* The dimensions must be square if used with Singularity (as of 20131104)
* There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region)
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
TODO: discussion of reading in terrain information

==Varregions and OAR Files==
TODO: Discussion on saving and restoring varregions.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Things Known to be Broken==
* Rezzing a prim from inventory at greater than <256,256>
* Saving/restoring heightmap when restarting region
** Start large region, edit large part, restart region, see that edits are not saved

==Implementation Notes==

===Branch in the Repository===
As of November 4, 2013, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region.
* ITerrainLoader implementations
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
*Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* Blog entry on moving terrain info into class
** Moving class from OpenSim.Region.Framework into OpenSim.Framework
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New layer types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Ward3DMap/TerrainSplat.cs is filled with "256"s.
** Doesn't even bother to use the symbolic constants.
* Warp3DMap/Warp3DImageModule.cs is filled with "256"s
* WorldMap/WorldMapModules.cs is filled with "256"S
* Services/MapImageService/MapImageService.cs relies on a constant width of 256
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>
* Singularity commit for varregion: https://github.com/singularity-viewer/SingularityViewer/commit/ad8ea07a

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion/Protocol

2013-12-29T16:21:56Z

Misterblue: structure of page

Varregion

2013-12-29T16:16:52Z

Misterblue: Add link to varregion protocol page

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

A growing list of protocol changes to implement "varregion" is at [[varregion/Protocol|Varregion Protocol]].

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256
* The dimensions must be square if used with Singularity (as of 20131104)
* There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region)
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
TODO: discussion of reading in terrain information

==Varregions and OAR Files==
TODO: Discussion on saving and restoring varregions.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Things Known to be Broken==
* Rezzing a prim from inventory at greater than <256,256>
* Saving/restoring heightmap when restarting region
** Start large region, edit large part, restart region, see that edits are not saved

==Implementation Notes==

===Branch in the Repository===
As of November 4, 2013, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region.
* ITerrainLoader implementations
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
*Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* Blog entry on moving terrain info into class
** Moving class from OpenSim.Region.Framework into OpenSim.Framework
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New layer types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Ward3DMap/TerrainSplat.cs is filled with "256"s.
** Doesn't even bother to use the symbolic constants.
* Warp3DMap/Warp3DImageModule.cs is filled with "256"s
* WorldMap/WorldMapModules.cs is filled with "256"S
* Services/MapImageService/MapImageService.cs relies on a constant width of 256
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2013-12-29T16:12:06Z

Misterblue: Add section on region crossing.

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256
* The dimensions must be square if used with Singularity (as of 20131104)
* There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region)
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
TODO: discussion of reading in terrain information

==Varregions and OAR Files==
TODO: Discussion on saving and restoring varregions.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

===Sensing Border Crossing===
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: <tt>Scene.PositionIsInCurrentRegion(Vector3 pos)</tt> and then <tt>EntityTransferModule.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. (Side note: <tt>GetRegionContainingWorldLocation</tt> should really be a function on <tt>IGridService</tt> but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on <tt>IGridService</tt>, in <tt>EntityTransferModule</tt> and a bunch of bookkeeping in <tt>Scene</tt>. This too should be cleaned up.

==Things Known to be Broken==
* Rezzing a prim from inventory at greater than <256,256>
* Saving/restoring heightmap when restarting region
** Start large region, edit large part, restart region, see that edits are not saved

==Implementation Notes==

===Branch in the Repository===
As of November 4, 2013, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Consolidate neighbor region computation code (Scene, EntityTransferModule and IGridService all have 'get neighbor' code)
* Clean up/eliminate border list creation and use code
* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region.
* ITerrainLoader implementations
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
*Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* Blog entry on moving terrain info into class
** Moving class from OpenSim.Region.Framework into OpenSim.Framework
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New layer types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Ward3DMap/TerrainSplat.cs is filled with "256"s.
** Doesn't even bother to use the symbolic constants.
* Warp3DMap/Warp3DImageModule.cs is filled with "256"s
* WorldMap/WorldMapModules.cs is filled with "256"S
* Services/MapImageService/MapImageService.cs relies on a constant width of 256
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2013-12-27T01:17:33Z

Misterblue: fixed 2618 to 2816 number wrongness

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256
* The dimensions must be square if used with Singularity (as of 20131104)
* There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region)
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

for llRezObject to work beyond 256m set "ScriptDistanceLimitFactor = 52.0" (for 512mx512m) in the [Xengine] section of OpenSim.ini.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2816x2816 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
TODO: discussion of reading in terrain information

==Varregions and OAR Files==
TODO: Discussion on saving and restoring varregions.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

==Things Known to be Broken==
* Rezzing a prim from inventory at greater than <256,256>
* Saving/restoring heightmap when restarting region
** Start large region, edit large part, restart region, see that edits are not saved

==Implementation Notes==

===Branch in the Repository===
As of November 4, 2013, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region.
* ITerrainLoader implementations
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
*Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* Blog entry on moving terrain info into class
** Moving class from OpenSim.Region.Framework into OpenSim.Framework
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New layer types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Ward3DMap/TerrainSplat.cs is filled with "256"s.
** Doesn't even bother to use the symbolic constants.
* Warp3DMap/Warp3DImageModule.cs is filled with "256"s
* WorldMap/WorldMapModules.cs is filled with "256"S
* Services/MapImageService/MapImageService.cs relies on a constant width of 256
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2013-11-26T16:59:06Z

Misterblue: note on setting 'CombineContiguousRegions=false' when converting from mega-regions

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256
* The dimensions must be square if used with Singularity (as of 20131104)
* There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region)
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

If converting from a mega-region, remember to set "<tt>CombineContiguousRegions = false</tt>".

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2618x2618 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
TODO: discussion of reading in terrain information

==Varregions and OAR Files==
TODO: Discussion on saving and restoring varregions.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

==Things Known to be Broken==
* Rezzing a prim from inventory at greater than <256,256>
* Saving/restoring heightmap when restarting region
** Start large region, edit large part, restart region, see that edits are not saved

==Implementation Notes==

===Branch in the Repository===
As of November 4, 2013, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region.
* ITerrainLoader implementations
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
*Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* Blog entry on moving terrain info into class
** Moving class from OpenSim.Region.Framework into OpenSim.Framework
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New layer types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Ward3DMap/TerrainSplat.cs is filled with "256"s.
** Doesn't even bother to use the symbolic constants.
* Warp3DMap/Warp3DImageModule.cs is filled with "256"s
* WorldMap/WorldMapModules.cs is filled with "256"S
* Services/MapImageService/MapImageService.cs relies on a constant width of 256
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2013-11-25T21:24:54Z

Misterblue: Notes on viewer work

'''Varregion'''

__TOC__
"Varregion" is a feature of OpenSimulator that enables region sizes larger than 256x256. The region is just larger so it acts like a regular region but with borders farther apart.

The implementation uses the [http://aurora-sim.org Aurora] large region protocol extensions so the existing [http://firestormviewer.org Firestorm] and [http://singularityviewer.org Singularity] Aurora support will now work for OpenSimulator.

==Restrictions==
Some restrictions apply:
* The dimensions must be a multiple of 256
* The dimensions must be square if used with Singularity (as of 20131104)
* There must be no adjacent regions (at least one empty 256m space bordering all sides of the large region)
* You must use BulletSim (as of 20131104, ODE has not been modified for varregions)
** You must use BulletSim's height map terrain implementation. Add to your INI files:
<pre>
[BulletSim]
TerrainImplementation = 0
</pre>

==Configuration==
The size is be specified in the <tt>Region.ini</tt> file:
<pre>
[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
</pre>
If size is not specified, it will, of course, default to the legacy size of 256.

If the given dimensions do not fit the restrictions, acceptable values are computed and warning and error messages are output into the log.

The terrain heightmap is stored in the database as an array of 'shorts' (two bytes) so, if you have a very large region you might need to set the database maximum size to a larger value. For instance, a 2618x2618 region (11x11 legacy regions) turns into a 56 megabyte heightmap and, for MySQL, you would need to set <tt>max_allowed_packet</tt> to something like 64M.

==Loading Terrain==
TODO: discussion of reading in terrain information

==Varregions and OAR Files==
TODO: Discussion on saving and restoring varregions.

==Implementation Discussion==
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.

===TerrainData===
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
<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
stack (LLClientView) because
<tt>TerrainChannel</tt>
is defined as part of
<tt>OpenSim.Region.Framework</tt>
which is not visible to the protocol code.

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.

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.

There is one subclass of <tt>TerrainData</tt>: <tt>HeightmapTerrainData</tt> which keeps the terrain as a compressed heightmap. The height of each point is stored as a <tt>short</tt> which is <tt>height * compressionFactor</tt> where <tt>compressionFactor</tt> is usually "100". This creates a compact storage of the terrain heights with two decimal points of resolution.

The LLLP ("Linden Lab Legacy Protocol") sends terrain height data in
compressed "patches" of 16x16 areas of the terrain
height. This is a protocol feature that is implemented in <tt>TerrainChannel</tt>.
I feel that underlying protocol optimizations shouldn't appear up the
stack so, in creating <tt>TerrainData</tt>, I tried to hide terrain patches.
I mean, someday terrain will be generalized meshes. Right?

===Terrain in the Database===
Previously, terrain height maps were saved in the database as a blob of 256x256 doubles. To have different region sizes, that format had to change. There is an existing database field <tt>revision</tt> that stored the time the terrain was saved. This revision information wasn't used for anything so this field was co-opted to contain a revision code for the height field blob.

There are three forms for the height map blob: legacy, compressed2D and regular2D. "legacy" is, of course, the previous 256x256 collections of doubles. "regular2D" contains the X, Y dimensions and enough floats for that area's heights. "compressed2D" contains the X,Y and compressionFactor followed by enough shorts for the height map.

The database readers and writers default to the legacy format and, if the region happens to have the dimensions 256x256, it is stored using the legacy format. This is an attempt to keep downward compatibility.

All of the database modules (MySQL, SQLite, MSSQL and PSQL) have been modified to store terrain this new way.

==Things Known to be Broken==
* Rezzing a prim from inventory at greater than <256,256>
* Saving/restoring heightmap when restarting region
** Start large region, edit large part, restart region, see that edits are not saved

==Implementation Notes==

===Branch in the Repository===
As of November 4, 2013, the varregion implementation is in the 'varregion' branch in the OpenSimulator git source repository. This branch is periodically merged with the 'master' branch so it is roughly the 'master' branch plus the varregion functionality.

Since the varregion implementation is supposed to be 100% downward compatible, this branch will eventually be merged into the 'master' branch once the not-breaking-existing-configuration feature is tested and verified.

In an existing clone of the OpenSimulator git source repository, do:
<pre>
# setup local branch that tracks the remote repository branch
git branch --track varregion origin/varregion
# update the working set with the varregion sources
git checkout varregion

# after you are done testing varregion, restore the 'master' sources with:
git checkout master
</pre>

===Stuff to Work On===
What follows are notes I am making as things that might need work are found in OpenSimulator.

* Region handles are world coords and also the base of the region
** verify that everyone who converts coords to handle (Util.RegionWorldLocToHandle) is supplying the base of the region.
* ITerrainLoader implementations
** How to handle tiles.
** How to handle large regions sizes.
** Terrain/FileLoaders/*.cs all return an ITerrainChannel
** Need to fix all the file reader/writers
** FileLoaders/LLRAW.cs has several "256"s rather than constant references
* Teleporting: should be able to teleport to anywhere in a large region
** "MyRegion/550/687/40"
* HG code needs to allow addresses anywhere into large regions
* When GridService return adjacent regions, make sure it does the right thing for large regions
* Consider moving terrain XML serialization into TerrainData
* Consider removing all instances of TerrainChannel.GetFloatsSerialized()
** Replace with passing around TerrainData
* Code in EntityTransferModule that checks distance to decide of to make new connection
** search for references to 'Constants.RegionSize'
** Consider removing the distance code and replacing with call to grid service
* WorldMapModule.cs does a lot of arithmetic depending on constants that are really Contants.RegionSize
* Util.IsOutsideView uses Constants.RegionSize. Is use is ScenePresence a problem?
** Used in ScenePresence.AdjustKnownSeeds()
** Is this another instance like EntityTransferModule that needs to goto the grid service?
*Move all the short[] heightmap representation stuff into TerrainData.cs (partially done)
** Is it possible to move all the patch stuff out of TerrainModule/TerrainChannel?
** Clean up the use of m_revert. It looks like it is not saved after terrain is modified.
* Need to look through RegionCombinerModule.cs and see what safety checks are needed
** Maybe just prevent combination if not legacy region size
* In LSL_Api.cs, llEdgeOfWorld() does some neighbor computation. Check for ok'ness.
* Blog entry on moving terrain info into class
** Moving class from OpenSim.Region.Framework into OpenSim.Framework
* LandManagementModule.SendParcelOverlay sends land sale/ownership info for 4x4m areas
** Looks like it expects to send exactly one 1024 byte block (for the 256x256 legacy region
** Check viewer code for what will happen for larger regions
* The code for cloud and wind needs to be enhanced for larger regions
** New layer types added
* LLClientView.SendMapBlockSplit() needs to have region size to send with the map info
* Ward3DMap/TerrainSplat.cs is filled with "256"s.
** Doesn't even bother to use the symbolic constants.
* Warp3DMap/Warp3DImageModule.cs is filled with "256"s
* WorldMap/WorldMapModules.cs is filled with "256"S
* Services/MapImageService/MapImageService.cs relies on a constant width of 256
* Region/Framework/Scenes/Tests/BorderTests.cs might need work if non-standard regions are tested
* Verify terrain tests still work (for 256m regions)
* Region coords are sometimes 'int' and sometimes 'uint' with conversions EVERYWHERE
** pass over everything and convert region coordinates it 'uint's

====Viewer====
* LLSurface is wired to expect adjacent regions of same size
* Terrain surface image is sized with a 'static": " static S32 sTextureSize; // Size of the surface texture"
* From FreeNode:#SingularityViewer 20131125:
<pre>
<Aleric> radams1, SianaGearz, frnic : I couldn't help myself doing a profile anyway.. The reason the viewer is slow is because it's busy "drawing" the terrain. "drawing" between quotes because my guess is that it is trying to draw ALL terrain and then clip that afterwards to the frustrum...
<Aleric> So, this could be greatly improved by disregarding terrain way way earlier when it is beyond the drawing range anyway.
<SianaGearz> OK
<Aleric> I disabled all rendering, even added a 'return' in terrain render
<Aleric> but.. no improvement of FPS!
<frnic> oops
<Aleric> LLSurfacePatch::updateVisibility() is still eating a lot of cpu.
<Aleric> LLSurface::updatePatchVisibilities does 97% of the calls to LLSurfacePatch::updateVisibility
<Aleric> which then spends most of it's time calling LLCamera::AABBInFrustumNoFarClip
</pre>

==Testing==
* Terrain/parcel operations
** Default 256 standalone region
*** Clean database. Start single standalone region. Verify 'pimple' region. Verify one parcel. Flatten region.
*** Create parcels adjacent to each edge and standalone in middle. Change names of each parcel and verify. Restart simulator and verify parcels exist and work correctly.
*** Save five parcel region as OAR. Clear database. Restart region. Load oar. Verify 5 parcels of correct location, name and features.
** Adjacent 256 standalone regions
** 768x768 standalone region
** Changing land from 256 to 768
* Teleporting
* Adjacency
* Hypergrid

Varregion

2013-11-24T20:08:45Z

Misterblue: Region coords to uints work item

Varregion

2013-11-24T20:04:40Z

Misterblue: more stuff to work on

Varregion

2013-11-10T20:04:59Z

Misterblue: note on setting up database parameters for large heightmaps

Varregion

2013-11-10T19:46:03Z

Misterblue:

Varregion

2013-11-10T17:56:51Z

Misterblue:

Varregion

2013-11-10T17:18:18Z

Misterblue: adding testing info

Varregion

2013-11-07T13:58:35Z

Misterblue: Add note about SendParcelOverlay

Varregion

2013-11-06T06:25:02Z

Misterblue:

Varregion

2013-11-05T23:41:30Z

Misterblue: Note on using heightmap BulletSim terrain implementation

Varregion

2013-11-05T22:08:30Z

Misterblue: Add instructions for varregion branch in source repository