The kicker here is they've built a 3d workflow (i.e. OBJ and FBX support, and direct Blender export). This means that, unlike with almost any other option you don't start out needing to implement 3d import from scratch.

On the down-side they do not appear to have implemented 3d animation yet. Assuming we can go from animated FBX to Babylon fairly seamlessly, this starts to look pretty useful.

The next thing would be a halfway decent positional sound library.

PlayCanvas [disclaimer: I'm CTO] has a full 3D import pipeline from FBX, COLLADA and OBJ which supports skinned animation and all default materials.

Plus we have a level designer, physics engine, scripting API, hosted publishing, and a halfway decent positional sound library :-)

You can see importing models and animations in action here http://www.youtube.com/watch?v=qy_fRcV-3wk, or signup for yourself [http://playcanvas.com]

Three.js has OBJ support natively (I've written a extension to allow you to view them directily on your github[1]). COLLADA and glTF, which provide support for animations, are also supported[2].

Cannon.js is a promising physics engine[3].

Nonetheless, it is exciting to see Microsoft not only supporting WebGL, but also promiting open source libraries to ease development on the platform.

[1] https://github.com/danielribeiro/three-hub

[2] http://threejs.org/examples/webgl_loader_collada.html

[3] http://cannonjs.org/

I tend to be dismissive of OBJ support since it's so easy to do and doesn't get you terribly far, but yes that's nice.

Collada support is a lot more impressive, but FBX support -- even though FBX is proprietary -- is much more useful given the wider and broader support for FBX out there (even Blender can export to FBX).

Blender export supports objects animations

They don't support bones yet, so this is probably straight transforms. We need bones and skeletal deformations.

This is really awesome, and it seems like proper WebGL games are going to become a common reality soon.

Chrome handles these samples very well, except for one thing which I think would be a major distraction for games: there's a ~1/sec stutter, which I assume is a GC pause. Google touts their stop-the-world GC as being ultra efficient and accurate, and in many ways it is. But I'm not sure that STW is an appropriate approach for games.

The stutter has improved in recent updates, but it's still there. I wonder if they'll consider an alternative GC approach for situations involving continuous rendering.

It seems to be pretty heavy on object allocation, eg:

    BABYLON.Vector3.prototype.add = function (otherVector) {
      return new BABYLON.Vector3(this.x + otherVector.x, this.y + otherVector.y, this.z + otherVector.z);
    };

I do a lot of WebGL work and I'm constantly fretting about avoiding allocations. For instance, compare to gl-matrix's operator:

    vec3.add = function(out, a, b) {
      out[0] = a[0] + b[0];
      out[1] = a[1] + b[1];
      out[2] = a[2] + b[2];
      return out;
    };

A little more awkward, but you're only allocating the vector once and then modifying in place wherever possible. THREE.js takes as similar approach with THREE.Vector3.

Exactly - quote mrdoob: "We try really hard to not create or destroy objects at run time. We use pools and reuse objects as much as possible, or flags. We don't want to rely in the garbage collector." https://github.com/mrdoob/three.js/issues/2435#issuecomment-...

The next version (1.2) will remove the pressure on GC by using in place operator and by reusing more entities

Makes me wonder why this isn't built on top of three.js to begin with?

Three has well over 2 years of rock-solid improvements under its belt, from hardcore graphics programmers to boot.

Three is not a fully fledged game engine, it's "only" providing a reasonably easy to use, sane 3D graphics engine to run on, which raw WebGL is decidedly not.

So any JS "game engine" project would do well to build on three.js (to pick up their many performance and other improvements from the last 2-3 years and those that the community will keep producing over the years to come) and then on top of that provide actual, non-rendering related "game engine" features akin to Unity3D. Objects management, component system, triggers, events, usable input management abstractions, materials management, LOD systems, configurable shadowing/lighting setups (on top of the options provided by three+friends), pluggable post-fx shaders with a few out-of-box ones and easy custom shader integration etc etc etc.

The samples work fine is Firefox 22 too (30 to 60 FPS 1.8 GHz Core i5), without the pause you're describing.

There are pauses, even worse than in Chrome. Use MemChaser add-on to see GC activity in FF. In Firefox Nightly on the particle demo I have non-incremental 0.6-0.7s pauses every ~10s (not to mention stutter from incremental GC in between the big pauses). In Chrome on the same sample I just don't have any pauses longer than 0.1-0.2s (every ~2s).

Firefox has been working on an incremental GC

I believe that they have been using an incremental GC since version 16.

Correct. In profiles I typically observe incremental GC running in 1-5ms increments, which makes it easier for it to fit in between frames without causing visible stutter.

Firefox on a tf700 dies horribly at around 3 fps.

I wonder how webgl will perform on the predominant browser platform - mobile.

I've been pushing for browser vendors to partially mitigate this by scheduling garbage collections during vsync (since the game's requestAnimationFrame code isn't running at that period in time). Unfortunately at present I'm not aware of anyone doing it.

For reference, at 60hz you have roughly 16.6ms to produce a frame and then do whatever you like before it's time to present it. So if the actual game code runs in a few milliseconds (not unreasonable for low to mid tier 3d games, even in the browser), you can do some incremental GC for 5-10ms and not be at risk of missing vsync. It's even better if you do the actual wait-for-vsync in a dedicated thread while you GC; then you won't ever miss vsync, and the vast majority of GC pauses are entirely hidden from the user.

Babylon.js seems to have evolved from Babylon Toolkit, a 3D framework for Silverlight 5:

http://babylontoolkit.codeplex.com/

Link to the website of the project: http://www.babylonjs.com/

You can see demos directly there.

Looks like the goals that inspired the quirky, far too limited VRML standard (http://en.wikipedia.org/wiki/VRML) have finally been realized.

Please note that we've also worked on a companion framework named GameFX: http://blogs.msdn.com/b/davrous/archive/2013/07/23/introduci...

As Babylon.JS, it's open source, mostly done on our free time and works well on every platforms supporting WebGL such as Chrome, Firefox, Opera, Android, Firefox OS and of course IE11 (win 8.1/RT).

This is a 3D renderer like three.js. Does anyone know how they compare?

As far as I can tell they copied the major features and concept of Three.js, added a few extra features, but implemented it in such a way that it is only performant in a specific version of Internet Explorer. In other words, embrace, extend, extinguish.

I don't understand why people keep falling for this crap. Microsoft will do the best that it possibly can to disrupt WebGL with compatibility and other issues, just as it has always done with every key aspect of web technology. This li brary is the latest example. They could have easily made improvements to Three.js or some other existing library that was tested on other browsers but they did not. There are too many billions of dollars on the line. 3d gaming in the browser means the end of the Windows PC monopoly and Microsoft knows that whether the rest of you do or not. No I'm not exaggerating.

I think competition is good. Soon after babilon.js got released I took a look at their file format and did a loader for three.js. This made me see how much three.js needed some geometry structure refactoring (moving towards a bunch of flat typearrays). I'm slowly working on that but I still need to find a nice API for it [1].

[1] https://github.com/mrdoob/three.js/issues/3672

*babylon.js

> it is only performant in a specific version of Internet Explorer

Where does it say this? Demos work fine in Chrome for me, at least.

Yes, it works great on Chrome.

Regarding the missing collisions: ThreeJS focuses on the 3D part of a game engine only. If you want collisions, you need to add a physic engine.

There's a couple of them out there - I would recommend CannonJS and there is a working ThreeJS FPS with WASD and collisions here: https://web3dblog.wordpress.com/2013/01/07/source-code-of-th...

Its on GitHub https://github.com/BabylonJS/Babylon.js

Babylon.js is based on the Babylon Toolkit for Silverlight, and includes significantly more features than Tree.js (not just a few), including sprite support and other 2d-graphics functionality.

BTW...Babylon.js works in all 3 of the major browsers, and performs best in Firefox, not IE10.

Would seem that at least particles, sprites, 2D layers, collisions, and dynamic textures are not in three.js. There's also mesh hierarchies, animations, and mirrors in Babylon.js, which I'm not sure if three.js supports those as first-class concepts or not.

Syntax seems pretty similar, which is not terribly surprising.

People wanted XNA 5, not yet another WebGL framework.

And tonight was the night where I was going to figure out how to use my Oculus Rift with WebGL.

This looks to have awesome potential. Well done!

Just in case you're still looking: https://github.com/benvanik/vr.js

Breathtaking! 120 FPS in all demos (because my video driver settings limit FPS to 120). Chrome, gtx680.

Version 1.2 is out :) [disclaimer: I'm the author^^] Major rework of the API to remove GC pressure New 3D charting demo

"Sorry but your browser does not support WebGL..." Wait. What?

Apple Mac OS X 10.7.5 Intel Chrome 28.0.1500.95

BAH. Apparently Chrome blacklists certain scenarios. Dumb.

Why's that so bad? A comment in this discussion (http://programmers.stackexchange.com/questions/17519/why-doe...) suggests that it is trivial to transform one system to the other.

It's actually not that bad but OpenGL (and thus WebGL) is a right-handed system by default (It supports whatever system you want though). And right-handedness is also kind of a standard, think about cross-product, Counter Clock Wise direction, etc...

Oculus Rift + Babylon.js = <3

I don't do game development at all, so please take my comment with a grain of salt.

How is this better than Flash/Flex/whatever Adobe has to play games? I mean waiting time is still there and I don't think Babylon.js works on all browsers the same (i.e. single code base for your game).

Second question: if I want to develop a game to be played on browsers AND mobile (iOS + Android) and I'm a single developer, isn't Adobe my best bet?

Well if you're a solo developer targeting browsers and mobile, I'd use Unity 3D (which went from supporting to abandoning Flash recently). It gets you browsers, desktop platforms, iOS, Android, Windows Mobile, PS3, XBox 360, and Wii -- not sure about the new Wii platform (does anyone care?).

The long term looks better on WebGL. And it's safer to bet your business on an open platform.

Adobe actually announced that they would be charging royalties on 3d games developed with flash. They backed off after developers pushed back, but it really shows the danger of using an Adobe owned platform.

Well, flash support on mobile is somewhere close to non existent and last time I checked the various flash 3D libraries (Away3d etc) the performance left something to be desired.

Yes, but you can export iOS and Android apps with Flash. The iOS browser still does not have support for WebGL.

Flash is dead. Adobe proved they weren't serious about flash when they announced licensing restrictions, 9% "revenue sharing" and hoops you have to jump through in order to use the "premium" 3d stuff. They eventually changed their mind about the 9% revenue tax after developers revolted, but the damage was done now that everyone knows they'd even think of doing something like that. And they drove the nail in the coffin (which Steve Jobs supplied), when they gave up on Flash for mobile.

http://www.forbes.com/sites/ericsavitz/2011/11/09/adobe-to-s...

"Flash Player 11.1 is the last release of the Flash Player plug-in for mobile browsers. Adobe will not add support for new mobile device configurations (chipset, browser, OS version, etc.). Adobe will continue to provide critical bug fixes and security updates for existing device configurations through September 2013, and will also allow our source-code licensees to continue working on and releasing their own implementations." http://www.adobe.com/devnet/flashplatform/whitepapers/roadma...

There is no future for Flash. Adobe's all about HTML5 now, they don't give a shit about Flash any more, and neither should you.

Unity3D went to great efforts to support Flash, and now they're sunsetting it, for good reason:

Unity wrote on their blog: http://blogs.unity3d.com/2013/04/23/sunsetting-flash/

We don’t see Adobe being firmly committed to the future development of Flash. This is evidenced by the cancellation of Flash Player Next, the instability of recent Flash Player versions and by Adobe’s workforce moving on to work on other projects.

By introducing, and then abandoning, a revenue sharing model, Adobe eroded developers’ (and our) trust in Flash as a dependable, continuously improving platform.

Developers are moving away from Flash, and while Flash publishing has gotten little traction, our own Unity Web Player has seen unprecedented growth in recent months (now installed on over 200M computers and already installed by 1/3 of all Facebook gamers).

1. Microsoft 2. Not open source

> Microsoft

I don't see anything that says that this is a Microsoft product. It looks like a side project by a Microsoft employee. (full disclosure: I work at MS.)

> Not open source

Looks like the source code is available at https://github.com/BabylonJS/Babylon.js under the "Microsoft Public License" which has been certified by the Open Source Initiative as an open source license.

This is just another technology connected with Microsoft that we should lament - right along with C#, Mono, Knockout, and TypeScript. Microsoft earned the ire of geeks everywhere in the 90s and it's a grudge many can't let go. Meanwhile you let Apple and Google steamroll you all by showing you what a real closed ecosystem monopoly really looks like. And you swallow it down because they do it all under the banner of 'open source.'

This makes absolutely no sense. Apple (iOS, OS X as examples) generally is a very closed ecosystem, though not a monopoly, and certainly don't operate under the banner of 'open source'. Google (Android, Chrome as examples) is a pretty open ecosystem, also not a monopoly, and actually is open source, no idea what "banner of 'open source'" means but they just are open source.

On the flip side, there's no reason to hate everything Microsoft do, c# and Mono are great. Maybe people should get over dismissing anything open source that Microsoft do, but the rest of what you've said makes no sense.

> On the flip side, there's no reason to hate everything Microsoft do, c# and Mono are great.

Microsoft didn't do Mono, it did .NET which Mono cloned in a form supported on a wider variety of platforms.

Mono is pretty much ostracized from the open source community along with many open source C# projects. Remember the whole ordeal about including Mono in Ubuntu?

Fair enough, I've never looked into it and he gave it as an example of a Microsoft project.

I've invested in a number of MS technologies only to have them discontinued or changed in a way that broke my code. This has happened a number of times. On the other hand, my OpenGL, C and Java code still all works.

There's a lot of reason to not use MS technologies even if you do like MS.

Don't really have a problem with Microsoft releasing open source libraries showcasing their support for open source technology. Yes, it's late for MS to be coming to Jesus er Stallman, but that's what you do when you're playing catchup.

"real closed ecosystem monopoly" you mean closed like Android, Chrome, Go, etc. etc.?

And you swallow it down because they do it all under the banner of 'open source.'

It is not under the banner of 'open source'. It IS open source (just ask Amazon, for example).

Uhg, the point is these are all multi-billion dollar businesses that use open source in one way or another. The problem is the open source (hacker news) community pretty much auto-ignores/dislikes anything connected with Microsoft. It's juvenile.

It's not juvenile - as a matter of fact, I'm very wary of Microsoft's moves because I remember perfectly well just how greedy and shady Microsoft has been (especially during the nineties). In comparison, Google has been a much better citizen in the developers community. It too will succumb to the problems of gigantism and the pressure of "shareholder value" in the long run, but for now you really can't compare the credibility of Google's and Microsoft's open source programs.

It's getting better: http://www.businessinsider.com/microsoft-and-xamarin-getting...

> especially during the nineties

That was 20 years ago!

That's exactly why I said it wasn't "juvenile" ;)

It is open sourced under Microsoft Public License: https://github.com/BabylonJS/Babylon.js

According to the Free Software Foundation, it is a free software license but not compatible with the GNU GPL.

Yes you're right about that, although this is only mentioned in the blog post, not the website. I'm also guessing this is open source the same way say Google open sources Android or Apple open sources Darwin.

> but not compatible with the GNU GPL.

That doesn't mean much, the GPL (v3) is incompatible with itself (v2). Not a GPL hater, just pointing out that it's not a big deal for licenses to be incompatible with the GPL.