Let’s run through the quick checklist for the recently semi-announced “LivePlace“, who claims to do some pretty nifty things with distributed server side rendering.

• Buzzwords like “Cloud Computing” and “Virtual Worlds”? Check.
• VC Capital Funding? Check.
• Implausible Technology that doesn’t stand up to basic analysis by an industry professional? Check.

Say hello to serverside cloud based renderered virtual worlds. Somehow, against all odds a small unheard of Silicon Valley company has developed a real time renderer that not only exceeds the current best of breed distributed real-time rendering research projects by huge margins - does so in a way that’s scalable to deploy a major concurrent project on.

Doesn’t anyone in Silicon Valley do basic fact checking with a technical adviser before giving capital?

Assuming this company has actually succeeded in developing such a renderer (big if) isn’t there the additional problem of bandwidth? Let’s be kind and say the average user has a 1024×768x32 screen - that’s 24mbit of data that needs sending 30 frames a second (720mbit/sec), now yes you can use some video encoding to cut that down significantly - but that’s a heck of a lot of data, and the compression is going to induce processor load seizures too.

The answer to the above question is apparently not.

There is a big reason we do client-side rendering today, and that is it distributes the load better than any “cloud”. 100,000 clients = 100,000 processors, 100,000 graphics accellerators, etc. Yes some of them suck and can’t do pretty graphics (Intel I’m looking squarely in your general direction), but the rendering they can do is going to be better than what a foreign service can do for you, and it’s going to be speedier - not only do you not have to wait 200ms ping and a x megabyte download to happen before you see the results of your movement.

While I am not claiming that this technology couldnt be made to work - it’s just not going to be pretty, I dont believe it will scale anywhere near effectively, and the bandwidth requirements alone are going to cause some very tough questions to be asked about whether this will run at all. (After all - anyone with a internet connection fast enough to support this is going to probably have a decent video card anyway.)

Count me very skeptical.

Shouts to Belaya for adding to the snark contained within this post.

Sources are availible from the usual location:

http://forge.opensimulator.org/gf/project/xenki/frs/?action=FrsReleaseBrowse&frs_package_id=6

This is the rewritten version of the XBAP Viewer known as Xenki - this release has support for IRendering-style meshers, Terrain rendering and more.

I have added a password to a post listed earlier on this blog. As stated within that post, I do not enjoy writing negatively about people, products, groups, etc - and getting into arguments on the interwebs wins you nothing, but is great at wasting time.

In this post I made certain specific claims about a group and their public behaviour, that group has agreed to me to be more careful about what claims they make publically and improve general behaviour, and in doing so I have agreed to withdraw that post from the public domain. A password is now required to view the post and attached discussion - if you have a legitimate reason to want to read that discussion, my contact details are on this site.

While I still hold that the substantial portion of the original claims are reasonably correct - these claims are between myself (and certain specific developers) and the group, and a degree of confusion about the topic at hand has lead to an agreement that despite being cliched, there was a good deal of misunderstanding involved, one that if it is to be posted at all now, it should be posted in a terse clarified form which I will post if there is ever a need.

I’m glad to hear a little sanity coming from the New York Times on this matter (via Slashdot) - typing your password into someone elses website should always be consider a absolute no-no. It’s a phishers dream come true.

Why not? Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised. They do not want to take on the liability for mischief originating at someone else’s site.

If someone wants to design an OpenID-like solution the best answer is to do some form of challenge/authenticate redirect. IE - User visits site A to post a blog comment, wants to use their ID, They click ‘Authenticate me’ and enter the URL to the site that will authenticate them - the user is redirected to that site, SSL certificates should verify you are actually speaking with your authenticator, you login - then redirect back with an appropriate token matching the challenge written by the original site.

It’s a bit more complex than “Enter your password on Joe Shmoes website” - but the security benefits are considerably higher given you can verify you are sending your password only to Joe.

The rest of the times article is a discourse over whether we should abandon Passwords in favour of secret cryptographic keys - I believe the problem here is that ‘he who has the keys, has your account’ this means you either need to use one computer only (and forget about logging into your email from another persons machine), or you need to start carrying your crypto keys around with you and prevent someone from nabbing them.

The downside to passwords is however that they are incredibly weak security measures - a 1024bit RSA private key is a lot stronger than a 128bit password (8 ASCII chars) (each additional bit is a doubling in strength, so a 129 bit password doubles the number of possible combinations - 896 doublings is a lot stronger yet).

The best solutions are of course hybrids - when strong security is required (banking, etc) having some form of USB key that can perform RSA encryption for you within the token without revealing your key may be worthwhile - although it means you need to start carrying it around wherever you wish to do banking - however to activate the device some kind of password would be essential too to prevent someone from stealing it.

I love you Joshua, and I could not be happier. Of course I will marry you.

I was reading some of the trackbacks about the original Xenki article that I wrote and came across this particular piece, with the truthful accusation that the original post was rather fuzzy unless you are already familiar with a lot of the technology.

Xenki (Snowcrash reference?) is a browser add-on able to show the OpenSim environments inside the browser. The original post is amazingly fuzzy at explaining what it does exactly (just technobabble to anyone not deep into coding) but its the very basics of getting 3D inside a browser in a similar manner OpenSim renders the same content inside its client.

Well, it’s time to correct that with an introduction to the background technologies I’ve used in Xenki, their benefits and finally a summary of what the hell it is.

An Introduction to XBAP

XBAP is a browser technology that Microsoft recently developed - it first appeared on the scene with .NET 3.0, along with WPF and a host of other new technologies. XBAP is basically short hand for “XAML Browser APplication” - in english gibberish this means “Browser hosted .NET WPF Application”.

Which in turn means “Your standard Desktop Application, inside a tiny little browser space, but not quite.”, there’s a few major differences - first

You dont need to install anything - XBAP’s run the same way Java Applets do - they download the program code onto your computer, then launch it in a tightly secured “sandbox” so it cannot affect the rest of your computer.

No-click installation of a desktop application that cannot access the local system is actually a big benefit here - since we dont actually need anything on the local system to be able to run it, all our content is being loaded remotely anyway.

We can however for caching purposes install the application which will give it access to the local system - but this isnt required. It will display just fine on it’s own without.

An Introduction to WPF

The other acronym pushed above is WPF - WPF is short for Windows Presentation Foundation, this is a new graphics display system introduced in .NET 3.0 and Windows Vista, although it’s been backported to 2K/XP if you install .NET3.

It has some very cool features - including a well thought out 3D API which I have been using for the rendering thus far. XBAPs require that you use WPF for rendering purposes - but otherwise let you access the Windows API just fine.

And Xenki?

Xenki is basically an XBAP 3D application that works like a Java Applet. It embeds libomv for networking - so we can connect to Second Life / OpenSim style world without any issues. It does not need to be installed and runs just from within the browser by visiting a page. We can put it in a ‘portal’ on the webpage by using an IFRAME (similar to how Lively operates, except it uses an ActiveX control for rendering).

Why this approach is a good idea

The answer here is simple - we dont need to install anything, so web designers can embed Xenki controls on their website and expect people running Windows to be able to see them without any installations required. All you need is to be running a OpenSim, or have a space in Second Life that your users can be sent to, and be using either Internet Explorer or Firefox.

Finally the name - Snowcrash reference?

Yep - actualy the name was suggested by an employee at DeepThink, the fabulous Cichli Azure. Cichli was suprised to hear that only a single person has gotten the reference so far.

I hope that clears it up for people.

Every now and then, this hits me. I fire up OpenSim (or RealXtend), and it crashes instantly with a “BadImageFormatException” - when you see this, you know you have a compatibility problem with an embedded C/C++ binary. In english, 90% of the time this means you are running under a 64-bit environment with a mix of 64 and 32bit code trying to run together.

OpenSim is 64-bit aware

The reason for this happening is that OpenSim by virtue of the .NET platform is quite 64-bit aware, this means natively it can address 16TB of memory just fine if run on a 64-bit operating system. (nb, under Mono you need to make sure Mono is 64bit to get the same benefits).

However unfortunately, some of the libraries we link against have to be compiled ‘one way’ or the ‘other way’ and not both.  When running a 64-bit application, things such as memory pointer lengths are difference, so there is no way to cleanly pass data between a 32-bit and 64bit application - everything must be one or the other.

So how do you fix this?

There’s two routes, the easy route, and the proper route. The easy route is good for 90% of our users - if you dont need to access more than 4GB of memory and dont mind about the slight slowdown when handling double precision numbers, then just run 32-bit.

How? Instead of launching OpenSim.exe launch OpenSim.32BitLaunch.exe instead - this forces OpenSim to run under a 32bit environment (under windows provided by WoW32).

The more detailed fix

The next option is to strip out the sections that are causing problems. OpenSim is modular - so you can swap bits and pieces with their alternatives. The following are components that are not 64-bit compatible by default (however it is possible to fix this, something I will get to in a moment.)

Incompatible Components List

Physics - most problems come from our Physics Engines, since these tend to be written in high performance C/C++ with ASM littered. The following list of physics engines by default are NOT 64-bit compatible.

• OpenDynamicsEngine - The ODE DLL we provide is compiled for a 32bit operating system, however you can fetch the sources for our custom ODE DLL from (SVN) http://opensimulator.org/svn/opensim-libs/ and build it yourself on your native environment.
• AGEIA PhysX - The AGEIA PhysX support (now Nvidia PhysX) relies on a natively compiled 32-bit DLL. At present there is no fix here.

Compatible Engines

• BasicPhysics - This is purely managed but very simple in operation. Collisions are provided only between the avatar and the ground here. This runs without problems regardless of environment
• POSPhysics - POS physics is a more complicated BasicPhysics engine with bounding box collisions between objects. For some tasks this is sufficient.
• BulletX - Our own custom BulletX library is derived from the BulletXNA project, this is a properly developed fully managed physics engine that does proper collisions (however the friction coefficient can be a little low for some users).

Storage Engines - At least one of our storage engines relies on some hard coded components, it’s listed below

• SQLite - Whaaa? SQLite is broken on 64-bit environments? Afraid it’s true. Unfortunately on Windows systems the only solution is to recompile the entire of Mono (including Mono.SQLite.dll) yourself under a 64-bit flag.

Compatible Engines

• MySQL - The DotNetConnector provided by MySQL is 100% compatible and probably the recommended adapter for production installs.
• MSSQL - Windows-only however MSSQL is also free and the adapter is built into .NET itself so is pretty much guarunteed compatible.

Other incompatible components

Perenially we have problems with the following components in addition to the above, this includes libsecondlife’s OpenJPEG version - this can be fixed by compiling libsecondlife and OpenJpeg (using make) on the target system. This may have been fixed recently however as complaints about this DLL have lessened sharply.

Running

Once you have swapped incompatible components out, or recompiled them appropriately, OpenSim should run under a 64-bit environment natively on Windows. As mentioned above, under Linux/Mono you will need to make sure that Mono has been compiled as a 64bit application for this to take effect.

The differences between the two are mostly marginal, however there are some definitve improvements in certain mathematical loops and stability when using large amounts of memory. In production environments, running 64-bit mode can be an attractive option, however will require constant maintainence to compile the above libraries as new releases occur.

There’s been a rush of discussion recently about embedding virtual world technologies in the browser, I have seen two Java3D based implementations (which are very clever and deserve a closer look - especially if either is Open Source).

Tish has written up an interview with Avi who I mentioned earlier, on 3D in the Browser, the technologies and where things should be going - he’s very eloquent and I agree with pretty much everything he has to say. Avi added a companion piece with just a table of definitions and a small commentary on the article, which leads me to add my own comments on things.

First - the best browser is one that we dont need to install much onto the clients system, because the hurdle of making a plugin popular is a big one. XBAP is great for this since you dont need to install it to run it - it runs on a sandbox on it’s own just fine.

The downside to this is that we lose things like Local Caches which dramatically increase the load times when frequenting common areas - it would be nice to be able to optionally “Preview, then install” something we might be able to do via the XBAPs (one mode restricts to sandbox, other presumes it’s installed). Some experimentation in installing easily is going to need to be done.

I’ve been doing some further experimentations with XBAP (and yes, I’ll be posting the latest Xenki code shortly), and discovered some interesting things. First - 3D performance is no worse than a standalone WPF application, Second - it runs on Windows 2000/XP and up - I previously assumed it was Vista only, and was pleasantly suprised to find out this is not the case. Third - getting security certificates needed to automatically launch directly without install actually wont be too painful afterall (as long as libopenmv can get signed, we’re good.).

Cross Platform, Java3D?

The cross platform issue still remains elusive, which is why Java3D has caught my eye recently - given the similarities between C# and Java, it strikes me as potentially useful to be able to take large chunks of Xenki, run it through a special compiler and produce something that will run on Linux and Mac too.

The question becomes: why not use Java directly and skip the C#/WPF bit? Well the answer here is somewhat a personal one, first is that WPF is a lot easier to work with - this is an unfortunate fact of life, but doing things like UI ontop of 3D frames and doing it cleanly and efficiently is something that WPF has done so much better that there is almost no competition between them.

I personally have a preference towards doing things as quickly and cleanly as possible, worrying about making it functional rather than working on structural work that has already been done before - however if someone has already produced a good embeddable engine for Java on 3D pages - I’d be very tempted to at least try and give it a shot.

Java3D does also have the downside that it still sits in a sandbox, and the sandbox is mandatory - there’s no way we can implement a local cache using it to the best of my knowledge, I personally feel that the installable option is a very good way to cross the barrier between ‘hosted’ and ‘installed’ once the user is familiar.

Updated Xenki Sources

As stated above - I’m going to push the new xenki sources out in the next 24-48 hours. Watch this space as I will post the URLs and also the SVN address where I will be keeping changes.

I’ve noticed that there are a lot of resources out there for how to run your own OpenSim instance, but they are so disparate that finding them all can be a challenge, especially as each tends to have it’s own self contained target use case.

So in order to make life easier for people, I have compiled a list as follows

For Windows Users (Desktop and Server)

• Maxx Monde has written an excellent set of tutorials, you can read them as follows.
  • Part One: Compiling and Installing
  • Part Two: Commandline Usage
  • Part Three: MySQL Databases
• Virtual White has also a set of tutorials which cover mostly the same things as Maxx’s.
  • Part One
  • Part Two
  • Part Three
  • Part Four
  • Part Five
• OpenLife have a ‘ready to run’ standalone launcher which while lagging a few months behind the latest release, tends to be stable and easy to use.
• The “Semi-Official” Instructions from the OpenSimulator wiki
• How to connect to your OpenSim from the OpenSimulator wiki
• Tool: OSTray - OpenSim Tray Launcher
• Tool: DeepServers - ASP.NET GridServers (written by DeepThink)

For Linux Users (Server Oriented)

These links usually also work for MacOSX as long as you are familiar with a commandline.

• Official OpenSim Instructions
• Getting OpenSim Running on a VPS connected to OSGrid for $15/month written by myself. (Start to finish tutorial)
• Tool: Moo Console Launcher and Configurator
• Tool-ish: WiXTD - Based on the popular OpenSim Web Interface
• Tool-ish: OpenSim Web Interface (redux)
• Tool: OpenUGAI - Cgi-bin Perl GridServers (written by 3Di)

Pages worth bookmarking

• OpenSim Forge - Tools and Utilities for OpenSim and peripheral software.
• OpenSim Related Software Page - ditto.
• OpenSim User Documentation Page - User documentation from OpenSim developers
• Planet OpenSim - Blogs, news and other commentary on OpenSim
• OSGrid - Nonprofit free to use grid built by members, lead tester of the OpenSim software. (See also how to attach a region)
• RealXtend - OpenSim derivative with some cool features (Windows-only)
• SLUniverse’s Other Grids Forum
• OSGrid’s Forum

Enjoy. I will try to periodically refresh this when new useful resources appear.

This is just a very quick shout-out to the guys over at Microsoft - in particular Zain Naboulsi, their Virtual Worlds evangalist, for introducing me to David and Gerhard, the Project Manager and Lead Programmer respectively on the WPF Graphics Team, who have graciously offered me their time to help answer some performance related questions with regards to the Xenki viewer I have been developing.

My absolute thanks - it’s great to have such esteemed assistance on-hand, and I will be sure to be contacting you guys with all sorts of hairy questions about things I shouldnt be doing but am. *grin*