

Why you should use WebGL - mariuz
http://codeflow.org/entries/2013/feb/02/why-you-should-use-webgl/

======
PanMan
While the article is right WebGL isn't supported on iOS, supposedly it IS
supported in iAd ads on iOS, which are HTML5. So it is to be expected some
future version of iOS will expand this to webviews/Safari.

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.

~~~
magicalist
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>

------
hartror
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>

~~~
unconed
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...](https://github.com/unconed/NeverSeenTheSky/blob/master/js/fluid.js)

~~~
hartror
Exactly, you need to understand the trade offs, which I don't feel the article
touched on.

~~~
pyalot2
I did say that I won't talk about the gotchas in this article up front though
:)

It's already a wall of text, I think it's better to pick one topic and limit
its scope for one post.

------
socialist_coder
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 =)

------
starmole
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.

~~~
pyalot2
\- 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

------
shanester
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.

~~~
pyalot2
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.

------
clebio
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...

~~~
T-A
<http://www.tuxlom.com/> runs fine (60 FPS) on a mobile Core i5 with HD 4000.
:)

~~~
clebio
OS/version, browser/version? Doesn't work here, though if I reboot into
Windows 7 I'm sure it will.

~~~
T-A
Windows 8, Chrome

------
count_zero
Total lack of IE support is a bit...problematic.

~~~
purplelobster
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.

~~~
exodust
> "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.

------
james33
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.

~~~
magicalist
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.

------
prodigal_erik
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.

