Load Oar 0.9.0+

= Load Oar Console Command =

This page provides information on the 'load oar' console command from OpenSimulator version 0.9.0 onwards.

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, terrain and parcels already in the region.

Note: If you are using a version of OpenSimulator less than 0.9.0 then please see the original Load Oar page.

Parameters
The load oar command in OpenSimulator version 0.9.0 onwards has the format:

load oar [parameters] OARFILE

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

Notes on OpenSim Physics
BulletSim Mesh objects are not converted to ubODE Mesh objects, not the other way around.

Regions that were created with BulletSim Physics sometimes do not work with simulators that run with ubODE Physics.

Collada Mesh objects have to be uploaded again when the physics change.

Notes On Regions of Different Sizes
With the addition of regions that have a size that can be a multiple of 256x256 (i.e. a Varregion) there is the possibility of loading OARs to and from regions of different sizes. The load oar command now fully supports this and will load both smaller regions into larger ones and (cut out) pieces of larger regions into smaller ones. Parcel data is now handled correctly too.

= 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:

load oar NewRegion.oar

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:

change region BiggerRegion load oar Region00.oar load oar --merge --force-terrain --force-parcels --displacement <0,256,0> Region01.oar load oar --merge --force-terrain --force-parcels --displacement <256,0,0> Region10.oar load oar --merge --force-terrain --force-parcels --displacement <256,256,0> Region11.oar

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:

load oar --merge --force-terrain --force-parcels --rotation 30 --displacement <128,128,0> LegacyRegion.oar

Loading part of a 512x512 VarRegion into a standard 256x256 sized region
Say you have a 512x512 Varregion with an island in the middle that's about the size of standard region (256x256m), you could use the following command to rotate it, cut it out and place it in the standard region:

load oar --rotation 90 --bounding-origin <128,128,0> --bounding-size <256,256,4096> VarRegion.oar</tt>

= Visualising how it works =

The new 'load oar' parameters work in the following order and this is *important to remember*:

--rotation</tt> -359 to +359 degress. The source region is rotated by the desired amount anticlockwise in degrees. If not specified then no rotation takes place. The coordinates within the source region are the same after rotation, so for example the middle of a 256x256 region will still be at <128, 128> after a 45 degree rotation, but the original SW corner will now be at new coordinates <128, -53>.

--bounding-origin <x, y, z></tt> --bounding-size <x, y, z></tt> The (possibly rotated) source region is then cropped to a cube or rectangular cuboid defined by the coordinates given.

The resultant cuboid will then be placed at <0, 0, 0></tt> in the destination region unless modified by:

--displacement <x, y, z></tt> The rotated and cropped data is offset into the destination region by this amount.

Some things to note:

--rotation</tt> applies to all of the source region's data, that is terrain, parcels and objects (prims). Both terrain, and even more so, parcels do not rotate well using arbitary rotations like 45 degrees as the edges will become jagged, but it's still supported.

In Pictures
The following four diagrams attempt to show examples of the work flow for various combinations of source and destination region sizes:

http://imagebin.ca/2NZGoAZffOgl/standard-to-standard.png

http://imagebin.ca/2NZJfk0nsoap/standard-to-var.png

http://imagebin.ca/2NZJxXOH6lue/var-to-standard.png

http://imagebin.ca/2NZKAL35VFdk/var-to-var.png