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.

It’s been a number of months since I last looked at the State of Open Viewers back in december.

Since then there has been some coalescence on Idealist as the platform-of-choice for the future viewer. While Xenki has some definete nice features (browser access, reasonable UI), it has some problems too (32-bit only, security sandbox issues, etc)*. I’m hoping we’ll be able to take some of the UI handling code (camera control, etc) from Xenki and import it into Idealist to get a best-of-both result.

Right now, the Idealist renderer is pretty good – it’s rendering things close to 90% accuracy, the remaining 10% include avatars (a somewhat complex topic), some sculpted parameters, and special effects (glow, bump maps, etc.). The following two screenshots should give you a good approximation of the rendering capabilities of Idealist right now.

Fig 1.1 - Idealist Viewer

By contrast, the same scene in the Second Life viewer is fairly similar

Fig 1.2 - Second Life Viewer (1.22)

You can view this scene on OSGrid.org, it’s in the region “DTL Welcome Center” (a side project to build a new Orientation Island for osgrid.) – it makes a good test of a renderer since it uses almost every graphics feature on offer right now.

The most noticable differences between the viewers in terms of accuracy come down to a couple of minor but fixable points

• Texture alignment – Idealist doesnt process extra texture parameters; rotation, scale, offset, etc. Most of these are fairly simple to implement, so this should not pose any long term difficulties.
• Mirror X / Invert Sculpt Parameters – Idealist doesnt process these flags, so some of the sculpts are inverted (noticably the orange signs).
• Alpha smoothing – Idealist produces ‘rough edges’ on alpha surfaces, this is fixable with some tweaking of the renderer parameters.
• Texture Downloads – Not a bug in the renderer, however the texture download routine suffers issues with download speed and incomplete downloads. This is somewhat fixed in MXP due to MXP using plain HTTP for asset distribution – but under LLUDP some additional work needs to go into libomv to handle asset transmission better.

While that is not an exhaustive list – the current feature state is pretty good. Where work needs to go right now is in user interface (doing cross platform UI with 3D surfaces under .NET is interesting, let me assure you.) – one of the UI proposals I have been working on is pictured below.

Designing a Viewer UI

Fig 2.1 - Idealist UI Mockup

The main idea being to reduce clutter where possible – things such as Inventory are needed often, but arent needed permanently. Implementing these as a docking toolbox allows you to expand the inventory dock quickly and easily – while not having it consume significant screen real estate unnessecarily. As mentioned above – getting a design like this to work cross platform is difficult, infact it may even be easier to write a UI toolkit for Irrlicht than to attempt to embed Irrlicht into a UI toolkit while maintaining cross platform support.

MXP

One of the more interesting features of Idealist is the ability to connect a client on the newly implemented MXP handler. While getting it running requires a lot of technical knowledge right now – the MXP protocol has a lot more potential than the LLUDP one does for expansion and interactivity. There are also a number of improvements MXP makes to the transport layer which should improve scalability for the server.

Fig 3.1 - Idealist/OpenSim via MXP (source)

You can play with the MXP version by using the MXP branch of IdealistViewer, use the following settings when doing an SVN checkout

SVN URL: http://forge.opensimulator.org/svn/idealistviewer/branches/idealistviewer_mxp_0_0_1
SVN Username: anonymous
SVN Password: anonymous

There are some other benefits visible on LLUDP too, including a fixed water shader, better terrain handling and other renderer improvements which have not yet been migrated back to Idealist Trunk. When connecting, you will need to connect to the region in the format “mxp://ip:1253/<region uuid>/Test/” – note that on public grids exposing your region UUID can be a risk (some work being done on improving this).

Contributing

Finally, there’s a call for some contributors to Idealist – right now the major developers are also major OpenSim developers. We’re looking for some graphics specialists to come in and help with the design of Idealist – there’s a number of bugs and features which could do with patches, so if you are interested, please hop in #idealist-dev on Freenode.

I’ll repeat the call for Xenki if anyone is interested, I’m currently looking for a new maintainer to take over the role. Shoot me an email (see contact page for details) if you are interested in taking over the lead developer role on the project. (Update: Maintainer has been found.)

So, I’ve discovered XBAP. It’s a little secret technology that Microsoft developed as a way of running WPF applications in a browser, and I do have to say it’s very useful and handy.

An XBAP is a full blown application running on the .NET platform. It can access everything .NET can access within a security sandbox – including the Direct3D API. The sandbox is a little bit annoying but quite understandable – and most awesomely – it runs under Firefox fine, I’ve been using Firefox to debug.

Why not Silverlight?

When Silverlight was first released – I was quite intriguided. Not only do you get C# and a .NET environment, maybe we could do a version of OpenViewer running in Silverlight? We’ll after careful examination – Silverlight is capable of neither decent network access, nor any hardware 3D rendering capabilities. (I do have to question someone investing all this time in a “Flash Killer” and neglecting to add 3D capabilities. But I digress…). So the idea’s been dormant ever since I discovered this.

A few days ago, after my friend Tish Shute mentioned a MS developer talking about tighter integration between Direct3D and WPF the other day, I dug up in my head this thing I’d heard of once before called an XBAP – it’s basically a WPF Application, but hosted inside your browser, and in the last year since I checked it out, XBAP has improved a lot.

For one, it worked inside my Firefox browser painlessly without me apparently having to install anything (.NET had already put the appropriate plugins in place). It also just-so-happens to support hardware 3D rendering, direct network access (Hi libsecondlife libomv!), and a few other shiny things as long as the application sticks in it’s sandbox.

OpenViewer – meet Lively.

One of the things I really do dig about Google’s lively client is just how seamless it integrates in your browser. It’s not a full blown 3D world no, but I think Google got one thing right: Make it as easy to get instant gratification as humanely possible.

I think this is one lesson that the OpenViewer project might be able to take onboard – and XBAP might be an easy way to get there (at least for Windows clients)

The drawbacks (and there’s some reasonable ones)

Nothings perfect, and unfortunately this isn’t a perfect solution either. There’s some problems that wont be completely easy to solve, and some aren’t solvable in the current form.

First is the security sandbox – unless the user downloads and installs the WPF application (then hosts the installed copy) you get no local storage meaning no cache or access to the local harddisk (including uploads). Big catch.

Second big catch – it’s Windows only. Looks like Vista at that. While it may run on Firefox under Vista, this wont be a foolproof solution for Mac or Linux users, at the moment, Mono lacks a complete WPF implementation which means it might be a while before they get it (and even then it would be in standalone mode rather than in-browser)

Third catch – Performance doesn’t seem highly optimal when rendering complex 3D scenes. This one I think may come largely from the experiments I have been doing using a lot of brute-force methods, I expect this one to be somewhat capable of workarounds.

Toying as a viewer

Right now, I’m in the early early stages of getting a viewer up and running as an XBAP – text-only we can do no problems, getting 3D in adds a degree of complexity since we still cant use libprimrender due to LL licensing issues. I’ll be using the OpenSim Meshmeriser library instead here for the moment, although accurate rendering would be great.

I expect to post some screenshots in the next few days as I get this to a reasonable level – if you are lucky, I might even publish the XBAP file so you can play around with it. Source will be forthcoming after I’m happy enough with it.

It’ll go under a different name to OpenViewer – mainly because of the non-portable problem. I’m using the name internally XBAPViewer right now, but I’ll think of something better before it’s released.