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.

Yep.

I said it - one of the things that’s been touted as so fantastic about SL’s rendering performance is the speed at which you can push them to the graphics card, the amount of caching in vertex buffers that can be done, etc.

I’m about to say that it actually doesnt seem to matter that much, and Prims lose out in a lot of cases for some very interesting, but difficult to fix reasons, and doing performance workarounds for this is going to be complex, irritating and make me wish I was dealing with my precious meshes.

I should note here, that the performance of the XBAP application on my crummy laptop graphics card is still relatively solid - and I’m brute forcing nearly every operation at this point.

Reason Number Uno: Fill rate, “invisible” triangles.

Prims waste a lot of triangles in areas we cannot see - occlusion culling of whole objects works well here, but it doesnt work when we’re dealing with potentially a few thousand triangles that are part of an object, but inseperable. This is mostly due to construction techniques than something we can fix at the renderer level, but nonetheless it has a major impact on performance.

Possible Solutions

I’m experimenting with using CSG (Constructive Solid Geometry - boolean operations) at the moment as a method of reducing the number of hidden triangles pushed to the screen. This will have some complexity when involving transparent surfaces, but if we discount transparent primitives from the algorithm we may get a reasonable reduction in the number of triangles pushed to the screen, at the expense of increasing the number of vertex buffers used (prims do have vertex caching on their side).

This is something I plan on experimenting with and am looking at ways to do CSG in C# without me having to dig out research papers.

Reason Number Duo: Really Inefficient Texturing

This is a more annoying issue - namely that as we start drawing triangles for the procedural surface, we have to flick texture index multiple times to render the primitive (assuming it isnt the same texture on all sides), on a spherical or curved surface this isnt so much of a problem - we push a few thousand, flip, push a few thousand more. Fine.

On boxes - Push 2 triangles. Flip. Push 2 triangles. Flip. Now, of course it’s better not to flip at all - and as some people will point out, pushing 2 triangles vs a few thousand is better and still more efficient. The problem here is how primitives differ from mesh based models.

Traditionally in mesh based modelling, you generate a single texture with a uv map for the entire object. By wrapping and contorting it, you can render the entire object as one single pass, which means we dont need to pause, do a new texture lookup, repeat as many times. It still happens occasionally, but the number is much much lower.

If your scene (such as in a modern game) only has 50 uniquely textured objects on scene at once (look closely and you will find it’s probably not much higher than this number) this is fine. It works well - if we appropriately stage our render pipeline, we might even be able to group these into a single pass each.

SL? Your lucky if your scene has less than 100 textures visible. I’ve seen regions where this number is many times more, potentially in the thousands — and as I pointed out earlier, we’re flipping textures midway through rendering single object collections, which is possibly hurting the performance gains we are making by being able to cache those collections originally.

Yeuck.

Some possible solutions here

There’s a couple of potential solutions to this, but I think the easiest one is to leave this to ATi/NVidia/Intel - pipelining similar textures is something I expect their drivers to do. If this does become a problem, I have some ideas in place for grouping similarly textured faces from different primitive groups into single vertex collections.

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.