Testing the blog waters

Hi. I have been asked to pick up this blog and do a weekly report on OpenSimulator. This is my first test posting as I see if I can actually drive wordpress.

I’m one of the Core Developers and the OSGrid Director and have been around since about r500 in the Spring of 2007. Many of those on IRC know me as “ckrinke”. Those on OSGrid know me as “Charles Krinkeb”. My real-life name is “Charles Krinke”.

OpenSim Docs, OpenSim Nightly Builds

This is just a quick post to let everyone know we’ve added two new resources to the OpenSimulator.org website. The first, we’ve added Doxygen programming docs covering the entire OpenSim codebase – these will be refreshed periodically with every major release that we do. You can find the docs at http://docs.opensimulator.org/

The second major thing we’ve done lately is introduce a Continuous Integration (CI) server which produces regular builds and monitors for build failures. Right now it is configured to produce a new build after every commit – the result of which will be copied to our new builds repository at http://builds.opensimulator.org/

Enjoy – and thanks to everyone involved who helped get this setup!


SVN Module – or, DIY Rollbacks and Backups.

So, earlier this week I committed a prototype of something I have been musing on for DeepThink internally into the OpenSim SVN. It’s a shared region module which acts sort of as a non-realtime datastore. The purpose of which is to allow you to store (and load) region backups to a SVN server.

The SVNModule will use the also-new ‘export’ module, to serialise your region to a collection of XML and binary files that make up your region (XML for anything human editable, ie – object data. Binary for non-human editable components such as terrain data)

It’s worth noting you can use “load-xml2” on the objects.xml file, and “terrain load heightmap.32” to import those parts back into the region from outside the SVN server.

Before I continue, I should point out that this is a very untested module – I have only confirmed it works under Windows 32bit, and has not gone under any sort of sufficient testing for large scale use, yet. Proceed at your own risk.

To setup the module, copy the [SVN] section from OpenSim.ini.example to your OpenSim.ini – make sure ‘enabled = true’ is set, and the other details are in there. At the moment it will only work with svn:// and http[s]:// repositories. I am working on SSL/SSH wrapped repositories at the moment, but it is more difficult to implement, so may take some time. You can use any SVN URL (it doesnt have to be the root of a SVN repository). I recommend that you use one subdirectory per server unless you have a high speed link between all your servers — this is because if all servers share a directory, checkout times will include updates from every directory (something on my agenda to implement a workaround).

Start your sim up, and check to make sure you get [SVNBACKUP]: messages on your console, as long as no errors are thrown (of type SvnException) you should be good. If you see an error – there is help text buried in the exception.

Presuming all has gone well, there are several console commands worth reviewing:

svn save – saves a current copy of all your regions to SVN.
svn load – loads SVN head and imports it to your region.
svn load <revision> – loads a specified revision
svn load-region <name> – loads a specified region at head revision
svn load-region <name> <revision> – loads a specified region from a specified SVN revision.

Automatic backups (periodic saves) and several other features are on the cards, but have not yet been implemented. Ideally I would like to convert this to a datastore-style adapter that imports changes live (so you can rollback individual changes), but that may be unwieldy. Some thought is required on the matter.


OpenSim Weekly News – week ending Saturday 12th April 2008

Hello there. For the past couple of weeks I’ve posted a weekly OpenSim development summary to this group blog. However, I’ve realized that I’m a shameless traffic whore (and it does take a surprising amount of time to write the post!), so today’s summary and future editions will be posted to my own blog here. Corrections and comments are still welcome.

OpenSim Weekly News – week ending Saturday 5th April 2008

This week in OpenSim…

  • Teravus fixed a bug which caused problems with region interoperability between Windows and Linux servers. Hurrah for platform neutrality!
  • Adam made more changes to terrain commands.
  • I made a change where the “Take Copy” option in the pie menu really does take a copy of the object rather than the object itself.
  • I made a change so that prims copied using the shift copy method now properly retain their script contents.
  • Teravus updated our embedded OpenDynamicsEngine library. This may have an impact on physics stability when using this engine.
  • sdague reorganized the database namespaces to be OpenSim.Data.* rather than OpenSim.Framework.Data.*. If you’re having trouble running OpenSim, try changing all your references in OpenSim.ini and all the bin/*.xml configuration files (if you are running a grid) to point to the new namespace.
  • I made a change so that the scripts contained in all linked prims can now be properly edited using the ‘Edit linked parts’ option.
  • We had a small hiccup with inventory as the underlying mechanism has changed to CAPS in the latest Linden client. But with lots of preparatory work by MW, Teravus and a very small fix by myself, inventory appears to be working again in the latest client! However, we do still appear to have all the inventory bugs which existed before the client 🙂
  • Teravus changed the default packet output queue throttle settings. This should help any problems people have been seeing with prims which appear to be missing when they login (but can still be bumped into!). It should also help with land block problems.

New Terrain Commands

Some time ago, I reworked the terrain engine into a new shiny module. This module is now nearing completion as far as core features go – from here on in, new features will be towards things like v2.0 goals. Since it is now working correctly for most things, I have reworked the console commands back in – with some improvements. Many of you noticed in the last two-three weeks the old commands were ‘depreciated’ – these should now be working again as of r4039/4040.

So, a little guide.

First – I’ve created a new ‘command manager’ which also handles console commands, the goal of here is to enable LSL/Scripting functions for every console command, as well as allowing proper syntax-checked console input plus help. The short of this is you can now type “<module> <command> help” for help about a particular command, or “<module> help” for a list of valid commands. At the moment only “terrain” is supported for modules.

Region# :
terrain help
17:48:06 - ===Terrain===
17:48:06 - * load - Loads a terrain from a specified file.
17:48:06 - * load-tile - Loads a terrain from a section of a larger file.
17:48:06 - * save - Saves the current heightmap to a specified file.
17:48:06 - * fill - Fills the current heightmap with a specified value.
17:48:06 - * newbrushes - Enables experimental brushes which replace the standar
d terrain brushes. WARNING: This is a debug setting and may be removed at any ti
Region# :

You can see the list of commands there, with a brief description of what they do. You can see more detailed help, IE.

Region# :
terrain load-tile help
17:50:26 - == load-tile ==
17:50:26 - Loads a terrain from a section of a larger file.
17:50:26 - = Parameters =
17:50:26 - * filename (String)
17:50:26 -      The file you wish to load from, the file extension determines th
e loader to be used. Supported extensions include:  .r32 (RAW32) .f32 (RAW32) .t
er (Terragen) .raw (LL/SL RAW) .jpg (JPEG) .jpeg (JPEG)
17:50:26 - * file width (Integer)
17:50:26 -      The width of the file in tiles
17:50:26 - * file height (Integer)
17:50:26 -      The height of the file in tiles
17:50:26 - * minimum X tile (Integer)
17:50:26 -      The X region coordinate of the first section on the file
17:50:26 - * minimum Y tile (Integer)
17:50:26 -      The Y region coordinate of the first section on the file
Region# :

You will notice some of the commands have subtly changed since the previous version, load-tile now takes a slightly different input format, measured in tiles rather than pixels. Tiles are assumed to be equal to Constants.RegionSize (256) squared. So, the old format of ‘load-tile file.raw 512 512 1999 1999’ now takes the syntax ‘load-tile file.raw 2 2 1999 1999’.

The help in this new version should be more comprehensive and user-friendly for end users (or I at least hope so), I’m keen to see what users think. Also, if there are any features the previous version had that are not supported now and you were using, please let me know and I will add them to my TODO, but all other things being equal – I’m now going to move on to redesigning the console input for the rest of OpenSim.


Proof of Concept – Advanced Terrain Brushes

In my previous post, I mentioned that I would be working on some new features this weekend, I’ve now finished the first of those – the new terrain brushes. As a proof of concept, I have developed a set of terraforming brushes simulating three different erosion techniques. Read on to learn about the brushes, and how to enable them.

To test these brushes, run the following command on your simulator console – please note that this is permanent until you disable it or restart the simulator.

script terrain newbrushes true

This will swap your default brushes, with the following new and exciting brushes.

  1. Thermal Erosion Brush (Replaces ‘REVERT’ tool) – my favourite. This acts as a sort of a cross between a smooth tool and a flatten tool, it creates very natural looking results if you drag it around a little. The effects of it are sort of similar to what would happen if you blew on a pile of very fine sand from directly above. Spikes and pinnacles get flattened out and their ‘mass’ gets transfered to neighbouring sections, creating a sort of plateau.
  2. Olsen Erosion (Replaces ‘FLATTEN’ tool) – this is a implementation of the oddlabs optimised hybrid erosion routine, described in the paper “Procedural Terrain Generation“. It will flatten flat areas, and sharpen sharp areas – think of it as a light touch you can apply over the top of a terrain to give it more contrast.
  3. Hydraulic Erosion (Replaces ‘SMOOTH’ tool) – this is a fairly powerful brush that needs a little more tweaking. The intended effect of this brush should be like pouring a bottle of water on a sandcastle, in that it will create a river system and drag sediment along with it as it flows.

I’m now going to look at implementing terrain effect filters that apply to an entire sim. Tom Coulthard, author of the GPL’d CAESAR package has been kind enough to give me permission to take a look over his code, and reimplement some of the high-end algorithms inside it for the purpose of developing OpenSim. (Thanks!)