- [UPDATE] WebGL has just officially become version 1.0 final, and announced that they’re working on WebGL.
- Excellent news for those with Android phones: it looks like Firefox 4.0b5 supports WebGL, certainly on the Google Nexus S (video by Andrew Mason). Sony Ericsson have also got it running in the default (WebKit-based) Android browser (h/t Mr.doob), so that will hopefully get rolled into a release soon!
- Opera fans can now see WebGL in their favourite browser! It works pretty well, too: the Opera 11 preview displays my tutorials just fine, but isn’t quite so happy with more complex content; only a couple of the pages in last week’s around the net post worked (specifically, the raymarching, the SceneJS teapot and half of the three.js demos). Still, all but one of the demos in the Khronos demo repository work, so all in all it’s a great result for a first public release. (Thanks to Theo Armour for beating me to press with this one
- The gl64k WebGL demo competition’s site is now a bit more attractive and detailed, with a submission form and useful information like the list of judges.
- Minority Report-style interfaces, here we come — Aleksandar Rodic created the gorgeous Chrysaora jellyfish demo, blogged about hooking up a Kinect to WebGL, and has now published a video of the combination of the two. Very impressive.
- Improvements to a real-world WebGL app: the ChemDoodle molecule-graphic system now supports protein ribbon models. An article explaining what that all means is here, and a demo is here. (Note — the demo’s a bit slow on Chrome,
perhaps because it’s anti-aliasing, which requires much more GPU workdue to what looks like a Chrome bug — more in this comment from Kevin Theisen.) Cool new demos from someone new, Robert Schild: “Voxelspace“, bump-mapping, and most excitingly a simple Apache helicopter flight simulator[UPDATE: I should have looked more closely, although Robert says they're WebGL, these demos are actually using the 2D canvas. Thanks to aa for spotting that and pointing it out in the comments.]- From AlteredQualia, video textures in three.js: very clever, even if it does make it a bit hard to watch the movie
- Another one from WhiteFlashWhiteHit: a disturbingly wobbly head.
- This made my brain hurt A sphere using particle sprites in three.js.
- Mikael Emtinger has added support for 3d sounds to three.js (move around the scene to hear two different tunes based on where you are). (h/t AlteredQualia)
- An interesting article on comparative benchmarking of graphics systems from Jeff Muizelaar at Mozilla, including a port of Microsoft’s Internet Explorer fishtank demo to WebGL.
- Another cool Perlin noise demo from John Davis.
- This might be useful, especially if all you want to is get a WebGL model onto a web page with minimal fuss.
- A lot of very cool content has now been uploaded to KataLabs’ OurBricks 3D model repository. If you’re at the Game Developers’ Conference and looking to chat about WebGL with someone, a good plan would be to visit them at the Khronos booth on Friday from 10am to 1pm.
- There’s a new version of glMatrix, adding new functions for linear interpolation of vectors and quaternions and for transposing 3×3 matrices (useful for the normal matrix), and making a few bugfixes. I’ve ported my tutorials over to it, as it made it easier to implement a bugfix suggested by Shy.
- Andor Salga is looking into adding OBJ file importing to Processing.js, and, to judge from the number of ducks on his demo page, has succeeded!
- A useful tip from Diego Cantor; how to draw just the vertices that make up your mesh. This can be useful for debugging.
- A Processing.js demo: triangulated anenomes.
- So, I guess it was always going to happen once WebGL hit the stable Chome build and it wasn’t just early adopters using it: lots of reports of crashes, summarised here on Download Squad.
- Musings about WebGL performance from Bruce Rogers at Facebook — the numbers of supported sprites seem a little low, though. Presumably they’re rendering thousands of separate objects rather than pushing up one mesh and letting the GPU do the work.
- Finally, a tutorial with some first steps in learning WebGL.
WebGL around the net, 3 March 2011
March 3rd, 2011
9 Comments
Hi Giles,
Thanks for the links. ChemDoodle slowness in Chrome is not caused by anti-aliasing. Both WebKit and FF4 work perfectly. There is actually a severe issue with Chrome, where WebGL performance degrades when multiple geometries are rendered. For now, our belief is that Chrome is not WebGL functional (also causes crashes on Mac when a computer returns from sleep with a WebGL application open).
Our recommendation is that users uninstall Google Chrome and instead use WebKit and FF4 to view WebGL demos. At least, until the Chrome team fixes their browser.
You can follow the bug report here: http://code.google.com/p/chromium/issues/detail?id=74526
Hi Kevin,
Thanks for the update, you’re quite right — I put that in a while back, before you’d told me that it wasn’t anti-aliasing. I’ve fixed the post.
Cheers,
Giles
Kevin: I really don’t want to teach you how to program, but if you care to do a little bit of profiling, you will find out that your program spends more than 50% of CPU time calling one single function: getUniformLocation. It’s amateurish to point fingers to others while you can easily fix the performance issue yourself, i.e. caching location value
Bo,
First, thank you for taking the time to look into my issue. I appreciate that and your suggestion.
Your solution does relieve the issue, but it does not cure it. Caching values improves performance greatly for parameters like color, but for the large number of atoms and bonds we render, the true bottleneck comes from setting the model view matrix (uniformMatrix4fv). For each atom there is 1 geometry and for each bond there are 2 (one color for each side). Each geometry requires its own unique model view matrix, and therefore caching is not possible. That being said, you may know some techniques I do not, and I would be more than glad to hear them.
The true issue comes down to browser performance. Surely, Chrome has an issue when WebKit and FF4 can render thousands of geometries smoothly (regardless of caching), while Chrome slows to a crawl. Please do not get me wrong, I am a huge fan of Google Chrome and recommend it over all browsers on Windows/Linux for our 2D components. The Chrome developer team is also incredibly talented and I am sure these performance issues will be fixed. I am more than happy to help discover these issues and push towards a solution.
I will append the bug report with this additional information.
Ok, maybe I was a bit harsh, sorry about that. I’ve come up with a good idea to solve your problem. Instead of update matrix for each individual atom, you give them Identity world matrix and a defined View-Projection matrix. Then you pass Atom position as Vertex Uniform and transform them in the Vertex Shader. I’ve done that to my asteroid rendering code and I can render up to 10000 asteroids and still get 60 FPS. Try it, you won’t be disappointed.
Demo’s from Robert Schild are canvas2d…
You’re quite right, they are — I should have checked more closely. Post updated appropriately. Perhaps he’s calling it WebGL because it’s 3D in the browser, not realising that there’s a specific technical meaning for the term.
“aa” is right – of course & “giles” too
– the demos are canvas2d at the moment – I’ll try to combine WebGL (coming soon, I hope) and 2D canvas – and real WebGL implementations – to find out differences in performance etc. – stay tuned! Sorry for the wrong wording – I’ll correct that on my website!
Thanks, Robert — they’re cool demos even if they’re not WebGL, looking forward to seeing hardware-accelerated versions