When we started out with O3D we knew what we wanted to achieve: we wanted to create a browser API that provides developers direct access to the powerful 3D graphics hardware that's inside most modern PCs. We wanted it to be fast; fast enough to handle the complex rendering needs of a high-end video game but without making any assumptions on what it would be used for. In essence, we wanted to provide the flexibility and speed of a low-level graphics API like OpenGL or Direct3D, while addressing the constraints of running inside the browser.
Bind a shader.
Provide values for all the shader parameters. Even simple shaders require a handful of parameters like the view projection matrix, light positions and texture sampler settings.
Assign vertex streams such as positions, normals, tangents and texture coordinates.
Set the necessary render states such as blending modes and culling.
Issue the draw call.
A few other things are worth noting about O3D:
We had decided early on that in order for O3D to be useful we need to take all the steps necessary to guarantee that the images we render look the same, regardless of the GPU or the OS it's run, so that developers can trust that what they see on their computer is exactly what all their users will see as well. In order to achieve that, we settled on a GPU spec that we feel offers a good balance between being inclusive and providing access to modern GPU features. GPUs that run O3D must be capable of at least DirectX 9.0 graphics and we only accept Shader Model 2.0 pixel and fragment shaders. We believe this covers over 60% of the GPU installed base today. For the remaining ones we are looking into providing a software rasterizer. If you feel that we haven't quite hit the right sweet spot, either that we're limiting GPU features too much or that we're not inclusive enough, please let us know here .
We believe that one of the big advantages of implementing an API that isn't exactly based off of an existing API such as Direct3D or OpenGL is that it gives the implementaters the flexibility to chose the appropriate low level graphics API to build on top of, depending on the platform. In our case, we chose to use Direct3D on Windows (DirectX enjoys a lot better GPU driver support on that platform than OpenGL) and naturally OpenGL on the Mac and Linux.
In closing, I'd like to say that what you see here is an API that was designed by a group of engineers coming from all sorts of different backgrounds: some graphics people, some games people, some web folks. We're proud of what we've created but at the same time realize it's not set in stone in any way. It's really our contribution to the discussion on finding a standard for 3D graphics in the browser, a cause that we're really committed to. As such, we always welcome your feedback, comments and even criticism! Please let us know what you think of it, and how we can improve it. You'll find links to our discussion group and moderator app in our front page (http://code.google.com/apis/o3d).
Posted By Vangelis Kokkevis, Software Engineer, O3D Team.