Well, I've been on the fence for a while, but I'm fairly sure that I'm not going to build native code demos anymore. WebGL just enables far too much awesome stuff. This demo on its own was impressive, but the fact that people are able to design new parts of the demo is what sets it apart.
With WebGL, it becomes simple to build an online, collaborative demotool where group members can easily work together on building new productions. That's simply unprecedented and may lead to a rebirth of the demoscene.
Sadly, I also think it will commercialize it on a whole different level and take away the innocence. But ah, ch-ch-ch-changes -- not all bad.
Personally I haven't been involved in the demo-scene for some 15 years but every now and then I indulge myself in the latest releases at http://pouet.net and find myself having lost a whole evening. That said, from what I have seen, and if this was indeed cutting-edge, we still have quite a bit to go... But yeah, we are definitely getting there. Not sure whether to jump for joy, though. :)
It is a very cool demo and allows you to mess around and build you own shaders online. This was very impressive as the first demo of its kind I ever saw.
This is simply amazing. Admittedly, I downloaded the leaked album minutes before seeing this link, but after watching this 4 times in a row I now have the song stuck in my head and just pre-ordered the album on iTunes.
Oh yeah, and if you see a smiley face on the ground in the desert scene I made that :)
Nothing makes my MacBook sound more like an aircraft during takeoff than a WebGL/HTML5 experiment.
I like to think I have a decent computer (MacBook Pro Gen 5) but it couldn't handle this. I suspect my slow internet connection might be another possible reason.
I must admit, before the Steve Jobs Vs. Flash drama unfolded, I paid little attention to the performance of Flash. I know my system would kick up a bit when I visited a flash website but it wasn't terribly uncomfortable. I think myspace pages crippled my computer more than any single flash application ever could.
And the other day I saw a HN comment for another one of these HTML5 demos that it kept crashing someone's iOS Safari browser. Apparently Flash doesn't just suck because Adobe are useless, but because interaction and animation is a hard problem to solve.
That said, this was pretty cool. The 3D was a bit "Money for nothing", and my Chrome gave me 10 seconds of beachball each time it switched from 2D video to 3D, but it's still showing that the web is moving forward (to CD-ROMs from the 90's)
One thing I've noticed is when running a WebGL demo in Chrome on a Mac, if another window partially overlaps the WebGL animation it freezes up the entire system.
It's obviously still a work in progress, but I think it will be fantastic when all the kinks are worked out.
That could be because the demo doesn't use requestAnimationFrame. This javascript call will stop whatever function it's given when the canvas is out of view. Frankly I've only noticed major issue on Mac. I'm developing a WebGL app and my boss on a mac had the habit of moving to different tabs without closing my demo before the requestAnimationFrame was introduced. Lets just say he wasn't too happy ;p
I also remember when we all thought that HTML5 would bring interoperability... Instead of "Designed for IE" we now have "Designed for Chrome". Is Google really that much better than Microsoft, or does the internet just have goldfish-like memory.
Google updates their browser every 12 weeks, and they're making sure everyone upgrades. While IE9 is a nice upgrade, IE still lags behind the other modern browsers. Furthermore, to date they have no plans to support WebGL. Id gladly put Google in Microsoft's place.
Having said that, we should be converging on open standards.
it's important to remember that the W3C is dependent on working implementations for specs to become finalized recommendations. the fact that you can use the latest HTML5 and CSS3 features, even if their spec isn't finished yet, isn't some kind of nefarious plot to embrace, extend, etc., and vendor prefixes, as annoying as they are, just mean that we won't be burdened later if specs change before they are finished.
the webgl 1.0 spec has been finalized. even though this was built with some google employees and is featured on a chrome experiments page, it works just fine in my Firefox 4 and webkit nightly. I think we'll be ok.
It's more accurate to describe this as "Designed for everyone but IE". (IE is welcome to the party, but isn't interested yet.)
WebGL is new and there are a lot of issues being worked out right now, in the field, while we watch. As we move from getcontext("moz-webgl") to "experimental-webgl" to plain, old "webgl", these interop issues are slowly going away. In the mean time, lots of things are going to be broken along the way. Besides, if it all worked right out of the gate, that would mean they were not pushing far enough. ;)
We are very sorry, but “3 Dreams of Black” is an experiment and unfortunately does not currently function on every configuration. It appears that your computer's graphics card doesn't support WebGL technology. You can find more details for troubleshooting here and obtain a list of recommended graphics cards.
That's what I see on the latest build of Chrome, and in FF4, on my one year old laptop.
So now in addition to supporting a big pile of browsers, we're expected to support a big pile of video cards and hardware configurations too? Isn't this the reason we moved to web apps 15 years ago?
Interesting. I am using Chrome with --ignore-gpu-blacklist flag, and can run webgl apps on browser quite well (one such as Doobs' minecraft demo[1]). Yet, the site won't let me run it on Chrome.
Funny enough, on a Nvidia Quadro NVS 110M laptop I get the same thing in Chrome -- but it works in Firefox 4 (when it doesn't crash the whole browser).
J'utilise la dernière version de Chrome sur un Mac Pro et je ne peux pas voir ce machin parce que ma carte graphique n'est pas supportée.
Je me demande combien de gens sont en mesure de voir et d'interagir avec cette démo. Et quel pourcentage des utilisateurs du net ils représentent. Le message envoyé aux autres ressemble à « tu es un perdant, tu ne fais pas partie du groupe, tu ne mérite pas de voir notre travail ».
Je trouve que c'est pire que ce qu'on voyait dans les années 90.
We are sorry but you need to read french to understand this comment. Go take a course and come back here to experience our wisdom.
From an end user's perspective, this demo is a monstrosity (like pretty much all WebGL stuff I've ran across so far). I opened the link in a background tab, then my system started thrashing and Firefox got stuck. Restarted Firefox only to have it reload the tabs and freeze again. Had it running in the end and got to see the 3D butterflies flying around in a choppy music video.
It's quite CPU-intensive, but well worth watching if you can get it to work. I had to watch it in Chrome and bump my screen resolution down to 1024*768 to watch it smoothly. It was well worth it.
I don't think that having to bump your screen resolution to get a website/video working is anywhere close to reasonable. The point was to replace Flash for web multimedia because it was too resource intensive and unstable. What we see now is a half-supported proof of concept growing out of unrelated technologies.
This might be the beginning of something great, but WebGL still has miles to go before being viable mass consumption technology and it's important to recognize that.
How does the running performance of WebGL compare to what would be possible if it was a native app? Are there inherent limitations of implementing this in the context of the web that will keep it much slower or will continuing optimization and things like hardware accelerated canvas elements allow achieving near parity (>80%) in performance?
Well, the short answer is: hard to say. A lot of work is off-loaded on GPU's now days, and theoretically there should be no reason why talking to the video-card through a browser should be slower than talking to it through a portable executable (.exe). The reality of it is that there is far more sandboxing and verification that needs to be done since no one likes having their browser crashed out of the blue. As for performance of languages (JavaScript vs C or x86), naturally, you will always get more performance the closer to the iron you are but it's getting fairly blurred and compilers/interpreters are pretty damn smart these days.
I realize I'm not answering your question entirely, but what I read between the lines is you're wondering whether WebGL will be able to replace "native" applications, performance-wise in the future. The ball is in the air on that one, and it's about to be caught by Intel/AMD/nVidia. And I bet you they are already cuddling with the browser-developers (or at least rubbing their hands in glee).
I guess the quick and dirty test for the state of things right now is to simply check the CPU/GPU performance on this one and compare it with current top of the month here: http://pouet.net/prod.php?which=56871 (note that this is a 64KiB demo -- in comparison, the background picture of http://romealbum.com/ is three times bigger).
I think it much depends on how much work you're doing. If you're just viewing a static 3D model and doing some scaling or rotation, it's not so bad but if you're adding/removing/translating objects, it's going to be ass slow in JavaScript. One's best bet is probably to write your code procedurally and hope that V8 can compile it to machine code really well.
WebGL is really good and it's only going to get better as long as the creators of the browsers make enough money to subsidize the optimization.
It may be that Chrome/V8 need to start using LLVM.
> It may be that Chrome/V8 need to start using LLVM.
LLVM is far too heavy to be used in such a situation -- page load times would rise dramatically. Really, V8 just needs to start doing hot spot optimizations. Do a quick first pass like they're doing now, then incrementally optimize away the hot spots. If I had to take a guess, I'd say that'll be coming in the next year, in some form or another.
Ah yes, I forgot all about that. Guess it's not a prediction if it's already come true. Anyway, more focus will be put on such things, as we're about as far along as we can get with the initial fast compilation.
Once you get the data and the shaders over to the GPU, its going to draw at pretty much full speed. That said, penalties for running on the web include:
Even a well-written JS app on a great JIT is going to have trouble keeping up with an equivalently well-written native app that has access to SIMD, cache-aware memory layouts, prefetching and other native features. My CPU can do 200 million matrix x vector multiplies per second using SSE3. In Firefox4 JS it can do 20 million. Impressive, but not equivalent.
On Windows, you are probably running GL on top of a D3D translation layer. That adds overhead to an API that you sometimes want to call into 60,000+ times per second. The GLSL to HLSL shader translation step is a big pain during load times. I'm not sure how much of a run-time penalty it causes.
Web GLSL is somewhere between HLSL Shader Model 2 and 3 from 2003. The latest desktop GPUs run Shader Model 5 which has many sophisticated features and performance opportunities. However, many of those are a bit too sophisticated for casual 3D programmers. Hopefully WebOpenCL will come eventually and shrink that feature gap.
Don't get me wrong, I'm excited about WebGL, etc. But I've got a brand spanking new machine that churns through every task I've thrown at it... except WebGL demos. I'm running the latest Chrome and it's simply choppy as hell, despite the low polygon count.
Why are we bending over backwards to modernize a bunch of antiquated document technologies?
I quite like Javascript, but it is rapidly becoming byte code. If you considered "compilation target" to be a JS design goal, I'd consider Javascript to be an abject failure. Similarly, while I realize WebGL is in its infancy, any 3D rendering layer that, by design, cannot approach the performance of Direct3D for simply pushing polygons (not even talking about programmable pipelines) is also an abject failure.
I'm also running the latest Chrome on Linux, on a cheap laptop (although it does have 2 cores). I could run it with no problems and no visible system slowdown.
I guess it also depends on the software used, on drivers, etc ... the technology is very new and still a work in progress.
by design, cannot approach the performance of Direct3D
A bit laggy but amazing that it's even possible. Can't wait to see what this looks like in the future. I hope we'll see something like CS Source or a similar title ported over in the next couple of years.
Combining this and a Kinect tracking head movement for interaction would be interesting. Imagine something like that as the routine music video experience on your TV in the future.
stunning! can't stop re-playing it. such awesome use of technology to create beautify art. also pretty happy my system is handling it with no problems..
With WebGL, it becomes simple to build an online, collaborative demotool where group members can easily work together on building new productions. That's simply unprecedented and may lead to a rebirth of the demoscene.