This weekend, I have been experimenting with replacing OpenSimWI with open source social networking software - Elgg. For those who haven’t used or seen Elgg before, it is very similar to things like Facebook - user profiles, groups, etc.

The key with what we are aiming to do however, is eliminate the duplicated data. That is, if you have a group “inworld”, the exact same data should be used on the website. Join a group on the website - it should show up in world. The way we have done this has been to rewrite the Elgg database layer so that it reads and writes from the same databases the OpenSim Grid Servers do.

The result is you can participate in the grid, without needing to be logged in. Grab an RSS feed of your group notices or send someone an offline IM from the OSGrid website.

Custom Profile Pages (Editing)

A Sample Profile

Friends List (Detail)

Group Listings (Popularity Tab)

Group View

When?

There is no deadline for when this will be launched, but we’re hoping to do so within the month.

This is modelled somewhat after the same guide for wordpress. Running an OpenSimulator instance is a challenging prospect for many - there are a number of important criteria you should be looking at before purchasing, but the single most important question is “Will I be managing this myself?”.

“Do it yourself”

DIY Hosting OpenSim while relatively easy by comparison to most hosting software, is still not something that should be done by the technically uninitiated. OpenSim requires a healthy amount of maintainence in the form of updates, backups and patching.

Virtual or Dedicated?

For DIY hosting you have two choices in terms of hosting - Virtual Private Servers (VPS) or Dedicated Servers. Virtual Servers are a percentage of a physical server provided inside of a virtual machine. Virtual servers are often significantly cheaper than a dedicated server, however come at a heavy cost in performance.

Virtual server pricing starts at approximately US$15.00 per month. Dedicated servers will start at approximately US$50.00 per month. Virtual servers are appropriate for low performance private sandboxes, Dedicated servers are a must for public or regular usage.

A final note on dedicated servers - the most inexpensive dedicated server will often outperform the most expensive VPS. If you are on the price border between the two, I recommend switching to the lower performance, but dedicated server - than the higher performance but shared VPS.

Linux or Windows?

Unless you have significant investments in using Linux for your hosting, I recommend using Windows 2003 or 2008, especially if you are not familiar with running hosting environments. The reasons for this are fairly simple - Mono has memory management problems, memory requirements under Mono are often doubled or quadrupled.

Unfortunately Windows server is not always availible - especially at the lower price ranges. Microsoft charges hosting companies a $10/month per cpu fee for Windows Server, so this will always be passed on in the form of higher prices. In the highly competitive VPS industry this price increase makes good Windows VPSs a rare niche.

What processor?

OpenSim will very rarely peg your processor - I would not bother investing too much into the processing capacity of your instance or server. (Whether a VPS or Dedicated machine).

My own experience says that “off the shelf” desktop processors are more than adequate. Here at DeepThink we have standardised on Xeon 3220 based machines (Quad Core, 2.4Ghz) and we find these are more than suitable for our higher-end clients. For an average user, a off-the-shelf Core2Duo is more than sufficient.

How much memory?

This is a much more relevant question for OpenSim. If you are running on Mono, I recommend no less than 1GB of memory per region (512MB if it is mostly empty). If you are running Windows/.NET you can use a rule of thumb at approximately 384 to 512mb per region.

A more precise metric is to total up the following: A base cost of 200mb, total size of all textures in the region + 30% in megabytes (average region is around 50mb), 30mb per 1,000 primitives, 50mb per concurrent user and double the sum if you are running under Mono.

So a region with 5,000 primitives, an average number of textures (50mb) and ten concurrent users you should allocate approximately 900MB of memory for .NET and 1.8GB for Mono. Leave at least 100mb on top of this sum for the operating system itself; if the machine runs out of memory page file access will cripple the performance of your region.

Memory should be as fast as possible - the faster you can get the better.

How much hard disk?

None. OpenSim rarely uses more than a few gigabytes of space unless you are operating a large grid (OSGrid.org is only about 120GB of assets currently). Anything over 10GB is sufficient.

How much bandwidth?

This is a slightly tougher question to answer - it depends a lot on your sim, the complexity and texture detail, the number of visitors. We at DeepThink sponsor the servers running the OSGrid.org Plaza’s, which I believe are the six most visited OpenSim instances running. The Plazas are broken up over two physical machines - each uses about 240GB of bandwidth each month - or approximately 80GB per region per month.

In pratice your region should come in significantly under this - but I recommend making sure you have at least 100GB of traffic per region in the event that you create a popular space. Most hosts provide at least 1TB of transfer on dedicated servers, so this should in most cases be a non-concern.

The other side of bandwidth is connectivity - how fast your server can speak with the outside world. I recommend having at least 200kbit per concurrent user. So for a standard ‘10 concurrent’ situation, you should have at least 2mbit of connectivity.

Backup Space

Make sure to have some kind of external backup system - most hosting providers will sell you SFTP access to a backup server, however make sure that they in turn provide good backup policies on your backups (offsite backup, etc.). OpenSim can be very fickle software, so make sure you have a good backup routine setup.

Latency

If you are a non-american user or cater to a foreign crowd, Latency is a very important issue. Latency is the “lag” between when you do an action and when it occurs on the simulation server - unfortunately latency is often best fixed by changing the geographical location of your servers.

If you cater to an audience in a specific country - I would recommend searching for servers in countries nearby. Often localised hosting is several times more expensive than in the US due to higher prices for local bandwidth, however most of the time there is a cheaper alternative nearby. For example, Japan has very high local server costs - but Korean or Singaporean servers are cheaper and have similar latency characteristics.

Who?

Dedicated Servers

CariNet (San Diego, CA, USA)

CariNet have been a popular choice for people running regions on OSGrid thanks to great pricing and astonishgly quick setup times. Their live support is pretty good and tends to fix most issues within 30 minutes of reporting. Cari have a highly flexible pricing system - so make sure to remember to include additional RAM and the Windows operating system with your purchases.

CariNet are also an official sponsor of OSGrid.org, providing regular free upgrades to the official servers that are hosted there (Currently the two plaza machines and the one welcome machine). They have also provided some special pricing for OpenSim users - see the italics below.

Pricing: Minimum $50.00 per month (special offer at time of writing).

I spoke with CariNet’s sales department, and we have worked out a few “OpenSim Optimized” configurations -

• High Performance - Windows, 4 Core Xeon, 4GB configuration is US$200.00/mo with no setup fee.
  This configuration is ideal for a “SL-replacement” style region host, you could probably get a couple of regions off this hardware, but the exact number will vary as above. I would estimate approximately 2 “Full Regions” could be run on this hardware configuration.
  If you want this server for only $160/month (but with a $120 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn)
• Mid-Range - Windows, Core2Duo, 2GB configuration is US$140/mo with no setup fee.
  Expect to get one heavy region out of this configuration (or quite a few “homestead-esque” regions) - as always, this varies based on consumption.
  As above, if you want this server for only $120/month (but with a $60 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn)
• Low-End - Windows, Celeron 2 Core, 2GB configuration is US$125/mo with no setup fee
  Consider this a homestead replacement, you should be able to get a small number of “homestead-equivilents” running off of this - obviously you dont have primitive limits or things like that, but you will notice degrading performance if you rely on a lot of scripted functionality.
  As above, if you want this server for only $105/month (but with a $60 setup), contact Cari.net sales via their Live Chat with the discount code “OSGRID”. (Speak with Mike or Shawn)

Annual and quarterly discounts are availible for paying more than one month at a time.

Website: http://www.cari.net/

OVH (Paris, France, EU)

OVH are the largest dedicated server host in Europe and provide unbeatable pricing on European servers. English pricing is expensive, however the same servers ordered from their French or German language sites are 10-20% cheaper.

OVH provide large amounts of memory and disk space by default, so very little customisation is required on their default servers. Windows 2003/2008 is an additional EUR 15.00 per month. Their RPS low-end machines may be a suitable mid-way point between a VPS and a full machine, but I haven’t tested one myself.

Pricing: Minimum EUR 49.95 per month. An OpenSim optimized configuration will start at EUR 114.00 per month (fully equipped).

Website: http://www.ovh.co.uk

Virtual Servers

Tektonic (Dallas, TX, USA)

Highly recommended by one of our employees, Tektonic provide good quality Linux VPS solutions - while they only offer Linux based VPS instances, their pricing is affordable and do not appear to oversell their servers in any noticable capacity.

Pricing: Minimum $15.00 per month. A “workshop” quality VPS is US$28.00 per month.

Website: http://www.tektonic.net

Slicehost (St Louis, MO, USA)

Slicehost guaruntee a minimum level of performance on their virtual servers which makes them more expensive than other hosts, however have a solid customer service reputation and a high quality control panel.

Pricing: Minimum $20.00 per month. A “workshop” quality VPS is US$38.00 per month.

Website: http://www.slicehost.com

FsckVPS (Atlanta, LA or Texas)

FsckVPS is often recommend on the OSGrid forums as a potential host - their slices are of a reasonable configuration and have plenty of memory availible. Processing time is more limited and some users have complained about running into processor limits, so their higher end packages are recommended.

Pricing: Minimum $9.95 per month. A “workshop” quality VPS is $19.90 per month, however I recommend the $34.90 plan if you plan on concurrent users.

UPDATE 9 June 2009: These guys dropped the ball badly on an exploit, while it does look like their upstream provider gets the lions share of the blame, they had an unacceptable amount of data loss that could have been avoided by doing some simple backup precautions when an exploit becomes known.

Website: http://www.fsckvps.com

“Someone host it for me”

As an alternative to setting up and managing your own OpenSim instance, you can pay for someone else to manage it for you. Often this is simply bundled with a grid - however a number of companies (including DeepThink) offer managed hosting services for OpenSim.

On average, an OpenSim instance will take around four hours of maintanence each month - at an average industry salary this is around $80.00 per month to the hosting company in engineering costs. You should expect the margin per-server to be about this size.

OpenSim hosting companies will charge based on one of two methods - the first method is Second Life(r) style limits - Primitive, Avatar and Script limitations. The companies that charge this way are generally those providing regions within a grid.

The second method is charging for the underlying service used - Processor time, RAM usage and Bandwidth. The companies offering this tend to be fairly agnostic as to where your regions will connect.

An important distinction between the two methods is that you will often get more ‘bang for buck’ on the underlying capacity. For instance if you need multiple low performance regions - you will come out significantly ahead by purchasing server time rather than regions. Likewise if you need a single high performance region you can tailor your requirements more specifically.

A final note - many simulators are sold as ’supporting 45,000 prims’. This is not reflective of actual usage - the 45,000 number is the largest number the Second Life(R) client will display, however on the backend there is often no limit. That however does not mean the region is capable of supporting 45,000 prims.

We often find that simulator performance degrades rapidly past the 10,000 primitive limit per region and it requires a significant amount of work to get more than 15,000 prims into a region while the region itself is stable, especially when scripts and multiple users are factored into the equasion.

As an addendum to the above - the per region count is not reflective of the per-simulator count. OpenSim can host multiple regions per simulator instance and we have found that the simulator instance itself can host in excess of 100,000 primitives as long as they are distributed between multiple regions.

A note on SLAs and Uptime

OpenSim is still alpha software. If you expect 99%+ uptime, you will also expect to pay for it. Keeping a region running with guarunteed uptime requires active maintainence and attention by an engineer. This means it is impactical to expect 99%+ uptime unless you can afford a technician 24/7.

Our experience with client projects is between 97.6% and 99.2% uptime over the course of a month. (including scheduled and unscheduled maintainence) - this will vary slightly depending on the version of OpenSim used, number of users and other factors.

If someone claims to offer bug-free and stable deployments of OpenSim, they are probably lying or are very naieve. OpenSim will occasionally run into bugs. If you have a specific project in mind that requires a production deployment it is strongly recommended to hire a consultant who is familiar with the OpenSim project (eg DeepThink, IBM, 3Di, Tribal Media, etc.).

List of companies providing OpenSim hosting (note this is incomplete - there are likely to be others)

Customized OpenSim Hosting Providers

The following companies provide customisation services and will tailor your OpenSim install to your specific needs. These companies all provide pricing on a per-server basis rather than per-region.

DeepThink (Managed OpenSim hosting and Customisation services): http://www.deepthink.com.au

ReactionGrid (Managed OpenSim hosting): http://www.reactiongrid.com

3Di (Customisation services, hosting. Tokyo based.): http://www.3di-opensim.com/en/

Not listed here, but likely to offer these services are IBM, Tribal Media and Genkii.

Grid Hosting Providers

These companies provide hosting within the context of a grid. Most of these companies use very similarly specced hardware, however many of them share multiple clients per server - to use Second Life as an example, Linden Lab charges $295 per “island” which is stacked at 4 per server (or $1,180 per server per month).

While I did attempt to compile an exhaustive list of companies here - finding pricing and stacking ratios for many of them proved a difficult and time consuming process. You can find a more comprehensive list of grids (most of which offer region hosting), here:

http://opensimulator.org/wiki/Grid_List

Stability Remarks

As noted all over the OpenSimulator website - OpenSim is alpha quality software. To quote our downloads page

Please note: As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases. Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet. However, constructive feedback is still welcomed.

If you are putting OpenSim into a production environment, make sure to speak with your hosting provider about what you plan to do - many of them may be able to make recommendations or tweaks to better suit your demands. If you have clients involved - it is often better to stick to an older more stable release as all releases are not nessecarily equal (eg 0.5.8 was somewhat stable, whereas 0.6.3 had appearance bugs).

If you are planning on using the ‘bleeding edge’ version of OpenSim in production, expect to get cut, or again quoting the downloads page:

There Be Dragons Beyond This Point

If you are truly feeling dangerous, adventurous, or want to help us test the next version of OpenSim you are welcome to grab the latest unstable code out of our subversion trunk. Any warnings previous expressed about the alpha nature of the code go double or triple if you are running directly off of trunk. Never, ever, ever, never run this in production environments, it is not suitable for that unless you are very familiar with the source code, and can hot fix any piece of it (that probably means you are an OpenSim core member). Feedback and testing on the unstable tree is appreciated, as that helps us make the next release better. If this scares you from using trunk, that was intended.

If it breaks, you get to keep both pieces.

Final Remarks

Running an Opensimulator instance can be a perfect fit for your organisation or person as long as you respect the limits. OpenSim can provide fantastic discounts to other commercial virtual worlds software, however it is worth remembering that it is still new and experimental - often this can be an advantage in customisability and features, but at the same time you need to respect the limitations of the software.

If you are unsure about whether to put OpenSim into production or how to do it in a way that fits what you need to do - like every Open Source piece of software, there are a lot of developers and organisations who can provide consulting services. Check the Core Developers List on the OpenSimulator wiki for a full list.

It’s currently 12:18 AM PST, and we’re sitting at 42 minutes away from shutting down the grid for the big asset conversion. I will be posting regular updates on the OSGrid twitter feed. Today we’ll be doing two important upgrades to OSGrid infrastructure - the first will be moving to new hardware for the asset server, the second will be converting to the new FragstoreFS backend.

The first step will be shutting down the grid so we can export the database onto the new server - based on previous exports, this is estimated to take approximately 2 hours. The next step will be importing the database and adjusting the schema for the conversion - this involves changing the indexes to add a numeric incremental index which allows us to resume conversion from specified points. The import will take around one to two hours, and the index conversion will take a similar period of time.

The next step will be firing up the fragstore converter - this is a specialised piece of software we wrote for this, which will reformat the data into the new CAS-aware schema, and move the BLOB records into the filesystem. Conversion speed varies greatly based on the size of the individual assets being processed, but we’re hoping this will take between 9 and 15 hours to complete - we preconverted a large portion of the database already; but the exact speedup we will get from the preconversion is unknown.

Total estimated downtime is 21 hours - but this will hopefully be the last time we need to shut down the grid for such an extended period of time, as future asset moves will be able to be done transparently to grid users (Murphy willing.).

The #osgrid-dev admins have spent this morning doing a test on the new asset server. Thankfully appears to have survived our stress test nicely - we’re going to proceed as planned with the full conversion tommorow.

Update: OSGrid users - If you are reading this due to the twitter/osgrid notice, or the OSGrid news notice - the short of it is, we’ve converting the asset server. It’s going to take 24 hours, and we’re going to need to pull the grid down to do it. Downtime will begin approximately at 1AM Wednesday morning. It will take up to 24 hours to process the conversion - I’ll be posting information here on this blog as we proceed with updates.

For those just joining us on the OSGrid FragStore saga, read parts #1, and part #2 here.

Day 3: Conversion of the 1.5 million test assets has completed - and now we’ve got only the metadata in the table, I’m going to take some attempts at running queries. CAS storage eliminated slightly higher than my predicted 17% - coming in at around disk 23.49% savings on duplicated assets. Unfortunately the first bug has become apparent - creation date wasn’t preserved. I have patched the converter, so this will be filled when we do the final live conversion.

The following is the outputs of some queries I have run on this table, since it doesnt look like these take too long, we should be able to run these off the production server and update them in future. First, there are 15,957 groups of items with more than 5 objects using the same name in the system, of these, the top asset names are -

Returning to a query I was running yesterday on the CAS%s, the following is the updated chart with 1.5 million test assets loaded.

Fig 1. OSGrid CAS Duplicates (Day 3)

And if you have ever been curious about the distribution of assets in terms of asset type - here is a little chart showing the breakdown.

Fig 2. OSGrid Asset Quantities by Type

Full Conversion Date Set

We’ve decided to go ahead with the switchover this coming Wednesday, at 1AM PST. To go ahead with this, we are going to be bringing the grid offline for up to 24 hours. This hopefully will be the last time we need to go offline for more than 15 minutes - and also represents a move from our old asset hardware “Chenobyl” to our new server “Hindenburg” (which has a much larger hard disk capacity).

The following is my log of the OSGrid asset conversion saga.

Day 1: Today we’re taking a third attempt at doing the big fragstore conversion for OSGrid, for those not following the Saga of the Asset Server - about two months ago we started noticing major scalibility issues surrounding assets. Right now they are thrown into MySQL as a blob table, resulting in large amounts of waste both in duplicate content and in the fact we’re storing a filesystem inside of a relational database - you can read up on the earlier design decisions leading to FragStore here.

The previous two conversion attempts have suffered “mysterious MySQL glitches” which we assume may be related to various bugs with long running commands. Apparently the proper course of action when running a query that takes more than 60 seconds to process the command, is to freeze up entirely and stop processing requests - for now and evermore.

In an attempt to make this run a bit smoother - we’ve broken up the process into 2,000 batches of 1,000 assets each - previously our batch mechanism was using MySQL LIMIT X, Y which has the side effect of getting slower and slower as you progress down the table (thus causing the above); so we’ve shifted to using a numeric ID on the assets table. Putting the numeric ID on there allows us to at least index sequential accesses - LIMIT unfortunately will not use any form of index hinting.

mysql> ALTER TABLE `assets`
    -> ADD COLUMN `numericID`  int(11) UNSIGNED NOT NULL AUTO_INCREMENT AFTER `access_time`,
    -> DROP PRIMARY KEY,
    -> ADD PRIMARY KEY (`numericID`),
    -> ADD UNIQUE INDEX `assetID` (`id`);

Query OK, 1623826 rows affected (1 hour 11 min 2.54 sec)
Records: 1623826  Duplicates: 0  Warnings: 0

An hour and a bit later, the difference between the speed of processing before and after is pretty astounding

mysql> select id from assets limit 540000,10;
10 rows in set (11.53 sec)

mysql> select id from assets where numericID between 540000 AND 540009;
10 rows in set (0.42 sec)

It doesnt need a whole bunch of explanation to figure the above may help with our situation. Running the revised and simplified “AssetConverterMarkII” appears to go without a hitch - data is stored into the database, the metadata table is being filled correctly - all in all it appears to be functional. With one minor teeny little problem.

Only the first 4096 bytes of data are being written to the backend store. The remaining sectors of data are written - but consist entirely of zeros. Retrieving the data results in a buffer of the same length as the original stored asset - but often half the data is completely missing. An hour later, it looks like the data is being sent to the backend voldestore correctly, but either on the way there or on the way back, it loses something. Unfortunately it looks like the problem is outside the purview of the client adapter and is somewhere in the deep murk of the backend storage server.

Day 2: Rethinking time - after spending quite some time hunting for some alternatives, the simplest solution looks to be the best.

While I am keen to use Project Voldemort in the long term - in the short term debugging our implementation details are just not on my agenda. We use a IKVM cross-compiled connector library from Java, and the problem looks like it is sitting in there somewhere. Unfortunately debugging Java IKVM libraries from within .NET is painful at best, and not something easily fitting into our timescale.

The simplest solution is to throw the asset blobs onto the filesystem - filesystems are after all developed to handle tiny little files. Directories will slow down when there is more than about 3,000 entries within them, so we’re breaking storage up into “/b1/b2/hash.blob” - this means assuming an even distribution, approximately 30 files per directory at current size, scaling us up to a capacity of 100 million assets before we need to rethink the situation.

Distribution and redundancy are both things I am still keen to employ - putting us on the filesystem does allow us to look at things such as KosmosFS which provide transparent distributed filesystems on Linux, and also gives us the opportunity to look at commercial filestores down the road if we ever win the lottery.

Rewriting fragstore to use filesystem components where voldemort was employed took all of an hour and the asset converter was up and running - a lot faster too. Our conversion transfer rate on Voldemort was 66 assets per second. FragstoreFS?

10,000 Assets Processed (102.04 asset(s)/sec): 0 error(s) so far.

The second thing I wanted to test was just how big a savings we were getting from using Content Addressable Storage - with 10,000 processed, we ended up with 613 duplicates eliminated (6.1%). With 20,000 - 1390 (6.9%), with 90,000 - 8962 (9.95%). We’re hoping as the full dataset is processed - the % of duplicates eliminated continues to increase.

Fig 1. CAS Duplicate Savings

The next issue to present itself was a slowdown as the conversion occured - the number above (102.4) held firm for the first 10% of the conversion, then conversion speed began to massively taper off, first down to 71.39/sec, then down to 50.22/sec by 150,000 converted. My fears were a reprise of the situation we thought fixed on day 1 - slowdowns on accessing as we move further down the table.

Nebadon suggested that this infact might be actually because as OSGrid has become more popular the average size of an asset has increased over time - so we skipped a million rows down the table and started converting some of the later rows. Conversion speed? 68.31/sec. This indicates that yes, later assets are more expensive to process - but the conversion speed should still average the 60 or so per second we need to be able to convert the entire database in under 24 hours.

Appearing somewhat happy with the results, conversion on the complete database has started, but we wont know how well it has worked until tommorow.

Day 3: Stay tuned!

I thought it would be interesting to make some pretty charts representing the data behind OSGrid.org’s operations. The following is accurate as of today, but probably wont be tommorow. Some of the data is missing or has gaps in it - this is because during those periods I was not able to get accurate data and decided not to display it at all.

Servers

There are a total of 395 unique IP addresses connected to OSGrid, each roughly corresponds to a unique physical server hosting regions. Of these, 130 were compiled from SVN and give version information. (265 not reporting version).

The most popular version is r9332 with 35 unique servers running this revision. Next is a tie between the official 0.6.4 release and r9313 with 20 unique servers each. The remainder is distributed fairly evenly between r9307 and r9336. It is worth noting that version information was introduced in r9307 - so we cant quite yet see into the 60% that are running behind that version. What is interesting to note is however than 30% of the regions on OSGrid were updated with this revision already and indicates active upgrades and maintainence.

Fig 1. OpenSimulator Versions on OSGrid.org

Regions

At time of writing, there are 2,083 regions connected to OSGrid, owned by 386 unique avatars. (Averaging 5.3 regions per avatar) on 395 unique servers. Each server hosts on average 5.2 regions, the mode is 1, with 35% of servers hosting only a single region. The following chart displays the average number of regions per server over a range of values. Interestingly, this means that 1 in 7.5 users own their own region on OSGrid (compared to 1 in 600 in Second Life®)

Fig 2. Regions per Server on OSGrid

Users

The most interesting statistics are to do with users - currently there are 15,669 users registered on OSGrid.org. 20% of these users have logged in in the last week, 40% in the last month (75% in the last quarter). You can see the proportion of users who have logged in since a certain date on the following chart.

Fig 3. User logins since specified date

User Registrations are also fairly interesting to look at - OSGrid benefited enormously by Linden Lab’s Open Space pricing change announcement back in last November. Since the announcement, registrations on osgrid per day has doubled.

Fig 4. User Registrations per Day

Fig 5. Total User Registrations

It will be interesting to see if history repeats itself again when the next set of price increases occur in June.

Assets

A final note - I cannot make any charts on the asset table because, despite the presence of a creation date - running the query on our 2 million assets results in database meltdown. I can however give some quick figures on the asset table, there are 2,164,534 assets on OSGrid at present occupying a mere 65.4 GB (well less than a percentage of the Linden Lab asset cluster). Part of this is because unless an asset is in inventory, the central asset servers do not care to know about it.

So, I’m sitting here banging my head this morning over two issues. One, why the heck is terrain never deviating from zero height, and secondly why things werent looking quite right - as you could see in the previous posts it was clearly rendering prims but things were ‘missing’ or not quite right. Turns out the answer was both.

First, Terrain.

Yesterday I got the heightfield behaving properly, but couldnt understand why it was never being set when placed onto the live feed coming from the network stack. Answer turned out I was doing something stupid and had typo’d on a variable name for my indexer. Once that was fixed, we were rendering scenes like the one below.

It’s beggining to look a lot prettier, but as you may have noticed, the prims dont appear to line up in any recognisable pattern. While there is definetely a pattern there - something is very off.

Second, Objects - Part A.

Showing this one to Easy [Babcock] in the office, we quickly worked out that infact objects were never being rotated - every object had exactly the same identical zero rotation. After a few minutes debugging, this turns out to be related to the conversion from a Quaternion to a Euler rotation for WPF. Switching from Vector3 to Media.Quaternion internally solved the problem nicely.

Here’s a view of Abbotts aerodrome with the fix inplace.

Much better, although there’s still some clumps missing.

Second, Objects - Part B.

So, it’s looking like we’ve almost got this rendering correctly. At least object shape and rotation is being displayed correctly, although there’s still something lacking. It turns out that most of the bits missing corresponded nicely with camera view - so I’ve fixed this by telling libsl to ‘rove’ the camera position around the sim to download the entire thing. The above screenshot had this fix inplace.

This solved at least terrain loading completely and most objects.

Loading it up on OSGrid in Wright Plaza - everything seems to actually render properly now, at least so far as primitives go - we’re missing sculpties right now which form a large component of Wright Plaza’s design.

Second, Objects - Part C!? Huh?

Panning our Camera around a little, we notice something a little bit … odd. Namely that around 0,0,0 there’s a large congregation of primitives. I’ve been noticing this already and had discarded it as possibly being neighbouring sims in which case, I’ll just knock them out later.

But it turns out, there’s valuable prims being thrown there - it looks to me like maybe the child primitives in link sets having their “Position” being relative to the parent primitive rather than the sim (in OpenSim we have both .Position and .AbsolutePosition to seperate these).

So, I’m going to be working on that for the rest of this afternoon - after which I’m going to play with either texture rendering, or getting Meshmeriser to work so we can discard the dependency on the black-box GPL’d rendering library.

It’s a simple enough question - often when I see a company or group get involved in OpenSim, the first thing that springs to their mind is “Well, we must launch our own grid!”, with each grid having it’s own isolated set of users, inventory, assets and regions the question must be asked: “Why?”.

But in most cases, this often isn’t the best of ideas, and short of internal uses it’s often counterproductive duplicating effort others have undertaken already. Running a grid properly takes a lot of work - especially if you are doing frequent updates, if your intent is on making it a popular destination for random visitors, then you have extra work publicizing and convincing people to create an account and login.

All in all, it’s a lot of work for relatively little benefit.

Alternatives to starting your own grid

Attach your region[s] to an existing grid - I personally like recommending OSGrid.org - one of the downsides to this approach is that you are relying on the grid provider for your infrastructure - if they either neglect to update frequently you may run into problems, likewise if they have downtime or stability problems, you are tethered to them good and bad.

So, why do it then?

The short answer is to do it for your users, if you require users to register an account on your grid to come view your trinket, you have effectively annihilated any chance of instant gratification so to speak. The difference between opening a map on a popular grid, and logging out then relogging onto your grid is huge. It requires a good deal of effort to to so.

The longer answer lies in pooling resources - in this case users, users may log in to view your trinket, but after they are done with it, go visit someone elses trinket nearby, the key here is that people who come for other peoples shinies may end up visiting yours too - there’s no zero-sum game here, and offering a multitude of attractions is more powerful a drawcard than yours alone.

When you should make your own grid?

There’s plenty of reasons to run your own grid however - the biggest one is privacy and wanting to run something entirely behind a single corporate firewall. Protecting intellectual property and trade secrets requires making reasonable protections when possible, and public grids are not well suited for this.

Another reason is when you want to run something solely independently - such as say a specific concert or event, where you know that your demands require customisations on the grid software itself. In these cases unless you are able to make an arrangement with the grid operator you may run into problems and hosting oneself is a good idea.

So which grids allow outside regions to connect?

OSGrid.org is the best for this since the entire grid is hosted externally - making sure this works smoothly is a goal of the osgrid admins. Connecting a region is free and there are no real terms of service at the moment to speak of, other than “don’t break the law.”

DeepGrid has allowed regions to connect since the beggining - although the grid server software is updated less frequently than the OSGrid ones. A common terms of service do apply for this and region spaces need to be reserved via the website first before connecting (rather than first-come-first-served, price is still free).

CentralGrid offer region connections too however connecting a region invokes a large fee that isnt charged anywhere else, for as far as I can see no advantage. I’m not impressed, but you may be.