Why you should use WebGL
codeflow.org
codeflow.org
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.
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.
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.
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.
There are many game types/genres which don't require collision detection or realtime AI.
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...
It's already a wall of text, I think it's better to pick one topic and limit its scope for one post.
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
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 =)
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.
- 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
I've heard rumors Unity 3D is thinking of a full blown WebGL exporter as well, no idea if real/soon/at-all.
[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...
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.
Niche / hardcore game developers can potentially ignore this but if you are going for mass market you really can't.
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.
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.
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.
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.
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.