My first reactions to Google’s new O3D JavaScript API is “Thank God someone finally did it.”, a more detailed examination appears to yield something like Mozilla’s proposed Canvas3D but with practical implementations for all the major browsers and platforms (IE, FF, Win, Lin and Mac) - something Canvas3D was unlikely to get.

Fig 1. O3D Beach Sample

O3D has the advantage of being really the first proper 3D implementation for a browser to market (I won’t count Flash3D here since hardware accelleration is key to doing serious work with 3D.), it’s in ECMA/Javascript which makes it pretty accessible to a wide group of developers - and the API appears to be logical and powerful.

It’s backed by Google which will make overall deployment better - and I would be keen to wager that this endevour goes a lot further than Lively did. The runtime is even availible under the BSDL - which makes it very attractive to commercial users.

Could someone implement a virtual world with it?

I think for singleplayer games O3D is perfect - it’s easy to deploy, easy to write, uses standard file formats. Multiplayer - where VW’s come in is a much tougher nut to crack because there is still a dearth of reasonable communication standards for browsers.

AJAX is by communications standards not very powerful - it relies on the idea of a single thread carrying request/response packets. It can be hacked up into supporting threaded packeted communications - but I believe any virtual worlds using O3D will probably be those that can survive a larger latency (eg There.com(R) versus Second Life(R)) - worlds using it will use a lot more clientside processing to minimise connection loss.

The discussion on #opensim-dev this afternoon about O3D has been promising - it holds a lot of potential, and whether we can utilize it to write a simple browser plugin is going to be an interesting project for the next few days.

Graphically O3D has most of the niceties that a modern 3D engine expects (Shaders, etc) - the keys are going to be in the difficulty of writing scene and state management in Javascript, and making sure the communications systems are as simple and efficient as possible.

The ease of install and the lack of serious memory limits on the 3D scene means this may be a better option than Java3D for an accessible virtual world. Stay tuned.

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.

A quick update: Well, it looks like I’ve managed to almost solve the issue which I listed previously.

Here’s some screenshots of things sort of almost rendering correctly.

and one more showing the detail of one of Cubey’s planes (in this case his Ornithopter - and it renders correctly!)

Will post more screenshots later once I have completely fixed that issue.

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.

The basic rewrite of the viewer has been done, I’ve seperated out the renderer and the network code into seperate classes (which in turn will be abstracted into interfaces once I have a good idea on what functions are going to be required). There is a screenshot attached below.

Basic Scene Rendering using BoxRenderer.

Switching to a more advanced mesher

One of the things I have been tinkering with has been using more advanced meshing algorithms. libomv now has a IRendering interface which actually acts as the host for a variety of meshers (GPL, BSD, and others with varying levels of accuracy) - I’ve decided to use this interface internally when hooking in the mesher for the default renderer, so we can use any supported mesh generation algorithm, including both the GPL’d one derived from the viewer, the BSD box renderer, and potentially OpenSim’s BSD Meshmeriser. (The latter being my personal preference - since I’d like to be able to actually take a look under the hood rather than linking to magical black boxes. Insert obligatory licensing complaint here.)

In english - we can make things look prettier. The above screenshot was with the simple box renderer, the one below was linked against the more advanced one. The difference between these two functions is a single line of code and a difference reference when compiling the XBAP.

Now unfortunately, since I’d rather keep Xenki under a BSD/MIT-style license (usual reasons) - the distributed sources I’ll be releasing wont be linked against the more advanced renderer which I’m using for the screenshot below, but I do plan on spending some time tommorow attempting to get Meshmeriser working in it’s place if I can.

The timeline from here

My goals with this will be to try get textures (at least in a preliminary fashion) done tommorow, after that I will look at adding UV and Normals support to Meshmeriser and convert it to a IRendering interface so we can use it.

I also plan on cleaning up the UI a little more, below is a screenshot of the basic login form that now exists (so usernames and passwords are no longer hard coded, and this is almost venturing towards being sort of usable)

With a little luck, this will be sort of usable for basic navigation and viewing by the end of the week. I will post an updated source package sometime between now and then.