Which brings me to the following pretty screenshot:

This is a fresh install of Gridmix – one of the main aims of the package has been to make it so it requires very minimal configuration to look good, and do what you want. It’s pretty easily adapted for either a private or a public grid with a host of settings suitable for each.

For example – Signup & Registration, for private grids you might not care about verifying email address. In which case, you signup form is configured like so:

But if you are running a public grid – and you want to ensure signups are legitimate, you will want to verify email addresses, enable a captcha — and assuming you are in beta, you might want to say enforce a ’signup code’ to limit who can create accounts. Your signup form might look like this instead:

The entire skin is very customisable – not only can we easily substitute alternate themes in, but the entire default skin has been setup so that all the images and CSS can be HSL shifted at any time (allowing you to easily recolour your grid with minimal effort)

In addition, we’ve implemented a Mediawiki-Syntax parser into the content management system – allowing you to edit each page on the site using wiki-syntax. This allows you to ensure a consistent appearance across all pages – and keep that in the event that you choose to change the theme.

Finally – there’s a bunch of features in there which I know many people will find a big improvement over what Wi supports; such as Google Maps based world maps (which are generated in realtime – and include live positioning of all online agents on the grid – see the green dot.)

Cost, Availibility, etc.

We’re providing GridMix as an alternative to Wi for all current (and new) SimHost customers who have private grids. This will be a private beta for a period of around three months while we work in any specific feature requests and bugfixes that our customers bring to us – if you are a current customer, just contact support and we can get you setup with GridMix fairly quickly.

We’ll be releasing a limited “core” version as open source software sometime in the future (once we’re out of beta) – we’ve built this all using a MVC framework and have spent some time ensuring that it is both secure, functional and a lot more useful than Wi was. One of the big improvements has been the implementation of an ACL system based on the godLevel – you can now delegate users with a range of roles which grants them certain powers to ban or edit users or change grid settings.

It represents a complete ground-up rewrite, no-code has been copied from the original Wi (or anywhere else), the only foreign code is the base MVC framework. We’ll be adding new features fairly regularly as time goes on – some of the features we plan to implement include some compatibility with the search system, events calendar support & some analytics.

The full version will be available for a fee to non-customers, and a hosted version will be free to all current and future SimHost customers, who have one of our hosted grid packages (or a dedicated server). If you are a current (or potential) SimHost customer and wish to participate in the beta – as I said above, please contact us via support for more information.

#1 – Consolidation continues throughout the first half of 2010.

Platforms with relatively simple feature sets will continue to face increased competition from free products and their more technologically complex brethren. Many will survive on one or two large clients – but as a whole they will languish with a dearth of new clients.

#2 – Most tele-work virtual world initiatives fall flat on their face.

Customers of tele-work virtual worlds will find after protracted usage that Virtual World clients are no match for something like WebEx. While many instances will be sold – only those with a genuine requirement for a 3D environment (such as safety training) will actually succeed. The consequential failure of these business users will lead to yet-another-media “Are virtual worlds over-hyped?” rush.

#3 – Average World Concurrency Improves.

The shift towards doing less on the server will continue, but the servers & software will continue to get better and more scalable. OpenSim will be handling a minimum of 200+ concurrent users per region by the end of 2010 – likely a lot more. Dynamic load balancing becomes a hot feature in new virtual worlds. (Side prediction: with better protocols OpenSim could be looking at 2500+ users per server)

#4 – Entertainment Worlds continue to quietly succeed year-after-year.

I’m not talking about MMORPG games here either. The consumer entertainment virtual worlds will continue to grow, or at least will not stagnate as fast as business worlds. There.com, IMVU, Second Life will all continue to see growth — although at a smaller percentage than they have previously (5-15%).

Blue Mars will languish for the first half of 2010, but may gain serious pace in late 2010 as usability problems are fixed & average user hardware specifications continue to improve.

#5 – Greater Cooperation between Open Source Virtual World Frameworks

OpenSim, Sirikata, Wonderland and realXtend begin talking to each other. Initially this will likely be support for the various clients across platforms, but eventually this could lead to common adoption of a standard protocol. Commercial incentives for a common VW standard however will continue to languish due to complex conflicts of interest between member parties.

#6 – realXtend Naali becomes functional & useful.

Building a new viewer from scratch is a complicated process, but Naali will become modestly functional towards the middle of 2010 and competitive by the end. OpenSim developers will likely begin to standardise around it (rather than Idealist et al.) as a way of making “viewer-required” changes and improvements.

#7 – OpenSim begins a formal release process.

Sometime in Q1/Q2 2010, OpenSim begins seeing a formal release process where major improvements & features occur on one branch, while a fixed programming target occurs on a stable branch; API changes will only occur on the development branch. OpenSim also begins finalising some of the internal interfaces on the path to a 1.0 release. It is likely that a version “1.0″ will not be released in 2010, but a release candidate (or “0.9″) will appear in Q4.

#8 – Content Repositories such as Turbosquid sign licensing arrangements with VW operators.

Hot off the heels of the Turbosquid’s arrangement with Autodesk – world developers integrate content stores linked to royalty-free services such as Turbosquid to provide their worlds with content. Leads to benefits for both world operators and users alike as the general visual quality of new worlds improve. Content-related middleware providers such as Xfrog & SpeedTree see their technologies integrated into more and more worlds (Evolver.com might succeed here too).

#9 – Virtual World Content Producers slowly begin a shift to a Royalty Free Licensing as an option alongside the traditional “Item” approach.

Top end content designers realise that business users are willing to pay extra for royalty free licensed content – and are willing to pay a lot more for it. As Meshes are added to Second Life® – producers begin making and releasing content not just simultaneously in multiple virtual worlds, but to places such as Turbosquid under royalty free licenses. Visual quality in Second Life® improves dramatically – but still falls short of a new release video game title (Shaders would fix this.)

#10 – Cost of world platforms decrease as competition sets in.

The average price of a virtual environment begins to decrease – commercial standalone deployments fall dramatically from the current $50,000+ fees down to rates under $5,000.  Consumer worlds will likely remain priced fairly high, but will begin a slow inevitable drift towards a functional environment at a fairly inexpensive $14.95/mo price point. (But don’t expect it to hit that until 2012 at the very soonest.)

There we go – I think some are more probable than others, but it’ll be interesting to check back next year and see how I did.

I hope everyone has a Merry Christmas & happy new year!

This tool is a from start-to-finish utility for launching regions, it will automatically negotiate with your router to forward ports as required; and it will handle automatic updates of new versions using the official OSgrid.org Binary Releases. The basic release contains all the features of the default OSgrid binary release (including preconfigured Groups, Physics, Scripts, etc.). Shameless Plug: Obviously this has all the limitations of regions hosted from home – namely bandwidth & network considerations – if you want to host something permanently and reliably with support, come take a look at SimHost.

This new version of the launcher includes the following new features

• Confirmed & Tested Linux Support (and presumably OSX with Mono)
• New Zip Library (uses Ionic.Zip now) – works better on Linux.
• Completely rewritten UI – Now provides a great deal more feedback on what the tool is doing at any specific point in time.
• Ability to manually position a region optionally.
• Basic Input Validation (Bug: Glitchy on Linux – if you cant close the tool, input a few characters into the current field)
• ILMerge’d Release – now just one self-contained .exe

To use the tool, follow the following steps:

1. Drop the .exe in it’s own folder somewhere. Run it.
2. Enter a region name – must be between 1 and 64 alphanumeric characters. Some symbols & UTF8 characters are fine too. Known invalid symbols include: [ ] \r \n.
3. Select either automatic positioning (default), or enter a pair of free coordinate values. X first, followed by Y. Coordinates must be between 0 and 65,535.
4. Enter your Avatar Name on OSgrid.org – Firstname followed by Lastname.
5. Click Launch
6. At this point, the tool will download, unpack and install your region – you may be prompted to perform certain tasks manually (such as if Automatic Port Forwarding fails you may be asked to port forward manually.)
7. Once the OpenSim console appears – you should be good to go.

How to get this tool:

This is an Open Source utility released under a liberal BSD license. The latest source may be obtained via github

Source Code: http://github.com/AdamFrisby/OSGridLauncher

Release Download: http://www.adamfrisby.com/OSGL-r0.22.exe

Enjoy.

I see on a fairly regularly basis reports that OpenSim supports 45,000 prims versus Second Life®’s 15,000. It’s rubbish; but it comes from a somewhat logical source. The viewer itself will not display more than 45,000 objects in the ‘prims parcel supports’ field. There’s no technical reason for it – it just clamps the value (and I’m not entirely sure why). If OpenSim is set to unlimited prims (or 99,999,999), the viewer will show it as ‘Supports 45,000 Prims’ and not what it really is (’Supports “99,999,999″ prims’).

But, you can go well above that boundary. Some of Shenlei’s Leviathan builds are now breaking the 160,000 primitive count mark (and I have no doubt she intends to push it further!), but those builds are incredibly intensive on other aspects of the system, particularly memory usage. Primitive counts as a resource delimiter have never been accurate as far as underlying consumption goes; how they evolved goes straight back to when SL was still a MMORPG with nifty building tools (circa 2002-2004).

This is evident in SL – certain scripts cause “lag”, popular clubs can block other users from accessing the region (by eating up the whole max avatar count) – neither of these is factored into the current resource limits. This is applicable in OpenSim too – an unscripted region will behave better than a scripted one, an empty region will have uptimes measured in months, a popular one in days (or hours).

So, with this entry I aim to do two things – first dispell the myth that OpenSim supports 45K primitives. That is incorrect – OpenSim supports whatever you tell it to handle, whether it behaves is up to the underlying consumption required for your build, and what you are hosting it on. And second – clarify where the limits really are, and how you can optimise them.

With SimHost, we needed to give a number to our potential customers that is indicative of their usage, in a manner that can be understood like prim counts, but reflects the actual capacity used. We decided to go with RAM usage – this is because memory is the primary requirement of the OpenSim software. The amount of memory a region needs is pretty much directly proportional to all the other requirements (scripts need a roughly equal amount of memory as CPU, so do avatars, prims, etc.). There are other limits too – network bandwidth, processor usage, etc. All of these can become a bottleneck depending on the design of a region.

To give you a rough estimate of capacity-by-memory, one of our heavier customers has a 10,000 prim sim which hosts weekly meetings; it’s somewhat scripted – memory use for this region is between 405MB (Resident) and 1070MB (Total). Each avatar to the region adds between 20 and 50mb to the “resident” figure (and when occupied, some of the paged memory moves into the resident as it is accessed). If you use this as an example – 1024MB of resident memory should get you a “standard region equivilent”; if you want to start pushing on it further, then you might want to allocate 2GB dedicated to the region.

Network bandwidth is directly tied to # of avatars plus, # of primitives plus, # and size of textures. You can drop your bandwidth requirements fairly dramatically simply by building more efficiently, encouraging texture re-use, optimising your textures, etc. Sculpties actually work to your benefit here – since they can replace many prims with just one; and that one is ‘instanced’ – so that every copy you use, is only downloaded once by the viewer.

Processor usage is generally not a problem; to avoid any issues – giving a region a dedicated core will let it do it’s own thing. Scripts are about the only thing that can really push this figure (and physics to a much lesser degree). With recent updates to OpenSim enabling much larger concurrencies – processor usage is beggining to appear; but an average user will often struggle to push an average CPU core usage of more than 10%.

So, next time you see the claim that ‘OpenSim supports 45,000 prims’ (as I often do) – think of it not as a hard limit, or even a ballpark figure that is remotely accurate. OpenSim will try serve whatever you tell it to — but whether it does so successfully is more likely to be up to other factors relating to the underlying hardware; than the software itself.

What is being described below is dealing in real currency – you owe it to yourself if you plan to use this, to understand how it works, and perform your own risk assessment. The module is completely unsupported and unwarrantied. Use it at your own risk.

Suppose you are a user of one of the Open Grids or Hypergrid system – and you want to purchase an item, pay into an object, or otherwise transact business where a real currency transfer occurs somewhere down the line. Up until now, in all environments you are reliant on trusting a third party to act as a middleman, providing some currency-equivilent (such as say V$, L$ or whatever.).

The problems with this scenario is that that currency is at best backed by a single corporate entity (and even then they may not choose to ‘back’ it at all) – leaving you exposed in the event something goes wrong. This is compounded by the general trading size of these operators – tending to be sole-traders or small-business; the best scenario is one where neither the user nor the merchant needs to rely on a third party beyond the credit card processor.

Which is where DTL-PayPal comes in, this is a free (3-Clause BSD), open source module we’ve developed to solve this explicit problem. It uses PayPal as the backend for the transaction, and prices inworld goods in US cents. You pay me, OS$100 – and you get a bill for US$1.00 from PayPal. Every transaction needs to be confirmed by you with PayPal thus adding security into the system; in addition you don’t need to carry existing balances of ‘currency’ in order to buy items – each item can be bought individually with a seperate transaction on your Credit Card for each purchase.

The transaction is a 2 step process for the user – which is illustrated in the diagram below. Step one, you ‘negotiate’ the payment size — this is basically filling out the payment or ‘buy’ dialog that the vendor or merchant has setup already. Step two is you will be asked to visit a special webpage (which links to one at PayPal) which sets up and pays the transaction. From a users perspective you need to do nothing more.

Steps 3 and 4 occur when PayPal has confirmed the transaction for you – once the payment is confirmed (usually within 10 seconds), PayPal notifies the module, which in turn completes the transaction, finally PayPal deposits the balance in the vendors account for immediate use.

Obviously the problems with inventory server issues, vendor malfunctions, etc still exist – but to a customer PayPal does allow you to dispute charges on non-delivery grounds (however beware doing this to scam the system – the merchant gets a chance at rebuttal and it can be a complicated process)

From a vendor perspective – the main drawback to this solution is cost, PayPal will charge you roughly $0.28 plus 2.2% for a standard account in order to process the transaction. On tiny transactions (such as one for $0.50, fee would be $0.31) this can add up to a significant portion of the transaction. For users using this exclusively, I highly recommend using a PayPal MicroTransactions account which has much lower fees (but certain additional terms & conditions).

So, where can I get the code for this? It’s on my personal GitHub account (along with a few of my other goodies) – http://github.com/AdamFrisby/DTL-PayPal – I will add some further notes, first this module is currently somewhat hard coded to present a warning to the user about it’s experimental nature, remove this at your own risk. Second – OpenSim is still alpha software, you may run into other issues, so be prepared to handle them if you want to accept payments from users in it. This software has only been tested on the PayPal sandbox so far (and I recommend you do the same), however should work with the live version fine.

Enjoy.

It’s important to note here – these were real clients, using SL-derived viewers. By comparison libsl is a lot friendlier on the packet engine than the full viewer, so bots tend to be a less effective test. (Plus users introduce randomness that bots cant quite emulate). Wright Plaza with 85 avatars and their attachments weighs in at a healthy 15,400 prims – so there was no shortage of texture of prim data to be sent to each client – it’s actually probably one of the nastiest sims to do load tests in – which makes it great for this. Furthermore the hardware it is located on isn’t exactly top of the line, or even middle-of-the-line.

The short news is – we’ve made some really impressive progress in the the last week. Earlier we got up to 50 – which was tweaked, tailored and adjusted to get us to where 100 or even 150 isn’t really that out of the question anymore. There’s three big causes for this – first, abandoning OpenJpeg for decoding J2K textures made some very noticable improvements to stability (it’s in progress to abandon it for Encoding too); this means we’re not crashing on the way up – which means we can hit higher concurrencies more reliably. Second – John Hurliman from Intel rewrote our throttle routines and some low-level packeting code, which delivered a big boost to packet performance. Third – multiple efforts to reduce memory use in key places, has at least halved operating memory requirements – at 85 concurrent, memory was peaking at a mere 1.7gb (~20mb/user).

A result of these improvements has been memory IO is no longer such a major bottleneck – we’re actually beggining to hit the point where CPU usage is nearly becoming a more important bottleneck (we were hitting 90% CPU at peak — although the physics interpenetration mentioned above might be distorting this, since it could lead to run-away CPU use) – which is a refreshing change, since it is a lot easier to optimise around, and the tools for CPU use profiling are a lot better than those for memory IO profiling – and produce a lot more meaningful information.

We’d like to continue these load tests – the information the devs have gotten in the last week has been absolutely invaluable. Having a big pool of testers able to jump in on a moments notice has resulted in getting performance fixes tested and integrated a lot faster than usual – it’s also helped stability, each crash has been diagnosed and debugged in series as it is encountered. It’d be very easy to say that performance & stability wise, more has happened in the last week than the last 6 months – and we still need your help to keep going. We’re going to be continuing these load tests next week – there will probably be another major effort at getting 100+ avatars in a sim next Friday (same time, 1PM PST). If you want to know when the next test is planned, and help out – either hang around in #opensim on Freenode, or follow @osgrid or @adamfrisby where I’ll announce them they come.

Next stop, 150.

3Di – the Japanese OpenSim development company just opened the code up for their brand new in-a-browser viewer for OpenSim. It’s written in C#, has plugins for IE and Firefox; and is loosely based on the OpenSim-core team’s “Idealist Viewer”, which uses the Irrlicht 3D engine.

3Di’s innovations have been adding proper avatar support (albeit not the SL ones), improving the framerate fairly dramatically; and of course embedding it into a browser. It’s named “Rei” after the Japanese number for ‘Zero’ – and code is availible under a standard 3-Clause BSD license.

There’s already been a lot of news out there for the announcement of OpenViewer itself – so I probably wont go into too much detail; other than it lets you embed a 3D OpenSim space onto an arbitrary website – something which combined with say OpenID or anonymous login, could do wonders for increasing userbase concurrencies on OpenSim deployments.

OpenViewer has a couple of nifty extensions to the protocol like Mesh support – which uses the Irrlicht Model Format (realXtend uses the OGRE Model & Material Format, SL is planning to use the OBJ format – but dont expect anything for another year or two.); I’m not entirely sure how that plays into the building editor – specifically how you upload & use them, but I’m sure that will be clarified in forthcoming documentation. It will be interesting to see how well it performs on some big complicated sims (like say one of Shenlei’s behemoths), in theory it might behave a little bit better on the server, since libsl handles packeting a lot more sanely (and in lower volume) than the official viewer does.

There’s been some discussion in addition on the opensim-dev mailing list about getting realXtend & Rei both standardising on a common mesh format; COLLADA has been suggested – but the level of filesize bloat raises concerns for realtime streaming downloads of complicated regions.

Site: http://www.3di-rei.org (code & instructions)

Press Release (English): http://www.3di.jp/en/news/2009093001.html

Hopefully in the coming weeks, we can look at ways of embedding this into the OpenSim & OSgrid websites as a quick way to ‘try out’ the sims.

One racetrack, a little over 4 square kilometers of space (or 4,194,304sqm). This is my first attempt to build something with a bit of scale to it, now that we’ve got mega-regions working in OpenSim. (and vehicles.)

To start with, I need a terrain large enough to encompass the entire area (there’s no way in hell I’m manually terraforming this one) – courtesy of DeepThink, I have a license to World Machine Professional, a commercial terrain editing package that absolutely kicks ass. World Machine builds terrains in a semi-layered manner, then allows you to combine those through a railroad-style filter scheme.

Grabbing one of the World Machine samples as a base (since it had road layers already setup), I modified them and redrew the paths to build a 16×4 sim (4096×1024) terrain and rendered it. You can see the output in World Machine below, of course from this scale it doesn’t really do it justice.

Travelling at 55.5m/sec (200kph, 124mph) – you will cross into another region-sized space every 5 seconds; but the total racetrack length means that even at this speed it will take over a minute to complete, encompassing a minimum of 16 region-sized areas, which in turn is only a small subset of the entire space availible. Taking a picture of the terrain loaded into the mega region, you can see just how insignificant an avatar is at this scale.

This is compounded by the fact that the viewer refuses to put it’s “farclip” beyond about 4 sims distance, so at best you can see 1/4 of the track at once. The ringworld walls are each about 150m tall at this scale; and geographical features are quite recognisable as geographical features.

Of course, we can’t just leave it at that – to quote Mythbusters, “if it is worth doing, it is worth overdoing”, so I pulled up the terrain in world machine again, and decided to go a little bigger. I originally made it at 48×4 sims, however had to crop back to 32×4 due to my machine needing more memory to do the resulting 12,288 x 1024 terrain without swapping on disk constantly (resulting in a multi-hour render). For scale reference, the smaller of the two circles is about the dimensions of a single normal region.

Part 2 will cover texturing and detailing this race track, followed by some first impressions of how it behaves with Kitto’s new vehicle patches. Once I’m done with it, it will go up live on the Hypergrid (and probably OSgrid) for public perusal.

Kitto Flora deserves some major kudos for recent developments with OpenSim vehicles. Not only do they work, but the revised car script I toyed with earlier today – was actually quite usable; and dare I say it? good. All of this is thanks to Kitto’s work refining and improving the vehicle functions and how they interrelate with the internal ODE physics engine.

I could speculate here, and say if you were a decent vehicle coder – you could probably do some amazing things with OpenSim these days. So what happens if you combine these new vehicles, with Teravus’s recent mega regions code, and my sculpty terrain code (with mods from nebadon)? This. (Recommend jumping to about 4:40)

(Edit: Added a new link to the video – 22/09/09)

I probably do not need to go into too much detail here – the above is a 3_x3 megaregion, using 576 physical sculpts, Kitto’s latest ODE mods & vehicle script – running on a home users cable connection; with several people driving around at once. Not only does it work – it suprisingly works well. I expect a more skilled texture artist could pull some amazing things off with the sculpty terrain code – the terrain is just a quick output from L3DT done by Nebadon.

The vehicle code isnt in trunk quite yet – but if you ask around in #osgrid, I’m sure someone can point you to the github account where you can get the ODE patches. I’m sure much like mega-regions, it will be in trunk soon enough.

Credits: Kitto Flora (vehicles), Teravus (megaregions), Nebadon (video, hosting, testing, sculpty terrain), Bri Hasp & Hiro Protagonist (hosting & testing), Myself (sculpty terrain generator).