Improving O3D's hardware compatibility

Wednesday, July 1, 2009 | 6:54 PM


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.


DaVince said...

How about allowing to lower detail on the 65534 vertices thing? Meaning that, if there are too many vertices, it just lowers the amount of vertices, giving the user a lower-detail model in return (possibly relying on testing CPU power available to incrementally cut back polygons).

Well, I think it'd be a neat feature, anyway. It would certainly help on my low-end Eee PC if such performance features were added in. :)

Anonymous said...

There is nothing stopping an application from asking if you want to run the low-poly version of their product. On the other hand, for most products, there is no reason they can't split their geometry and just have look exactly the same and therefore not have to ask.

Arash Keissami said...

This update broke Windows 7 compatibility. I know Windows 7 is not officially supported yet, but it used to work prior to the last update. Now it doesn't, any idea as to when it may be fixed?

Arash Keissami said...

After trying to run XP through virtualization in Win 7 with no luck, I learned that changing the Compatibility mode of Firefox to Windows XP (SP3) will get O3D running in Win 7 again!

Unknown said...

Windows 7 is fixed in trunk. Hopefully will be able to push a patch ASAP.

Carsten Orthbandt said...

While I welcome the ease of use with your caps scheme I think a little bit more control would be helpful.
If say a game could detect if FP textures are available in the hardware renderer it could switch to a version of its content that looks better.
Asking the user to select the right one is a total no-go in my experience.

Unknown said...

i read somewhere that native client could be used for stuff like sound and physics which also are very important parts of most 3d applications.

but i don't this... what's the point of o3d then with native client? since if i understand this correctly native client could run any full blown game engine in the browser?

i am very curious who this whole 3d on the web thing will turn out. :p

Anonymous said...

Thank you . To all participant, please have a look at our updated contest post.
more templates easy to download

The Rainbow UI said...

Hello there,
Just want to know if there are plans to extend the O3D api to flash developers, actionscript 3.

Thank you
Best regards

DaVince said...

Sounds very unlikely. First of all, there's no reason, especially with more and more free and open technologies starting to replace Flash. Heck, even a Flash interpreter written in just JavaScript and SVG was released recently...

You have to keep in mind JavaScript is the most-used (and actually only) type of client-side scripting language specifically made for web pages and similar technologies out there.