This is an informal announcement that work has begun on WebGL and bringing some of GLScene browser-side!

If you’ve got a a WebGL-capable browser (see “compatibility” below) click on the following links to see it in action:

There is a simple variation on the classic NeHe tutorials templates and a first try at a heightfield, built at runtime with automatic normal computations on the JS-side, and illumination on the shader-side.

Compatibility

• Chrome: since Chrome 18, Google bundled SwiftShader, a software rasterizer, meaning that WebGL is now available everywhere (in hardware or in software).
• FireFox: on the desktop, availability depends on hardware + drivers. Mobile FireFox for Android also supports WebGL (at least it runs on my old HTC Desire, which is of the same generation as Google Nexus One).
• Opera: should also support it from version 12 both on desktop and mobile. Opera 12 on Android runs the above POCs on my HTC too.
• Safari: under MacOSX WebGL should be supported (couldn’t test that), though Windows Safari doesn’t support it. As of iOS 5, WebGL is only supported for iAds in iOS.
• Internet Explorer: not supported out of the box, but you might be able to use extensions like IE WebGL or Chrome Frame.

Is WebGL ready just yet?

If you scout the web, you’ll find multiple things are missing, especially from game usage point of view, things in the environment (such as going fullscreen, capturing the mouse or preventing screen rotation on mobile devices), or in the advanced rendering capabilities (multiple render targets, double precision buffers, NPOT mipmaps…) however those limitations are getting spec’ed right now by the Khronos group, and they are not relevant for a whole variety of visuals: simpler games, business graphics/visualization, education animations, static 3D representations, etc.

So, no, it’s not really for prime-time for all uses, but it’s certainly starting to become usable if you’ve got some control over the browser or the target hardware.

Architecture

This isn’t going to be  a straight port of GLScene, but more of a rewrite, based on ideas that were discussed a few years ago for GLScene 2.0. So the architecture will be different from that of FireMonkey’s 3D too (since FMX is based on DXScene’s, which is essentially a cut-down version of GLScene’s with cross-API drivers), it will be an architecture targeted from the ground up at shaders, OpenGL ES 2.x+ capabilities and extensibility.

A key difference is that the renderer and the scene-graph won’t be tied together, but separate, and the materials will be separate as well. I’m also planning to have a shader synthesizer early on, so classic material properties and lighting modes can be recreated easily, without having to write a single line of shader code.

Another item in the plan is to leverage partial classes, as a way for renderer and scene logic operating on the scene-graph to inject custom properties and methods, without having them built-into the core scene-graph classes, or go through registration schemes. This should hopefully allow the core classes to remain light, highly focused, and help combat bloat in the long run, by allowing extra features to stay purely optional, even if they require introducing interfaces or new virtual methods right at the root scene class level.

Availability

The lead platform is going to be SmartMS/DWScript, core units will rely on some advanced language features (like partial classes or generalized helpers), but with a long term goal of supporting other Pascal dialects as well (those that catchup feature-wise).

In the next SmartMS version, WebGL import unit will be available. They’re based on the WebGL specs, and provide external classes and constant declarations, so you can use WebGL with compile-time strong type checks, and edit code with ctrl+space suggestions.

Coming alongside are the WebGLScene units, which provide a set of vector/matrix maths routines, helpers for vertex buffers, shaders and texture objects, as well as what is currently the embryo of scene-graph.