After a long hiatus, I’ve decided to start the blog again. I have lots of design stuff I want to do around virtual worlds and I need a place to put it.

I ported the old blog from WordPress to Jekyll and had to learn Markdown along the way. Someday I’ll go off on my rant on why I hate Markdown and its cousin YAML but that is for another blog entry. They are what they are and lots of people are using them so, with grumbling, I must adapt.

The port from WordPress to Jekyll wasn’t all smooth. Jekyll supplies a conversion program that converts the WordPress database into Jekyll post entries but I found that I couldn’t get the right combination of Ruby libraries working to make that happen. The result was my own conversion routine written for C#. It’s only in C# because, at the moment, I have a full development environment for it running and, secondly, I could include the DLLs so there are no dependencies to random old versions of external libraries. If you are in a similar spot, checkout jekyll-importws-cs.

The base theme for the Jekyll version of the blog is jekyll-clean by Scott Emmons. A good starting point that I have since taken many liberties with. I like his philosophy of not including every cool library and feature in the world. This makes for easy modification and support.

Updated OpenSimulator BulletSim with fixes for Windows crashes (mantis 7371) and building physical linkset problems (mantis 7191). The former took a while as I managed to mangle by Visual Studio C++ build environment. The fix for that was just upgrading everything (after power cycling, of course).

Adding the varregion feature to OpenSimulator caused me to bump into the mega-region code. The most recent commits to OpenSimulator are a rewrite of some of that code to make it easier to understand and eliminate some complexities (like creation and testing of complex border classes).

There have been some Mantis entries saying how mega-regions were broken but now that should be better. This is, previous mega-region configurations should now properly test for border crossings within the mega-region.

One side effect of the changes is to allow combining varregions into mega-regions. Although not completely tested (I figure there are some problems with maps and TPing with maps), you can mega-region’ize adjacent, same-sized large regions. Not for the faint-of-heart, but a configuration possibility.

I have been working on several Mantis entries for varregion and mega-regions and getting those problems resolved. If you find something that doesn’t work, Mantis away.

– mb

The ‘varregion’ source branch in the OpenSimulator source repository has been updated this last week to fix a lot of the existing varregion problems. Some things that now work:

Teleporting to and from large regions using Singularity does not crash any more. There are still some problems with using the map to select teleport locations greater than 256 but that is being worked on.

Adjacent large regions now works. For instance, you can create adjacent 512x512 regions to reduce the number of border crossings. 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.

Another feature of adjacent large regions is, if you set your draw distance, you can see into the other regions.

Large regions show up in the map correctly. In fact, a lot of work was done on the Warp3D maptile rendered to make it faster, more functional (it now does meshes and prim textures[1]) and to not crash.

These changes are in the ‘varregion’ source branch which is in-sync with the master branch. More testing will make it get into the master branch quicker so test and file those manti.

[1] Check out the new parameters under the “[Map]” section in Opensim.ini.example.

I wanted to make the creation of varregions easier so I added some parameters to the ‘load oar’ simulator command. But, while I was in the area, I got a little carried away.

For varregions, ‘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:

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

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.

While I was in the neighborhood, I also added ‘–rotation degrees’ and ’–rotationcenter “<x,y,z>”’. These apply a rotation to all the objects in the OAR file before they are displaced and placed in the new region. The rotation center is relative to the original OAR and defaults to “<128,128,0>”. At the moment, the rotation is applied only to objects and not the terrain or parcels.

Say you have a 512x512 region named ‘bigregion2’ and an oar file with buildings named ‘buildings.oar’ which is from a 256x256 region. The following places the buildings big region rotated 30 degrees without modifying the terrain:

change region bigregion2
load oar --merge --displacement "<128,128,0>" --rotation 30 buildings.oar

The caveat to all this is that it is only in the ‘varregion’ source branch. More testing will make it get into the master branch quicker so test and file those manti.

And have fun with those OAR files.