There are some API changes coming in WebGL, which will probably require pretty much all of the WebGL content out there to be modified; the changes are likely to go live in Minefield in a week or two, so we need to get moving! Vladimir Vukićević and Benoit Jacob have given the details in two posts on the public WebGL mailing list. Here’s a summary:

• Fragment shaders will now be validated to make sure that they are correct for WebGL / OpenGL ES; previously you could get away with using quite a lot of desktop OpenGL stuff, in particular missing out the mandatory precision specifier in fragment shaders (see the mailing list for details and a fix from Vladimir). In the short term, whether or not this validation happens will be optional, decided by the brower’s user, and off by default. However, it will become mandatory, so you should switch it on now to test your content. To switch it on:
  • In Minefield, go to about:config and change webgl.shader_validator to true.
  • In Chromium, pass --enable-glsl-translator in on the command line.
  • There are no details on how to do it in WebKit yet.
• The gl.texImage2D function has changed its signature. Brandon Jones posted about this the other week, noting that Chromium warnsyou when you use the old form; both old and new forms of the function have been supported by the browsers for a while, but the old one will soon be gone.
• As Andor Salga mentioned recently, gl.readPixels has also changed.

So, I’m going to go through all of my demos and tutorial code and change to the new APIs; if you have WebGL content live on the Web, you should too!

Quite a lot of links for today, some of them quite old — but now my backlog is cleared, and just in time: SIGGRAPH is running right now — Dennis Ippel and Benjamin Delillo, who often appear in these roundups, are there — so I’m sure we can expect a rush of further news over the next few days :-)

• On the WebGL developers’ list and on his blog, Peter Nitsch has posted about some really cool pages he’s built using Flash to access your webcam and provide textures that can be used in WebGL scenes: a cube, and adaptions of two of IQ’s demos, a kaleidoscope and a raytracer — very cool stuff! So Flash is still good for something ;-)
• An even prettier demo, also from Peter, is this Mandelbox explorer.
• I mentioned SIGGRAPH — one of the big announcements there was that AMD will be shipping EGL and OpenGL ES drivers for their graphics cards, which are better-known under their ATI brand. If you’re wondering why that’s important for WebGL, given that it works on ATI cards already, Vladimir Vukićević has an explanation.
• SceneJS V0.7.6 has been released! It’s has more new features than I can list here, so follow that link.
• Some great new demos for Paul Brunt’s GLGE: 2D filters, video textures and canvas-based textures.
• A bit of a mash-up from Dennis Ippel: visualising Last.fm data with WebGL, GLGE and jQuery.
• Here’s a formal academic paper on SpiderGL.
• Here’s a fun game from Nikolaus Gebhardt (one of the CopperLicht guys): WebGL Asteroids. The author’s written about it here, with an interesting comparison of how “ready” the different technologies he used are.
• Charles Cliffe’s CubicVR 3D engine now supports GPU fluids.
• A demo of using multiple animated lights in X3DOM.
• From Andor Salga, a useful hint about using gl.readPixels, which is currently implemented differently by different browsers.
• Andor’s XB Pointstream is going from strength to strength, and now supports streaming so that you don’t have to wait for a whole point cloud to load before you see it — useful with demos like their 22Mb model of a lion!
• Fun: some models from a computer game called “Yo Frankie!”
• From Max (aka Yi Ren) at the University of Michigan, a car modeller that he’s ported from Sketchup.
• Here’s a real-world use for WebGL: proving that the crescent moon is drawn wrongly in children’s books :-)
• If you’d like a solid introduction to WebGL, this is worth reading (via Henrik Bennetsen)

We’ve released XB PointStream 0.4! Have a WebGL-enabled browser? Check out the demos! Or check out our video.

What is XB PointStream?

XB PointStream is a JavaScript library which will emulate Arius3D‘s PointStream viewer. It is designed to quickly render a large amount of point cloud data to the <canvas> tag using WebGL.

Features Landed

In this release we added streaming support, you no longer have to wait until the entire point cloud is downloaded before viewing it. Also, there was an issue rendering on some versions of OS X and Linux, which we fixed. Our PSI reader is coming along and has been pushed into our Github repository.

Get Involved!

If you’d like to get involved in development, testing or if you simply want to suggest ideas, visit us in the #seneca channel in irc.mozilla.org. Or file some tickets on our Lighthouse page. If you wanna get your hands dirty and hack some code, fork our repository from Github.

WebGL Mandelbox Explorer

Note: This demo requires a WebGL capable browser. Installation instructions can be found at Learning WebGL or the WebGL Wiki.

This weekend I put the finishing touches on a WebGL Mandelbox explorer I’ve been tinkering with for the past week or so. If you’re interested in the mathematics, Tom Lowes who wrote the Mandelbox formula does a good job explaining it in detail on his site. I’ve been captivated with the pattern ever since watching Krzysztof Marczak’s amazing Mandelbox trip on YouTube (a must-see).

Traversing a 3D Mandelbox in real-time is intensive on any platform, but WebGL does a fairly good job thanks to the GPU. I still need to lower the fractal iterations upon interaction, but that was expected. Rrrola was nice enough to post some source for his real-time explorer, which I ported to this version. I’ll add my own refinements over time as I get more comfortable with the formula.

There is plenty of room for refinement, but basic mouse and keyboard movement controls make exploration fairly simple. Things like camera viewing angles will be patched in over time.

This will be an evolving project. If you stumble upon any bugs or have suggestions, I’d love to hear them.

• Sick of JavaScript’s and GLSL’s syntax? Well, you could try writing your WebGL code and shaders in C# and cross-compiling them…
• Andor Salga has released version 0.3 of XB PointStream, a WebGL viewer that can show models made up of massive numbers of points.
• Here’s another website Andor’s done, with an appropriate name: http://www.doesmybrowsersupportwebgl.com/. Must have taken ages to write ;-)
• A fun WebGL game from 3dgames.pl: Curling (the blog post is in Polish, but the game is in English).
• This is the Toronto WebGL Community! Hmm, anyone fancy a London WebGL meetup?
• Benjamin Davis is using the O3D port to WebGL; starting with a a spinning cylinder but immediately moving on to something much more advanced: depth-of-field post-processing (sadly the latter didn’t work for me in Minefield — but it was fine in Chromium).
• If you want to add your thoughts on the pros and cons of WebGL, here’s a good place.

Sometimes I want to know if my browser supports WebGL–without loading a large and fancy demo or digging through about:config.

www.DoesMyBrowserSupportWebGL.com will give me a straightforward answer. This is especially useful if your desktop looks anything like mine:

Is WebGL enabled? Is this new demo broken? Didn’t I just do an update? Am I using the right profile? This site expunges one variable to investigate.

Yay or Nay.

I’m currently working on two projects which, in some way use WebGL‘s readPixels(). In Processing.js it is needed when running ref tests with 3D sketches. In XB PointStream it is used to get a screenshot of a point cloud on the user’s request.

In my last blog I wrote about some trouble I had calling readPixels(). It worked on Minefield and Chrome, but not on WebKit. Benoit Jacob mentioned the problem could have been due to a change in the WebGL specification. I re-checked the spec and sure enough, readPixels() was changed. To support both methods (old and new), I needed to write a work-around. It didn’t take long to come up with something that’s cross-browser. Here it is:

var arr = ctx.readPixels(0, 0, w, h, ctx.RGBA,
                         ctx.UNSIGNED_BYTE);
if(!arr){
  arr = new WebGLUnsignedByteArray(w * h * 4);
  ctx.readPixels(0, 0, w, h, ctx.RGBA,
                 ctx.UNSIGNED_BYTE, arr);
}

If you want to see it in action, check out our 3D point cloud gallery.

We’ve released XB PointStream 0.3! Have a WebGL-enabled browser? Check out the demos! Or check out our video.

Features Landed

In this release, we decided to add some elementary features such as mouse and keyboard support, but we’ve also added interesting bits like toPNG(), resize() and attenuation(). With toPNG() you can create a static 2D image from the 3D point cloud. resize() simply resizes the canvas and attenuation() along with pointSize() allows you to finely tune the point attenuation desired for your point cloud.

Bugs!

While working with Minefield, Chrome and Webkit, we’ve seen several inconsistencies. One major issue is toPNG() doens’t work on Webkit because readPixels() now fails. But it used to work! Another issue is rendering anything using OS X 10.6 on an iMac. The points come out looking like garbage. This happens both on Minefield and Chrome while Webkit refuses to render anything. Interestingly, on the same machine running Windows everything looks good. And I have no problems on my MacBook Pro running 10.5… We certainly have a long road ahead in terms PointStream being cross-browser.

Get Involved!

If you’d like to get involved in development, testing or if you simply want to suggest ideas, visit us in the #seneca channel in irc.mozilla.org. Or file some tickets on our Lighthouse page. If you wanna get your hands dirty and hack some code, fork our repository from Github.

• So, the big news is of course the release of the beta version of Firefox 4 (previously known as 3.7). Mozilla have been making a lot of noise about the inclusion of WebGL in this release (though you still need to switch it on with the about:config flag webgl.enabled_for_all_sites), so it looks likely that it’s going to be there in the final release.
• Some of the publicity for the new beta was at Mozilla Summit 2010; here’s a video of Vladimir Vukićević’s talk. Links to all of the demos he shows in it are on this page on his site; looks like there are some adaptations of Pl4n3 and Jacob Seidelin’s stuff there.
• One thing Vlad showed was a very cool WebGL platformer, which Paul Brunt has written to celebrate the release of GLGE 0.5
• I believe this was also shown at the Mozilla Summit: a demo with many contributors, far too many to list here: Flight of the Navigator. (Does anyone know of a link to a live version of this?)[UPDATE: a live version is on its way.]
• On to non-Mozilla-related news: some competition for WebGL? There are early indications that the next version of Flash will have support for 3D graphics.
• I really enjoyed this post by Brandon Jones: why the biggest threat to WebGL gaming is neither Microsoft nor JavaScript performance, but instead the very user interface style that makes browsers so useful.
• From Paul Rouget, a nice simple example that should help anyone who wants to use videos as textures in their WebGL scenes.
• I suspect you need to know more about the background than I do to know what’s going on here: RADIUS network traffic analysed, sent to the browser over WebSocket, and displayed in 3D using WebGL, by Takanao Endoh.
• Matthew Postill has created a C3DL-based system called SceneCreator which lets people create 3D browser-based scenes to share with others. Looks like fun!
• Evgeny Demidov has written a very attractive particle-based fire demo.
• I don’t know whether I’m more impressed by the (apparently) 1.8 million polygons in this demo, or the domain name ;-)
• From the WebGL dev list, a terrain generator.

2D:

• display 3d object using bounding boxes, walls, lights, and enclosures in a 2d scene
• create wall
• insert lights
• new scene(delete all)
• walls, wall corner, and lights can be selected
• delete selected
• move selected

3D:

• add item to scene from the side bar
• item selection (clicking an item highs it blue and is set as the selected item) *wall are not selectable
• once an item is selected a user can (using the button above the scene):
  • delete
  • rotate
  • move up/down
  • scale
  • copy
  • move to position of the mouse
• camera widget
• 5 independent cameras
• save/load using local storage

Google Warehouse:

• view the Google 3D Warehouse website inside the browser
• back and forward functionality

• Lots of good stuff from last week’s WebGL Camp: there are videos for all, and copies of the slides for most, of the presentations up on the website. Well worth looking at!
• One great bit of news that Paul Brunt mentioned in his presentation, and has since blogged about, is that he’s ported the jiglibflash physics library over to JavaScript so that you can use it in WebGL. He’s getting pretty impressive performance!
• There are some translations of the tutorials from this site into Polish over at w3center.pl, including a run though the troubleshooting stuff that recently landed in lesson 0.
• A case where the backstory is more perhaps interesting than the demo: a cloud of particles from Matthew Papakipos, a high-flying Google Chrome engineer who tweeted about having done this just before dropping the bombshell that he was moving to Facebook after being head of the Chrome OS project.
• An interesting tweet from Henri Sivonen: “Cool. Street View using WebGL. Degrades gracefully to a static cylindrical movable image when WebGL isn’t available.”
• Another Quakesque demo from Brandon Jones: a Quake 2 level in WebGL, along with an explanation of why doing such a thing is a terrible idea :-)
• This is an interesting application for WebGL — Diego Cantor’s doing medical imaging (YouTube video only, unfortunately).
• Here’s a very pretty WebGL Earth.
• From China, an attractive ripple effect demo.

I’ve polished up the content from the talk I gave at WebGL Camp last Friday (video of the Skype presentation of my talk here, all talks linked from here) and used it to create a WebGL FAQ! Thoughts, comments, corrections, whinges and whines all welcome in the comments — or just register and edit the Wiki.

Just finished my first-ever Skype-based presentation — very confusing talking to a live audience when they’re thousands of miles away! Here are the slides I showed; feedback on the suggested answers to the frequently asked questions in there — and, indeed, other stuff that should be in there — are of course very welcome.

I’ll put it all on the WebGL Cookbook wiki later so that everyone can edit it — hopefully Khronos will be willing to host it as a better FAQ later on.

Lots of news for today:

• Changes in the WebGL Working Group: Mozilla’s Arun Ranganathan, who was chairing the group, is stepping down, and Vladimir Vukićević is coming in as interim chair until 1.0 of the spec comes out.
• It was amusing that Apple’s demo of the new HTLM5 standard was branded Safari-only, and sad that it didn’t include WebGL. Google’s response, HTML5 Rocks, has neither problem (the San Angeles demo is on slide 25 of the “Interactive Presentation”).
• On the subject of animation, this is rather impressive: from the Biomotion Lab at Queen’s University in Canada, here’s a WebGL walker. I highly recommend you switch on the “Bones” toggle, and then play with the sliders — hours of fun to be had…
• Unsuprisingly, California continues to be a good place to be for WebGL meetups… SIGGRAPH 2010 will be in Los Angeles on 26-29 July, and Khronos will be holding a WebGL BOF session.
• CopperCube 1.4.1 has been released, and now supports animation
• The online WebGL 3D editor 3DTin now supports orthographic projections — maybe not as attractive as perspective views, but often much easier to work with when editing models.
• Dennis Ippel’s come up with another WebGL tutorial, this one covering getting started with GLGE.
• Another tutorial: 3dgames.pl, a Polish-language site covering 3D game development and WebGL in particular, has a promising tutorial on collision-detection, physics and reading the keyboard in WebGL games.
• A new project: Lively Goes 3D from Tampere University of Technology “aims for the development of a compelling 3D mashup environment”. It’s based on earlier work at the university and at Sun, and they have a simple WebGL-based version up and running.
• Andor Salga’s been busy, with release 0.1 of the XB PointStream tool he’s been working on to display high-quality point clouds in the browser (demos here, though be warned that they take a long time to load!), and also extending Processing.js to support transparent WebGL canvases (with, for example, HTML text underneath).
• This is an interesting proposal, I don’t know whether I think it’s a good idea or not: the guys behind Stack Overflow are asking for ideas for single-topic equivalents of the generic SO site, and Rahul Hamdapurkar has proposed that they create one for WebGL.
• DaveR53 commented on last week’s post about the N900 pointing out that the browser also supports HTML events when the phone’s orientation changes: someone’s now put together a video showing a cube that rotates when the phone does. There are some really interesting possibilities for web-based augmented reality here.
• Also on the N900, the X3DOM team blog that they’ve confirmed that their library works on the phone, including animation and sound.
• And in further X3DOM news, here’s an online X3DOM editor from Michael Zoellner.

The first WebGL Camp is happening at Stanford University, Palo Alto, California this Friday, and I’m pleased to say that I’ll be giving a short talk (via Skype, so people will be spared the sight of my face ;-) If you’re in the area then it really sounds worth going to; if you’re not, apparently everything will be streamed and also available to watch afterwards (on YouTube, I think).

Speakers that the organiser, Henrik Bennetsen, has announced so far include Vladimir Vukićević, the originator of Canvas3D and thus WebGL, Trevor Smith of Spaciblo, and Google’s Peterson Trethewey (on O3D and WebGL). The speakers he’s not announced yet are also very promising, so it looks like it’s going to be a great day!

[UPDATE] The full schedule has now been announced — it’s looking really good. Many thanks to Henrik for setting this up! I only wish I could be there in person.

I’m working with Mickael Medel at Seneca College’s CDOT (Center for Development of Open Technology) on XB PointStream, a JavaScript tool which will render high quality point clouds in the browser. If you have a WebGL-enabled browser, check out our 0.1 release!

0.1

For a 0.1 release, I think we have something fairly decent. I does mostly what it should–it renders a large amount of point cloud data on Minefield, Webkit and Chrome at a fast frame rate. The largest issue we have right now is compressing files, which Mickael is working on.

It took a while to get to 0.1 and I think we’re on the right track. Here’s how we did it:

Creating the Octree

The fundamental problem we face is that of rendering millions of points in the browser in real time. I knew one way we could speed up rendering is to spatially partition the point cloud and do frustum culling. I looked into a few different forms of spatial partitioning and found octrees could be an appropriate data structure. After doing a bit of research and reading, I felt I had an understanding of how to implement one and wrote one in a Processing sketch. As test data, I just generated a series of random points along the surface of a sphere and inserted them into the octree:

The theory was if I had it working on Processing, I could take the exact sketch and feed it into Processing.js. Using a WebGL-capable browser, I should see a similar result. Unfortunately, I did run into a bug, which took up an entire evening to track down. I got some help from the Processing.js community and by using a newer parser, I managed to make the octree and points render on Minefield using Processing.js. The main problem was it was very slow.

Parsing ASC Files

After I had a (mostly) working octree, I was interested to see it accept some real data. I used Arius3D‘s PointStream ImageSuite to convert a PSI file into something I could easily parse, an ASC file. This format presents the data in an easy human and computer readable format:

-8.088 -12.421 -14.033 64 32 16 -0.372 -0.247 -0.894
-8.088 -12.293 -14.033 64 40 24 -0.380 -0.153 -0.911
-8.088 -12.165 -14.033 56 40 24 -0.341 -0.012 -0.939

It was clear the order was positions, colors then normals. I wrote up a small XHR script to download the data, split on spaces, parsed the strings to numbers and inserted the values into the octree. I managed to make it render, but only at around 1 FPS.

Performance Explosion

The problem with Processing.js is there isn’t a way to create a shape once and render it from a cached buffer. Each frame, shapes need to be re-created in case they deform. The renderer then suffers a performance hit, but this has been filed on our lighthouse account. So I had to create a work-around and optimization to get things rendering at a decent frame rate.

A related problem is that Processing.js renders points by translating and drawing the data in a VBO which contains only one primitive. This works if rendering a particle system which only has a few hundred points, but not for dense point clouds. I knew by increasing the VBO to larger size, I could improve performance, but I had no idea how much of an increase I would see. I spent almost two days hacking apart pieces of Processing.js, fixing my octree, stitching pieces of JavaScript within my sketch and debugging until I had the point cloud rendered. I checked the frame rate and I was completely surprised at the performance gain. We were now rendering at ~50 FPS for 150,000 lit points. Depending on the depth of the octree, I see performance between 20 to 50 FPS. The more octants there are, the more culling can be done, but the performance does suffer. This is something we’ll need to work on.

Next Steps

I recently added some fixes so XB PointStream renders on Chrome and I’ll be implementing octant/frustum culling this week. I’ll also start to remove the Processing.js crutch so our library can begin to take shape.

Lots of new links since last time!

• This is a really cool idea — via the WebGL developer list, here’s a WebGL 3D model editor. Blender, watch out :-)
• Here’s a warning: as Chris Marrin says on the Public WebGL list, pretty much all WebGL content on the net right now (my own tutorials included) is invalid! Historically we’ve been able to get away with certain kinds of mistakes because the browsers haven’t been thoroughly validating our shader language; these mistakes could cause all kinds of problems when running on mobile devices in the future. Quite rightly, the browser developers will be tightening up the shader validation soon; an upcoming release of Minefield will make tight validation optional, which will give us all a chance to fix stuff. A little while after that, validation will be on by default.
• A very nice CubicVR demo, this time demonstrating bloom (where light from bright things “leaks” onto nearby dark areas).
• First steps for Andor Salga’s XB PointStream project: 150,000 surface “splats” with lighting, partitioned in an octree.
• From Brandon Jones, an animated character that you might find familiar…
• What looks like another cool demo from Pl4n3, this time based on GLGE — unfortunately my display driver crashed before displaying it :-(
• Another 3d-test interview, this time with Denny Koch of EnergizeGL.
• Using Processing.js, some jellyfish created with Bezier curves.
• Interesting: the first steps in a WebGL implementation for Node.js, a server-side JavaScript framework. As the author says, “[i]magine easily writing games or multimedia applications that run in the browser and on the desktop without changes.”

Last week, a firmware release made WebGL available by default in the built-in browser on the Nokia N900 smartphone. I’ve put together a video of some of the N900-compatible demos that I listed yesterday. Apologies for the terrible camerawork!

<object height="505" width="640"><param name="movie" value="http://www.youtube.com/v/KVOTK5f1VYk&amp;hl=en_US&amp;fs=1&amp;"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="505" src="http://www.youtube.com/v/KVOTK5f1VYk&amp;hl=en_US&amp;fs=1&amp;" type="application/x-shockwave-flash" width="640"></embed></object>

It’s worth saying again that, as far as I can tell, WebGL being live in the N900’s Gecko-based browser is not a statement from the Mozilla team that it’s ready for production applications — rather, it’s a choice on Nokia’s side to make an early-access development release of a technology available to all N900 users. Perhaps they feel that anyone who buys a Linux-based smartphone will be techie enough to be able to handle a bit of beta HTML5 goodness ;-)

[UPDATE] At Mr. doob’s suggestion, I tried IQ’s Shader Toy WebGL demo. It worked pretty well, although the Quaternion demo did cause a few responsiveness problems… here’s a video:

<object height="505" width="640"><param name="movie" value="http://www.youtube.com/v/ywZTDtQT9b8&amp;hl=en_US&amp;fs=1&amp;"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="505" src="http://www.youtube.com/v/ywZTDtQT9b8&amp;hl=en_US&amp;fs=1&amp;" type="application/x-shockwave-flash" width="640"></embed></object>

I’ve spent a while playing with WebGL on the Nokia N900 smartphone. It sounds like its inclusion in the 1.2 release of the phone’s firmware (which happened last week) was a surprise to the Mozilla team, which would explain why we’ve not seem any publicity… So, given that the developers don’t think it’s ready for prime time yet, and that the WebGL standard isn’t at 1.0 yet, and no-one’s been testing their demos on anything apart from desktop machines, it’s surprising that it works at all, and astonishing that it works as well as it does :-)

If you have an N900, here’s a random selection of demos that will work on it; I’ll put a video together for people who don’t but still want to see it… [UPDATE: video here]

• A spinning WebGL cube. (This includes a workaround for an odd bit of shader behaviour — interested parties might want to compare with this version without the workaround.)
• Vladimir Vukićević’s Spore creature viewer (took a long time to appear — perhaps 2 minutes — but worked fine when it did).
• Brandon Jones enhanced Spore viewer (took a while to come up, and for some reason it won’t respond to mouse drags [UPDATE with a link directly to the demo, mouse drags now work])
• Particle explosions
• Google’s shiny teapot demo
• Google’s San Angeles demo
• Google’s particle demo
• My first Mandelbrot demo
• Lesson 9: Merry Christmas
• Lesson 10.5: nano-doom with lighting
• Lesson 14: per-pixel teapot with specular highlights
• Lesson 16: render-to-texture
• Pl4n3’s single-file skeletal animation
• Ilmari Heikkinen’s whale (a few glitches when drawing this one).
• Pavlos Toukiloglou’s Copperlicht-based Match 3D game.
• Evgeny Demidov’s interference patterns.
• CopperLicht’s Quake demo (loads, but a bit hard to control because keypresses go to the URL bar…)
• Four dollar Plastic Laminator (albeit at 1fps…)
• [UPDATE from the comments below, here's Glubble from PlayWebGL.]

(That list is entirely based on what I happened to click on over the course of this evening. If you’ve got a WebGL demo that you’d like me to try out, leave a comment below with a direct link to the WebGL page and I’ll let you know if it works, and put it in the list if it does.)

• Big news: apparently, the most recent firmware update for the Nokia N900 mobile phone enables WebGL in its (WebKit Firefox-based) browser. I have an N900, and hope to have some first-hand news soon. [UPDATE: it works! More in a separate post later.] [UPDATE: here's my list of demos that work on the N900]
• Ilmari Heikkinen has released a stereoscopically-rendered whale.
• A demo from PlayWebGL: a GPU game of life, with attractive colours.
• Via Henrik Bennetsen, a presentation from the Google I/O conference on new HTML5 features, including a look inside the GWT Quake implementation.

• Via the forums: from Brandon Jones, a new ultra-optimised matrix JavaScript library, this one apparently the fastest yet! The benchmarks are certainly impressive.
• Registration is now open for the WebGL Camp on 25 June at Stanford University.
• A new WebGL library — this one focused less on pure 3D graphics, and more on using WebGL as a rendering engine for a user interface toolkit.
• I must have missed this the first time around: here’s an interesting post about the situation with anti-aliasing in Minefield and WebKit, from Andor Salga.
• Ilmari Heikkinen has put together some demos using his JavaScript tarball parser — looks useful.
• Some more cool demos from Evgeny Demidov, these ones based on splines. Here’s the Starship Enterprise, a shark, and a motorbike: more on his site.

The Khronos specification is detailed, organized and official. The WebGL Cheat Sheet by Nihilogic is a great quick reference tool. But sometimes I just want to query the WebGL context and get all the raw commands and symbols. This can be very useful and it’s easy:
var gl = document.createElement('canvas').getContext("experimental-webgl");
var symbols= "";
for(currSymbol in gl) {
  symbols += currSymbol + "\n";
}

symbols will then be filled with the commands and symbols available for your browser:
canvas
viewport
clearColor
clear
enable
blendFunc
...
This of course works for either Minefield, Webkit, but also Chrome. Yeah, CHROME, isn’t that sweetness?

Recently, the Firefox team updated their support for software rendering so that they use the standard Mesa library that’s distributed with most Linux variants.

As far as I understand it, Mesa can be compiled to have all of its OpenGL functions start with “gl”, which is the default (and follows the OpenGL specification), or with “mgl”, which is useful for applications that are linking not just with Mesa but also with another 3D API (see here).

Historically, Firefox’s software rendering used Mesa in its “mgl” mode. Vladimir Vukicevic kindly made an mgl compile of osmesa32.dll available on his website for people to download and use when they needed to try software rendering. This was great for Windows users, but made life harder for those on Linux; most Linux distros have easily-available Mesa packages, but these are generally built with “gl” function names.

The new version of Firefox uses “gl” function names, which makes life a lot easier for Linux users. But it seems to leave Windows users in a bit of a bind.

Unfortunately, there are no official pre-compiled Windows Mesa binaries that I can find. I’d be happy to build and host them myself, but I was wondering — does anyone know of a better way of distributing them? Or, indeed, have I completely misunderstood the problem?

[UPDATE] In the comments, Benoit (who is coding this stuff in Minfield) says that he’s adding code so that it will support both “gl” and “mgl” function names, which will be a great result for everyone. You can track the progress of the work here.

[UPDATED UDPATE] The plan is now to only support “gl” function names, but to make a compiled OSMesa32.dll easily available for Windows users. This sounds like a good plan too :-)

• An update to what I think was the first ever WebGL demo; Vladimir Vukićević’s original spore creature viewer had a note saying that it “only uses the diffuse texture map; it should really also render the bump map and specular texture”, so Brandon Jones has done the work and added both! (It only worked for me in Chromium when I checked it out just now, though.) [UPDATE It works for me in both Chrome and Minefield, though in the latter it does take a while to display.]
• Via the Public WebGL mailing list, an impressive benchmarking page from Thatcher Ulrich (currently Chromium or WebKit only). What’s interesting is that because most of WebGL’s overheads are on the browser side, if you have a large model with loads of triangles already uploaded to the graphics card, you can draw it just as quickly as a much simpler model — that is, there’s a per-frame overhead that dwarves the cost per-triangle. My (slow) desktop machine can do 59 fps with a 79,000 triangle model, which gives 47,000,000 triangles per second. But if I decrease the number of triangles to 1,800, the FPS doesn’t move — so it’s just 133,000 triangles/second. What do you see?
• And on that subject… One of the limits on the number of frames WebGL can draw per second are apparently caused by the way the 3D canvas is composited with the rest of the web page’s normal HTML content. The browser teams are hard at work on fixing the problem, though, and over on the Public WebGL list there’s been a very interesting technical discussion of what the situation is and what’s being done.
• From Pavlos Toukiloglou, a fun game using the Copperlicht engine: Match 3D, a kind of 3D noughts-and-crosses/tic-tac-toe.
• More experiments with audio from Dave Humphrey, including some links to some very cool WebGL/CubicVR visualisations from Charles Cliffe.
• On the subject of Charles and CubicVR, he’s updated his index page with a number of new demos; I think they’ve mostly been mentioned here before but still well worth a look.

A Chrome special today:

• Great news today — Chrome 5.0.375.55 is the new stable version for Linux, the Mac, and Windows, and it supports WebGL! This means that every Chrome user in the world who has OpenGL 2.1 drivers will soon be able to run WebGL content just by setting the appropriate command-line flags. My own experiments show that you still get the best results using both --enable-webgl and --no-sandbox — some pages, including my own lesson 16, still show problems if you don’t use the latter, or if you use --in-process-webgl instead. [UPDATE I should say that I'm not saying that you should use this in preference to a Chromium nightly — at least not yet! It's just cool that the WebGL support is out there on millions of desktops.] [UPDATED AGAIN I've checked with Ken Russell on the Chrome team, and he confirms that Chromium nightly builds are still what we should be using for WebGL development.]
• Once you’ve downloaded Chrome stable and configured it as above, here’s a new page to try with it: the English-language version of the Japanese Twitlife site I mentioned the other day.
• Sadly, it’s not all sweetness and light with Chrome. Andor Salga points out that the transpose parameter to uniformMatrix4fv doesn’t work; when you pass true, you get an INVALID_ENUM error. This oddity was also mentioned on the forums a while back, and we discovered something surprising — the OpenGL ES 2.0 spec, on which WebGL is based, explicitly says that transpose must be false! So Chrome’s quite right to complain about it, but it does make one wonder why the parameter is there in the first place… perhaps for future use?
• On a more cross-browser note, here’s something else from Andor — the results of some stress tests dealing with hundreds of thousands of points using Processing.js, across WebKit and Minefield.
• Finally, continuing the large scene theme, Charles Cliffe is continuing to test loading meshes into CubicVR, with an impressive a 34k-triangle cityscape.

Just so that you know that I’ve not given up on the lessons… I’m slowly but surely putting together the writeup for lesson 16. While working through it (and fixing messy code), I found a couple of things that needed to be changed in all of the previous lessons:

• As per Marco Di Benedetto’s suggestion, I’ve moved the code that calls gl.viewport from the initGL function to drawScene. As Marco says, this makes it a bit more explicit; it also had the benefit of making it necessary for me to make the width and the height of the canvas available in drawScene, which meant that I could use them explicitly in the call to the perspective function, so now we use a calculated aspect ration parameter value instead of a hard-wired 1.0. This means that you can resize the canvas in the HTML, and things won’t get stretched or squashed. A definite improvement.
• Roman pointed out in the comments that the glUtils.js file in the lessons has two copies of makeOrtho. This shouldn’t have been causing problems — the second one should just have overwritten the first — but apparently it was stopping stuff from displaying on his machine. I’ve removed it.

So that’s it for now.

• Some good news: Minefield can now use OSMesa for software rendering without needing it to be compiled with “mgl_” prefixes for the functions. Unfortunately that this means most of the instructions out there are wrong, including mine and those from Krzysztof Pasek that I linked to last week… I’ll correct mine shortly. The instructions on the Khronos website are, of course, definitive.
• This is cool: a Sparse Voxel Octree from Veljko Petrovic.
• From the Google IO conference, a report that a new Google Street Map API will support WebGL. Does anyone know any more?
• Using Charles Cliffe’s CubicVR, a nice model of a car, and another cool music visualisation, if you have the Audio Data API compiled in — here’s a YouTube video of it if you don’t.
• More nice stuff from Evgeny Demidov: the Earth, the Moon, Jupiter, Mars, a Lorenz strange attractor [WARNING! apparently this can crash Minefield on Snow Leopard], a Klein Bottle, and some very pretty interference patterns. Check out his WebGL page, and in particular the models section, for more. [Sadly not Chrome-compatible, apart from the Lorenz and interference examples]
• Lindsay Kay has another SceneJS release ready: 0.7.5, which brings a few API changes, some bug fixes, and downloadable examples.
• Via PlayWebGL, a Japanese virtual world that appears to be based around Twitter: can any Japanese readers out there tell us more about it?
• Not strictly WebGL, but this might be useful if you’re trying to download complex models with a bunch of separate files — images, meshes, and so on. Ilmari Heikkinen has created a JavaScript library to parse TAR archives.

I’m working on XB PointStream, a tool which will emulate Arius3D‘s PointStream. XB PointStream will use WebGL to render thousands of points efficiently in the browsers.

I was curious to see how many points Processing.js could churn out using WebGL. If fast enough, it could potentially be used as underlying rendering engine for XB PointStream. So I wrote a Processing sketch which rendered thousands of points, and I took some measurements. I didn’t have any point clouds at hand, so I just generated a few thousand points myself:

Once I recorded how long it took Minefield and Webkit, I started hacking in some optimizations in the Procesing.js library. I knew I could start with reducing the number of calls to uniformMatrix*. For example, in Processing.js, the perspective and view matrices are set every time a point is rendered, which is unnecessary. I moved these function calls out and ran the browsers through the tests again. I was pleased to see rendering time was cut roughly in half.

I then filed a bug on our lighthouse account to reduce the number of uniformMatrix*. We still have a way to go in performance, especially since these tests are static renders, don’t account for download time and don’t use real-time lighting.

No Chromium Tests Yet

It’s unfortunate that I couldn’t benchmark Chromium. I even took extra steps to get the tests to run by placing the Processing sketch within the HTML file so Chromium wouldn’t throw XHR errors. I also merged one of my Processing.js patches which does not transpose matrices in calls to uniformMatrix*, which the nightly has issues with. But even after doing this, Chromium surprisingly rendered extremely slowly. This was the exact opposite of what I expected since it always outperforms the other browsers. I could try to find the nightly which renders properly, but I don’t have time to sift through all those nightlies. If someone knows when WebGL was broken, let me know.

A few weeks ago I updated Chromium, but the update broke my 3D Processing.js sketches. I didn’t have the time to look into it, so I continued using Webkit and Minefield to run my tests. This week I had a chance to check out the problem, so I loaded the C3DL splash page to see if it would render. Interestingly it worked. I then tried Processing.js, but that was still broken. How was it that Chromium rendered C3DL and not Processing.js? I knew there must be some WebGL command somewhere in Processing.js which Chromium didn’t like. I poked around our library for a while but still couldn’t get anything to render. The only thing that seemed to work was changing the background color.

I then thought about checking for any errors WebGL was reporting. I stuck a few alerts in the library:
alert(ctx.getError());
I started seeing non-zero values. WebGL was reporting error 1280. I converted this to hex (0×500) and ran a search. It turns out the error was because of an INVALID_ENUM. I kept throwing in alerts until I could isolate which command was causing this error.

I eventually found it to be this line:
ctx.uniformMatrix4fv(varLocation, transpose, matrix);
I was passing in true as the second argument and figured that must be causing the problem. I changed it to false and WebGL stopped complaining. Great! Of course nothing rendered. So to work around this problem, I just had to transpose the matrices myself before passing them to WebGL. This didn’t change Minefield or Webkit, they still run fine and now so does Chromium.

In my last post I wrote about an application by Arius3D called Pointstream, which at its core renders millions of surface splats very efficiently.

I’m working with a few other researchers in the Seneca College CDOT lab. We are starting some work on creating a version of their viewer which works on Minefield, Webkit and Chromium using WebGL. I tentatively named the project XB PointStream in hopes that it will one day be totally cross-browser. If IE implements a subset of DirectX, it would fulfill this hope. That way all the major browsers would be able to render Arius3D scans without a plug-in.

We just started the project, so there isn’t much to show unfortunately. But here are some links we’ll be using:
Lighthouse account
Github repository
A temporary website

If anyone thinks of a better name, let us know soon!

The next thing we’ll need to do is flesh out some specifications.

• What formats to support (PSI, DAE, ..)
• Maximum wait time to render whole object
• Shader lighting (I believe Arius3D uses BRDF)
• User controls
• etc..

Some of these we can derive from the viewer, but we shouldn’t emulate it entirely. Arius3D wants us to create something generic so other developers facing the same issue would be able to use this tool as well. We will probably have another meeting to figure out some of these details. From there we can begin filing bugs in lighthouse and start hacking.