Improving O3D's hardware compatibility

We stated before that one of the goals for O3D is to have no caps bits. That means, not having to make your code check if the user's machine has feature X: You can write your application and you can assume it will run on any machine. We also wanted to select a feature set that we thought would be a good trade off between allowing high end real time 3d graphics and running on the majority of machines currently in use without being too slow.

Unfortunately, there are a few extremely popular GPU chipsets out there, like the Intel 950 for example, that were missing a couple of these base features we felt were important. Without those features certain common effects, like floating point textures for shadows, would not be possible. We could have just used the software renderer on machines without those features but the software renderer is not as fast as GPU hardware so we came up with what we think is a reasonable solution.

When your application starts up O3D, it can tell O3D what features the application requires. If the user's system supports those features then O3D will use them. If the user's machine does not support those features O3D will fall back to a software renderer. If you do not explicitly request those features then O3D will not let you use them.

We chose this solution because it provides the ability for a much wider range of applications to use GPU hardware than before. For example, only 3 of our samples required additional features to be available, which means most of the samples will run with GPU hardware acceleration even on low-end GPU hardware.

The specific features you can request are:

1. Floating Point Textures.
2. Geometry with more than 65534 vertices.

If you are using our sample utility libraries, the second argument to o3djs.util.makeClients is now a comma separated list of features you want. For example:

o3djs.util.makeClients(initStep2, 'FloatingPointTextures');

will request floating point texture support for your application.

If you dig into our samples you'll notice this is only used in 3 of our samples so far.

1. generate-textures.html uses floating point textures.
2. vertex-shader.html geometry with more than 65534 vertices.
3. The beach demo because it uses geometry with more than 65534 vertices.

For those last 2 samples, we could have avoided requesting those features if we wanted to. For example, in the case of vertex-shader.html we could just slightly lower the resolution of the plane that it animates. For the beach demo we could split any models with more then 65534 vertices in half and draw the 2 halves separately. This shows that many applications do not need those features or can be refactored to not need them and so a very large percentage of O3D applications can run using hardware accelerated graphics. Higher end applications that need those features can request them and they'll still run everywhere, but for applications that don't they'll be able to use hardware acceleration on a much much larger set of computers.

One question that is likely to come up is, "Could this solution be used to add really high end features like Shader 4.0?". The current answer is unfortunately "no". The reason is, if the user's machine doesn't have those features O3D uses a software renderer. Unfortunately we don't have access to a software renderer that could draw Shader 4.0 features at a reasonable speed.

We hope you'll agree that getting hardware acceleration on as many machines as possible is as awesome as we think it is. This change helps O3D run its best on a much larger set of computers.

Posted by Gregg Tavares, O3D Team