A couple of weeks ago Google announced O3D: an open source web browser plugin for low level accelerated 3D graphics. The website for O3D project is here.

Of course this created some buzz (hey, it’s Google after all). And it is in some way a competing technology with Unity. I think it’s going to be interesting, so I say “welcome competition!”

Preemptive blah blah: this website is my personal opinion and does not represent the views of my employer, former employers or anyone else other than myself.

Unity is one of the players in “3D on the web” space. 3D graphics in the browser are in fact nothing new. Unity’s browser plugin has existed since 2005 and is now in eight digits installations count. There is VRML, X3D, Adobe Shockwave, 3DVIA/Virtools, software rendering approaches on top of Flash and so on.

In my view, major advantages that Unity has compared to O3D:

• It’s not only about the graphics. Unity has physics, audio, input, scripting, streaming, networking, asset pipeline and whatnot. O3D is only about the graphics, and at a lower level.
• Unity runs on wider range of hardware. O3D requires Shader Mode 2.0 or later hardware, so about 30% of the “machines on the internet” can’t run O3D (based on our 2009Q1 data). Couple that with lots of compatibility workarounds that we have and it’s probably safe to say that Unity is more stable and mature at this point.
• Unity is not only about the web. There’s support for iPhone, Nintendo Wii, standalone games, and with time more console and mobile platforms will come.
• Creating and improving Unity is our primary and only focus as a company. In Google’s case, O3D is just another technology in their vast portfolio.

Of course, O3D also has advantages:

• It’s done by Google! When Google does something anything, people notice immediately :)
• O3D is free and open source. Hard to beat the free price, and open source does have it’s benefits. O3D is not a “standard” of any sort right now, but it looks like Google would want it to become one.
• Only focusing on low level graphics has it’s benefits: it’s lightweight, it appeals to hackers and graphics programmers who want to be in control. Unity’s higher level is much easier and faster to use, but low level hacking can be fun.

Of course there are tons of other differences (I might have missed something important as well).

For me as a rendering guy, it’s interesting to see O3D taking similar decisions here and there (e.g. they don’t use GLSL on OpenGL either because it does not really work in the real world).

So… we’ll see where things will go. It’s going to be interesting!

Unity 2.5 is finally released. In summary:

Here’s what’s new. Here’s the download page.

My 11th Unity release since I joined 3+ years ago. This is quite a crazy release that involved almost complete editor tools rewrite and lots of other juggling. Was not exactly a walk in the park, but it’s done now. Meet me at GDC in San Francisco next week and I’ll tell you the war stories (Unity booth is 5110 NH).

Here’s the obligatory source code commits graph:

18 people involved in source code, 5315 commits, 18501 file changes. Of course, svn commits do not mean anything… I’m just fascinated by graphs and numbers.

A few weeks ago it was all calm in the source control. Now it’s crunchtime!

I’m the master of svn deception. I do tons of useless commits just so that the stats look good. Yeah!

…ok, back to work.

Yesterday’s experience catching up with Unity forums, as I remember it:

Take a quick look at zillions of new posts.

Answer about five questions with “what’s the value of your camera’s near plane?”.

There should be some way to automate all of this. For every 20th question, reply with “increase your near plane!”, or something.

Spent last week at our conference, Unite 2008. Lots of people, lots of stuff and goodness, tired as hell, but almost recovered already.

We showed a glimpse of Unity editor for Windows at the keynote, so it is public now – yes, we are working on Windows toolchain. About the time! This is the major area I’m spending time these days – Windows, Windows, Windows. Learning WinAPI as I cruise along :) Before Unity 2.1 I spent months fixing tons of small issues, now I’m spending months doing tons of small Windows related things. Someday I’ll get back to doing tons of small things on the rendering side.

Here’s a couple of random photos that I stoleborrowed from Mantas:

Keynote in front of a Sentinel from The Matrix.

Presenters talking.

People listening!

I don’t know that guy in the center. Probably some stupid outsider. Really!

I’m quoting awesome post by Charles Hinshaw from Unity forums:

I vote that we complain enough that they don’t share plans until everything is 200% done – I personally don’t want to know about a new version of Unity until after I have already shipped at least one game built with that version.

Alternately, UT could issue press releases that lack any information that might set expectations and/or require approval from third parties:

Unity Technologies ApS, announced today that they may be releasing an update to their popular game development software at an undisclosed future time.

From their offices in Copenhagen, Unity Technologies CEO and co-founder, David Helgason, said “We’re pretty excited not to announce anything specific about this potential upcoming release as we think that many of our users may be pleased by the addition of some number of features that may not have been present in previous versions of the software.”

Tom Higgins, Product Evangelist, added “The features in this software are making it possible for a number of undisclosed companies to work on various projects that may be released in the future. I think all of our users might be inspired by the things that may currently be under development with this future version of Unity.”

edit: Uhm, based on the replies that follow, apparently it wasn’t obvious that I am not seriously requesting this.

Way to go! :)

(if this sounds like a rehash of a blog post on blogs.unity3d.com, well, it is…)

Everyone knows the Valve’s hardware survey. But what if your target game players are not the traditional “big budget AAA game” type? For example, at the moment most Unity Web Player games are oriented to much more casual market, so hardware there might be very different. And indeed, turns out it is quite different.

Without further ado, here’s the data we have: Unity Web Player hardware statistics.

It’s about two million data points since we started gathering it earlier this year.

Some subjective points of interest (I’ll be using current data for 2008 Q3 here):

• Operating systems: Mac OS X is 2.5%, the rest is Windows. 64 bit Windows haven’t really picked up yet (0.7%). Windows 2000 is dying fast (0.7%). OS X Leopard already took over OS X Tiger.
• CPUs: poor Transmeta :) Dual core CPUs are becoming the norm (46%).
• Graphics cards: quite sad, in fact… top 15 cards are slow or horribly slow. Capability wise, they are quite good, with about 70% having shader model 2.0 or higher. Shader model 1.x cards are dead. “Can has DX10” is 2.7%.
• Casual machines don’t have lots of RAM. Nor lots of VRAM.
• Most popular nvidia driver? 56.73. Looks like this is the driver that comes integrated in XP SP2… Now, who says regular people ever update their drivers? Likewise, vga.dll (i.e. standard VGA) is 1.6% of machines; additional 1.5% don’t report any driver (not sure how that happens…).

So yeah. Casual machines: capabilities quite okay, performance low, low, low. That’s life.

In Unity we very often mix fixed function and programmable vertex pipelines. In our lighting model, some amount of brightest lights per object are drawn in pixel lit mode, and the rest are drawn using fixed function vertex lighting. Naturally the pixel lights most often use vertex shaders, as they want to calculate some texcoords for light cookies, or do something with tangent space, or calculate some texcoords for shadow mapping, and so on. The vertex lighting pass uses fixed function, because it’s the easiest way. It is possible to implement fixed function lighting equivalent in vertex shaders, but we haven’t done that yet because of complexities of Direct3D and OpenGL, the need to support shader model 1.1 and various other issues. Call me lazy.

And herein lies the problem: most often precision of vertex transformations is not the same in fixed function versus programmable vertex pipelines. If you’d just draw some objects in multiple passes, mixing fixed function and programmable paths, this is roughly what you will get (excuse my programmer’s art):

Not pretty at all! This should have looked like this:

So what do we do to make it look like this? We “pull” (bias) some rendering passes slighly towards the camera, so there is no depth fighting.

Now, at the moment Unity editor runs only on the Macs, which use OpenGL. In there, most of hardware configurations do not need this depth bias at all – they are able to generate same results in fixed function and programmable pipelines. Only Intel cards do need the depth bias on Mac OS X (on Windows, AMD and Intel cards need depth bias). So people author their games using OpenGL, where it does not need depth bias in most cases.

How do you apply depth bias in OpenGL? Enable GL_POLYGON_OFFSET_FILL and set glPolygonOffset to something like -1, -1. This works.

How do you apply depth bias in Direct3D 9? Conceptually, you do the same. There are DEPTHBIAS and SLOPESCALEDEPTHBIAS render states that do just that. And so we did use them.

And people complained about funky results on Windows.

And I’d look at their projects, see that they are using something like 0.01 for camera’s near plane and 1000.0 for the far plane, and tell them something along the lines of “increase your near plane, stupid!” (well ok, without the “stupid” part). And I’d explain all the above about mixing fixed function and vertex shaders, and how we do depth bias in that case, and how on OpenGL it’s often not needed but on Direct3D it’s pretty much always needed. And yes, how sometimes that can produce “double lighting” artifacts on close or intersecting geometry, and how the only solution is to increase the near plane and/or avoid close or intersecting geometry.

Sometimes this helped! I was so convinced that their too-low-near-plane was always the culprit.

And then one day I decided to check. This is what I’ve got on Direct3D:

Ok, this scene is intentionally using a low near plane, but let me stress this again. This is what I’ve got:

Not good at all.

What happened? It happened in roughly this way:

1. First, depth bias documentation on Direct3D is wrong. Depth bias is not in 0..16 range, it is in 0..1 range which corresponds to entire range of depth buffer.
2. Back then, our code was always using 16 bit depth buffers, so the equivalent of -1,-1 depth bias in OpenGL was multiplied with something like 1.0/65535.0, and that was fed into Direct3D. Hey, it seemed to work!
3. Later on, the device setup code was modified to do proper format selection, so most often it ended up using 24 bit depth buffer. Of course no one I never modified the depth bias code to account for this change…
4. And it stayed there. And I kept deceiving myself that the content of the users is to blame, and not some stupid code of mine.

It’s good to check your assumptions once in a while.

So yeah, the proper multiplier for depth bias on Direct3D with 24 bit depth buffer should be not 1.0/65535.0, but something like 1.0/(2^24-1). Except that this value is really small, so something like 4.8e-7 should be used instead (see Lengyel’s GDC2007 talk). Oh, but for some reason it’s not really enough in practice, so something like 2.0*4.8e-7 should be used instead (tested so far on GeForce 8600, Radeon HD 3850, Radeon 9600, Intel 945, reference rasterizer). Oh, and the same value should be used even when a 16 bit depth buffer is used; using 1.0/65535.0 multiplier with 16 bit depth buffer produces way too large bias.

With proper bias values the image is good on Direct3D again. Yay for that (fix is coming in Unity 2.1 soon).

…and yes, I know that real men fudge projection matrix instead of using depth bias… someday maybe.

I decided to make a very small game with Unity. Coincidentally, Danc of Lost Garden fame just announced a small game design challenge called “Play With Your Peas“. It comes with a set of cute graphics and a ready-to-be-implemented game design. What more could I want?

So it’s a small very small 2D game without any next-gen bells and whistles. It can probably be done casually on the side, by allocating an hour here and there. We’ll see how it goes. Hey, I never actually done any game in Unity, I only make or break some underlying parts…

Of course, first I start with no game, just imported graphics. Hey look, I can do sprites!

Then cook up some base things: define the game grid, throw in some basic user interface on the right hand side, and make it actually do something. This wasn’t so hard; that already gets me an almost working level building functionality. It does not have fancy block building delay or block deletion yet; that will come later.

Next come basic physics. Danc’s design calls for simple arcade-like physics (things moving at constant speeds, bouncing off at equal angles, and so on), but in Unity I have a fully fledged physics engine just waiting to be used. Let’s use that.

The design has sloped ramp pieces, which are hard to approximate using any primitive colliders, so instead I’ll use convex mesh colliders for them. Now, on this machine I only have Blender, which I totally don’t know how to use; and I was too lazy to go to PC and use 3ds Max there. What a coder does? Of course, just type in the mesh file in ASCII FBX format. Excerpt:

; scaled 2x in Z, by 0.85 in Y
Vertices: -0.5,-0.425,-1.0, 0.5,-0.425,-1.0, -0.5,-0.425,1.0, 0.5,-0.425,1.0, -0.5,0.425,-1.0, -0.5,0.425,1.0
PolygonVertexIndex: 0,1,-3,2,1,-4,1,0,-5,2,3,-6,0,2,-5,2,5,-5,3,1,-5,5,3,-5

It’s a left ramp mesh! So much for fancy asset auto-importing functionality, when you don’t know how to use those 3D apps :)

After a while I’ve got peas being controlled by physics, colliding with level and so on. Physics is very bad for productivity, as I ended up just playing around with pea-stacks!

So far there’s no game yet… Next up: implement some AI for the peas, so they can wander around, climb the walls, fall down and bounce around. I guess that will be more work and less playing around… We’ll see.

This is just too cool: Off-Road Velociraptor Safari game. Read that again. Who says game industry is all about sequels and safe licenses?

You drive a jeep with a spiky ball, and your goal is to chase down raptors and send them to the future, presumably to end world hunger. Or you can do stunts. And you the driver are a raptor, only you wear a hat and a monocle.

Just go and play it already: raptorsafari.com. It’s free.

Or watch a trailer if you want to miss all the real fun, or read a press release. Of course it’s made in Unity, in two months from start to finish.

To me, this is a perfect example of focus. Basically there are three things – 1) vehicle, 2) raptors, 3) physics mayhem – and that almost describes a game. Yes, there are crates and stunts and achievements and online leaderboards, but that’s just additional stuff on top of the core game.

Sounds like a good plan for making game prototypes:

1. Think up a game idea and describe it in one concise sentence. The idea may be totally crazy, like in this case. I guess an idea like Velociraptor Safari would not fly in a pitch at any publisher, but that does not matter at this point.
2. Get a small team of smart people. In Flashbang’s case, it seems they were 4 to 7 person team.
3. Choose a game engine/toolset that will allow you to make your game fast. *cough cough*
4. Do it!

All the above requires is a small smart team and groceries/rent for a couple of months.

Your original idea may be totally crazy, but with the actual working prototype at hand it might just work. Looks like Velociraptor Safari really clicked something on the internets (see Kotaku, JayIsGames, Destructoid, TIGSource, AtomicGamer, …).