Why you should use WebGL(codeflow.org)
codeflow.org
Why you should use WebGL
http://codeflow.org/entries/2013/feb/02/why-you-should-use-webgl/
9 comments
It's definitely supported in iAds, and you can enable WebGL in an iOS UIWebView via private APIs today (you just won't be able to release it). There's a few places with details, but here's an implementation you can grab off github: https://github.com/benvanik/WebGLBrowser
A grain of salt, cannot fault the article except it skimmed over a couple of areas. Keep these things in mind, especially if 3D graphics is something new for you:
Why you shouldn't use WebGL
* Performance: This is the big one. In 3D graphics and in particular games performance, both execution speed and memory usage, is everything. You can do some great stuff in WebGL but fitting lots of complex stuff (physics, AI, motion) in 1/60 of a second is hard enough when you can scratch around in ASM if you have to, let alone being constrained to javascript.
The Three.js demos are fantastic examples and a great learning tool. But they do feel to me like 90s demo scene[2] stuff. Working within strict limitations and using all the tricks of the trade to produce more than the sum of its parts.
* Libraries: the leading library Three.js is great and getting better and I enjoy using it. But I have a background in 3D graphics and know my way around 3D and OpenGL. Alternatives such as Unity hold your hand and have larger communities from which to draw help from if you don't know much about 3D.
[1] http://mrdoob.github.com/three.js/
[2] http://en.wikipedia.org/wiki/Demoscene
Why you shouldn't use WebGL
* Performance: This is the big one. In 3D graphics and in particular games performance, both execution speed and memory usage, is everything. You can do some great stuff in WebGL but fitting lots of complex stuff (physics, AI, motion) in 1/60 of a second is hard enough when you can scratch around in ASM if you have to, let alone being constrained to javascript.
The Three.js demos are fantastic examples and a great learning tool. But they do feel to me like 90s demo scene[2] stuff. Working within strict limitations and using all the tricks of the trade to produce more than the sum of its parts.
* Libraries: the leading library Three.js is great and getting better and I enjoy using it. But I have a background in 3D graphics and know my way around 3D and OpenGL. Alternatives such as Unity hold your hand and have larger communities from which to draw help from if you don't know much about 3D.
[1] http://mrdoob.github.com/three.js/
[2] http://en.wikipedia.org/wiki/Demoscene
A lot of people are underestimating what this stuff can be used for, IMO. It goes far beyond traditional games. I myself have been doing a lot of work with WebGL-driven articles [1]. With nothing more than nginx and Jekyll, I have an incredibly efficient pipeline to get 3D math lectures out to thousands with less than 20KB of JS per graph and 200KB of shared libraries. I can edit the content anytime I want and rsync an update. I got a 100k hits on that article last month, my little linode didn't break a sweat.
I've also been working on setting up GLSL based computational chains easily, allowing me to implement a fluid dynamics solver [2] with a dozen lines of JS and a hundred lines of GLSL [3].
It's not as demoscene-like as it seems, I don't have to work very hard to get it to run well, as JS is rarely the bottleneck.
Dedicated game engines will always be the realm of optimized native code, but there is an entire field outside that of rich 3D content. Between GLSL, Web Workers and fast JITs, there is a lot that can be done here. With JS, you not only get a platform you can deploy easily, but you get live access to a fully introspective VM at the same time. I expose all my JS to the console, and do most of my prototyping in there. All for free.
It's also the only platform that has a chance to be available universally, from pockets to desks to living rooms. I know I'd much rather restrict myself to techniques that are a couple years old, if it means it actually runs well on modest hardware—which a lot of demoscene stuff does not do.
[1] http://acko.net/blog/how-to-fold-a-julia-fractal
[2] http://acko.net/files/never-seen-the-sky/git/
[3] https://github.com/unconed/NeverSeenTheSky/blob/master/js/fl...
I've also been working on setting up GLSL based computational chains easily, allowing me to implement a fluid dynamics solver [2] with a dozen lines of JS and a hundred lines of GLSL [3].
It's not as demoscene-like as it seems, I don't have to work very hard to get it to run well, as JS is rarely the bottleneck.
Dedicated game engines will always be the realm of optimized native code, but there is an entire field outside that of rich 3D content. Between GLSL, Web Workers and fast JITs, there is a lot that can be done here. With JS, you not only get a platform you can deploy easily, but you get live access to a fully introspective VM at the same time. I expose all my JS to the console, and do most of my prototyping in there. All for free.
It's also the only platform that has a chance to be available universally, from pockets to desks to living rooms. I know I'd much rather restrict myself to techniques that are a couple years old, if it means it actually runs well on modest hardware—which a lot of demoscene stuff does not do.
[1] http://acko.net/blog/how-to-fold-a-julia-fractal
[2] http://acko.net/files/never-seen-the-sky/git/
[3] https://github.com/unconed/NeverSeenTheSky/blob/master/js/fl...
Performance: How fast is fast enough? We may not be able to make Battlefield 3 run in a browser yet, but there is a whole host of games that are possible, and are still a step-change in graphics compared to the 2D flash games.
We've got demos that are full rigid body simulations[1], 3rd-person shooters[2], fun little arcade games[3] and more[4]
Libraries: Three.js is great, but it's not a game engine. For games, the tool chain does exist though! At PlayCanvas[5] we've got a engine, visual editor, asset management, and publishing support. No WebGL knowledge required :-)
And because we're doing everything hosted in the browser, it gives us some cool bonuses, like real-time collaboration, cross-platform/device support, access from any browser.
[1] http://apps.playcanvas.com/will/ammo/vehicle
[2] http://apps.playcanvas.com/playcanvas/scifi/latest
[3] http://apps.playcanvas.com/playcanvas/apocalypse/latest
[4] http://playcanvas.com/demos
[5] http://playcanvas.com
We've got demos that are full rigid body simulations[1], 3rd-person shooters[2], fun little arcade games[3] and more[4]
Libraries: Three.js is great, but it's not a game engine. For games, the tool chain does exist though! At PlayCanvas[5] we've got a engine, visual editor, asset management, and publishing support. No WebGL knowledge required :-)
And because we're doing everything hosted in the browser, it gives us some cool bonuses, like real-time collaboration, cross-platform/device support, access from any browser.
[1] http://apps.playcanvas.com/will/ammo/vehicle
[2] http://apps.playcanvas.com/playcanvas/scifi/latest
[3] http://apps.playcanvas.com/playcanvas/apocalypse/latest
[4] http://playcanvas.com/demos
[5] http://playcanvas.com
Well you don't need a lot of CPU for doing AI and motion. In modern games, game logic like this usually takes not even 1% of the CPU time.
And more complex stuff than 90ies demo scene stuff is possible easily. There are lots of sophisticated 3d libraries to choose from, take a look at the demos of CopperLicht for example: http://www.ambiera.com/copperlicht/
But you are right: Physics is a major bottleneck. Fortunately, you don't need real rigid body physics engine in most games. In most situations, you can live with a small subset of it.
And more complex stuff than 90ies demo scene stuff is possible easily. There are lots of sophisticated 3d libraries to choose from, take a look at the demos of CopperLicht for example: http://www.ambiera.com/copperlicht/
But you are right: Physics is a major bottleneck. Fortunately, you don't need real rigid body physics engine in most games. In most situations, you can live with a small subset of it.
Well you don't need a lot of CPU for doing AI and motion.
Motion means collision detection and keeping the right data structures up to date. AI means things like path finding. Both sets of problems require lots of loops with lots of maths.
I've looked at Copperlicht and it is nice (looks like you work on it?), but still very limited when you compare it to the non-WebGL competition. The demos are all small largely static scenes that can be loaded onto the card and left untouched in memory.
I don't mean to say that WebGL isn't usable or that people shouldn't use it. I was providing a grain of salt to what was a very good write up.
btw. I like the doco for Copperlicht, nice and accessible and the octtree implementation impressed me when I was reviewing Copperlicht last weekend.
Motion means collision detection and keeping the right data structures up to date. AI means things like path finding. Both sets of problems require lots of loops with lots of maths.
I've looked at Copperlicht and it is nice (looks like you work on it?), but still very limited when you compare it to the non-WebGL competition. The demos are all small largely static scenes that can be loaded onto the card and left untouched in memory.
I don't mean to say that WebGL isn't usable or that people shouldn't use it. I was providing a grain of salt to what was a very good write up.
btw. I like the doco for Copperlicht, nice and accessible and the octtree implementation impressed me when I was reviewing Copperlicht last weekend.
Right now I think WebGL still does not make any sense to develop for. The best path for making money developing video games is either mobile, desktop, or Facebook. WebGL covers 2 of those bases but you lose mass market potential because of browser support and it's still ultimately not the best choice. For desktop you're better off just making PC / Mac apps and for Facebook/Web you really have to use Flash as it has far more browser support.
Personally I'm going with Unity and targeting mobile (iOS / Android). I don't really care about publishing to the web right now (Unity Flash doesn't work too well because the full feature set of C# .NET is not supported) but when Unity adds support for WebGL (which I'm sure they will) it might be a good option.
If I wanted to make hardcore games or games with higher graphical requirements I would publish to PC / Mac and not to the Web.
So, right now I don't see a compelling reason for publishing to the web or developing in WebGL.
edit- I'm speaking from a business perspective. If you just want to make cool stuff deployable to the web, then go for it =)
Personally I'm going with Unity and targeting mobile (iOS / Android). I don't really care about publishing to the web right now (Unity Flash doesn't work too well because the full feature set of C# .NET is not supported) but when Unity adds support for WebGL (which I'm sure they will) it might be a good option.
If I wanted to make hardcore games or games with higher graphical requirements I would publish to PC / Mac and not to the Web.
So, right now I don't see a compelling reason for publishing to the web or developing in WebGL.
edit- I'm speaking from a business perspective. If you just want to make cool stuff deployable to the web, then go for it =)
There are some big mistakes about Flash Stage3D which makes an article that pretends to be an informed overview very suspect.
Stage3D allows dynamic shaders even more than any other platform and does work very well on mobile via AIR.
WebGL as an API has serious problems that are not mentioned:
- High level language vs. bytecode at the API layer makes it very hard to implement consistently. The js API should take bytecode and a shader compiler (outermost loop) should be implemented in a safe script language via libraries.
- Very large API surface based on an 80s standard. This makes it much harder for browsers to support and test consistently.
- Extension mechanism makes it very hard to target consistently. A common problem in graphics is that every hw vendor wants you to optimize for the highest end in their line. Which gets you into the "make the best case better" optimization case when you really want to "make the worst case better".
- Serious interop/performance issues with js targets. Typed arrays are for example very important to a low level API like this.
- Low end support. Like Intel GPUs and mobile. WebGL is simply to big for testing and enforcing those constraints.
Sorry for ranting. :) Feel free to PM me for discussing 3D APIs for the web. I personally think the Flash Stage3D API is much better but I also realize the benefit of going plugin less.
WebGL as an API has serious problems that are not mentioned:
- High level language vs. bytecode at the API layer makes it very hard to implement consistently. The js API should take bytecode and a shader compiler (outermost loop) should be implemented in a safe script language via libraries.
- Very large API surface based on an 80s standard. This makes it much harder for browsers to support and test consistently.
- Extension mechanism makes it very hard to target consistently. A common problem in graphics is that every hw vendor wants you to optimize for the highest end in their line. Which gets you into the "make the best case better" optimization case when you really want to "make the worst case better".
- Serious interop/performance issues with js targets. Typed arrays are for example very important to a low level API like this.
- Low end support. Like Intel GPUs and mobile. WebGL is simply to big for testing and enforcing those constraints.
Sorry for ranting. :) Feel free to PM me for discussing 3D APIs for the web. I personally think the Flash Stage3D API is much better but I also realize the benefit of going plugin less.
- Please post documentation on flash being able to on-line compile.
- Both Direct3D and OpenGL (any variant) are moving away from requiring people to supply bytecode (or native code) to an on-line compile model of a high level language. Starting with Direct3D 10 you cannot supply your own bytecode anymore. Direct3D bytecode is cryptographically signed by the HLSL compiler of Microsoft and the DirectX runtime will refuse to run any shader bytecode that does not pass signature verification.
- WebGL is the smallest most concise of any 3D API around. Your claim of 80ties legacy is baseless. It is re-engineered from OpenGL ES 2.0 which cut away much legacy. WebGL threw out the entire remaining OpenGL ES 2.0 legacy profile. The entire API, all of it, fits on 2 PDF pages of a quick reference (compared to 4 for ES 2.0 and a dozen for full blown OpenGL). WebGL is extremely well tested with close to 10'000 tests in around 500 test suites that test everything from API consistency and behavior to actually verifying rendering results. It is not hard to test at all, evidenced by a superb conformance test suite and performance regression suite, unique among any 3D API in existence.
- The extension mechanism offers you the possibility to introduce alternative renderpaths. On any account, none of the extensions present are more than what Direct3D 9 already supports (but OpenGL ES 2.0 does not). Instead of checking the D3DDeviceCaps for capabilities, you check extensions, same thing really.
- Typed arrays have been introduced and are supported well by any vendor doing WebGL
- WebGL runs on mobiles because it is an implementation of OpenGL ES 2.0, which is supported by well over 90% of smartphones and tablets. Implementations of WebGL are offered from multiple vendors for android, and out of the box from Blackberry and Firefox OS
- Both Direct3D and OpenGL (any variant) are moving away from requiring people to supply bytecode (or native code) to an on-line compile model of a high level language. Starting with Direct3D 10 you cannot supply your own bytecode anymore. Direct3D bytecode is cryptographically signed by the HLSL compiler of Microsoft and the DirectX runtime will refuse to run any shader bytecode that does not pass signature verification.
- WebGL is the smallest most concise of any 3D API around. Your claim of 80ties legacy is baseless. It is re-engineered from OpenGL ES 2.0 which cut away much legacy. WebGL threw out the entire remaining OpenGL ES 2.0 legacy profile. The entire API, all of it, fits on 2 PDF pages of a quick reference (compared to 4 for ES 2.0 and a dozen for full blown OpenGL). WebGL is extremely well tested with close to 10'000 tests in around 500 test suites that test everything from API consistency and behavior to actually verifying rendering results. It is not hard to test at all, evidenced by a superb conformance test suite and performance regression suite, unique among any 3D API in existence.
- The extension mechanism offers you the possibility to introduce alternative renderpaths. On any account, none of the extensions present are more than what Direct3D 9 already supports (but OpenGL ES 2.0 does not). Instead of checking the D3DDeviceCaps for capabilities, you check extensions, same thing really.
- Typed arrays have been introduced and are supported well by any vendor doing WebGL
- WebGL runs on mobiles because it is an implementation of OpenGL ES 2.0, which is supported by well over 90% of smartphones and tablets. Implementations of WebGL are offered from multiple vendors for android, and out of the box from Blackberry and Firefox OS
If Unity projects could be exported to WebGL I would use it for some projects. Many programmers / designers (myself included) don't have the time or skill to code at such a low level for common functionality. I really enjoy the ease of use certain engines such as Unity3d and UDK bring to the table and it appears I am not the only one looking at all the 3D indie games being released using these tools.
Brandon Jones does a bit of Unity 3D exporting to WebGL, you should read up on his blog: http://blog.tojicode.com/
I've heard rumors Unity 3D is thinking of a full blown WebGL exporter as well, no idea if real/soon/at-all.
I've heard rumors Unity 3D is thinking of a full blown WebGL exporter as well, no idea if real/soon/at-all.
Am I missing something here? I've been trying to use WebGL for weeks now, based on [unconed's MathBox articles][uc]. For the life of me, I [cannot get this to work][my] on any laptop that uses the Intel HD 4000 graphics card (my samsung series 9) ... which includes nearly all the macbooks, no less. If that pretty common graphics card isn't supported, how can anyone develop WebGL libraries, let alone expect others to use them. Perhaps this will be patched in some (linux?) driver update in the future, but until then....
[uc]: http://news.ycombinator.com/item?id=5158989 [my]: http://news.ycombinator.com/item?id=5088918
EDIT: I clearly don't understand HN's subset of Markdown, either...
[uc]: http://news.ycombinator.com/item?id=5158989 [my]: http://news.ycombinator.com/item?id=5088918
EDIT: I clearly don't understand HN's subset of Markdown, either...
http://www.tuxlom.com/ runs fine (60 FPS) on a mobile Core i5 with HD 4000. :)
There was a bug ticket about that a while back: http://code.google.com/p/chromium/issues/detail?id=162634
If you still have the problem you should note down your GPU, driver/version and OS/version and comment on that ticket.
I will follow the progress of that ticket as of now.
If you still have the problem you should note down your GPU, driver/version and OS/version and comment on that ticket.
I will follow the progress of that ticket as of now.
Ok, I just updated that ticket. I had seen it, and tried the recommendations (latest chromium build), but have not yet had success. Thanks for any help!
Total lack of IE support is a bit...problematic.
I have no problem dropping IE support for app-like experiences. Honestly, people on IE are mostly at work or don't know much about technology and are less likely to play games. I don't see how asking the user to install another browser is bad compared to having to install steam or be limited to your flavor of mobile OS or console.
> "people on IE are mostly at work or don't know much about technology..."
IE9 is pretty solid in many ways. Runs javascript faster than Firefox. Jquery animated interface effects and so on run noticeably smoother and quicker in IE9. My main browser is Firefox and I like it, but I've noticed IE9's faster performance when testing.
IE9 is pretty solid in many ways. Runs javascript faster than Firefox. Jquery animated interface effects and so on run noticeably smoother and quicker in IE9. My main browser is Firefox and I like it, but I've noticed IE9's faster performance when testing.
... and people at work won't play online games?
You can run WebGL on InternetExplorer using IEWebGL: http://www.iewebgl.com/
IDK, if you want to run WebGL games you probably don't use IE anyway.
It is not an issue of users who want to run WebGL games, it is an issue of developers who want to target customers who run IE. In that sense, you are still virtually forced to use Flash if you want to hit the largest possible market.
Niche / hardcore game developers can potentially ignore this but if you are going for mass market you really can't.
Niche / hardcore game developers can potentially ignore this but if you are going for mass market you really can't.
Exactly, it goes beyond games.
As a web developer at a creative agency, it's impossible to pitch an interactive 3D simulation or data visualization project to a client if it won't work in IE. I'd be happy if even CSS 3D transforms were widely supported.
As a web developer at a creative agency, it's impossible to pitch an interactive 3D simulation or data visualization project to a client if it won't work in IE. I'd be happy if even CSS 3D transforms were widely supported.
Right, that is why Microsoft did not include.webgl support in IE, because then the web platform would.compete with their Windows PC gaming monopoly. To get around that people just need to another browser, which is what people obviously should do, unless they want to be.forced to buy Windows pcs for.the rest of their gaming lives.
No one really uses IE these days..
WebGL is great, but as a game developer that works with these technologies daily, it isn't ready for the mass market yet. The lack of mobile and IE support are deal-breakers for the short term. Give it a year or two and it'll be a whole different story.
It will be great when support expands, but I don't see how those are really deal-breakers. Are there even any equivalent platforms that would suggest mobile and IE support will be required before WebGL takes off? Meanwhile Firefox + Chrome is hundreds of millions of potential users.
Yes, people will get confused and annoyed about why a game doesn't work in their browser of choice, because they don't really know what a browser is, or the difference between a mobile browser and a desktop browser. But that's no different than my mother wondering why her flash games don't work on her ipad, and flash games are still a substantial (if not always stable) market.
The real problem holding back rapid progress, I think, is that lack of strong development tools, and that's (very slowly) being worked on.
Yes, people will get confused and annoyed about why a game doesn't work in their browser of choice, because they don't really know what a browser is, or the difference between a mobile browser and a desktop browser. But that's no different than my mother wondering why her flash games don't work on her ipad, and flash games are still a substantial (if not always stable) market.
The real problem holding back rapid progress, I think, is that lack of strong development tools, and that's (very slowly) being worked on.
WebGL is supported by Opera Mobile and Firefox for Android. The next version of the Backberry browser and Chrome for Android will support it, too.
It's very unlikely that IE will ever support WebGL, because Microsoft is against OpenGL in general. If you start with OpenGL, you probably won't bother with DirectX, which means you won't tie yourself to their ecosystem. That's obviously not in their interest.
Fortunately, IE has been constantly losing market share for the last 4 years.
It's very unlikely that IE will ever support WebGL, because Microsoft is against OpenGL in general. If you start with OpenGL, you probably won't bother with DirectX, which means you won't tie yourself to their ecosystem. That's obviously not in their interest.
Fortunately, IE has been constantly losing market share for the last 4 years.
Interesting. Could you expand a bit on this? Why is the lack IE and mobile support so much of a deal breaker?
I don't have much experience developing games, so i'm asking those questions mostly from curiosity. Aren't game developers used to choosing some platform while sacrificing other?
I mean, i always found it quite curious that on consoles for example it expected to find games that only work for one or two consoles, it is OK if some game runs on PS3 but doesn't run on PS1 & 2, not on XBox, nor on the Wii (nor on PCs, mobile phones, tablets, etc), thus "losing" a lot of market share; while on the web the expected behavior is that things should run on all possible browsers, and it's unacceptable to lose any substantial portion of the market share by not supporting some deficient browser.
I don't have much experience developing games, so i'm asking those questions mostly from curiosity. Aren't game developers used to choosing some platform while sacrificing other?
I mean, i always found it quite curious that on consoles for example it expected to find games that only work for one or two consoles, it is OK if some game runs on PS3 but doesn't run on PS1 & 2, not on XBox, nor on the Wii (nor on PCs, mobile phones, tablets, etc), thus "losing" a lot of market share; while on the web the expected behavior is that things should run on all possible browsers, and it's unacceptable to lose any substantial portion of the market share by not supporting some deficient browser.
Blindly trusting webgl is even more unwise than blindly trusting js, because most stacks are accelerated via passing third-party data to shoddy native code. If you're actually putting content on the world-wide web (not just a game that's useless without interactive behavior) js+webgl should never be the only rendering, but I fear that most authors don't care about this.
Also strange he says Unity has no support on mobile: While it's not supported in mobile browsers, creating mobile apps it one of its strengths, afaik.