Future of Babylon.js vs Big Frameworks

[jodo]

I recently did some research on how the "big players" like unity, unreal engine or cryengine are planing to handle webGL. While I wasnt able to find any information regarding unreal engine or cryengine going down the "webgl-path" I found some articels about unity. As you might know, the unity web player is pretty much deprecated. I think it doesnt run in lastest chrome, firefox and ms edge versions.

But in this articel: http://blogs.unity3d.com/2015/10/08/unity-web-player-roadmap/ on the unity site, they talk about that it will be possible to port unity games to webGL when version 5.4 is released this March.

The question is, should this work in a suitable way with unity, can frameworks like babylon.js survive? Dont get me wrong, I love working with babylon.js and it is an awesome framework with a super nice community. I would just like to know everybodys thoughts on this topic.

 

[chg]

7 minutes ago, jodo said:

The question is, should this work in a suitable way with unity, can frameworks like babylon.js survive? Dont get me wrong, I love working with babylon.js and it is an awesome framework with a super nice community. I would just like to know everybodys thoughts on this topic.

Isn't it a bit premature to take Unity WebGL seriously? They've failed to deliver on this for a few years now... (EDIT: thinking about this, I guess it is inevitable that they will get something useable working eventually, but then as a dev that's good for us right - more choice)

[jodo]

@chg sorry to not know that. I have only very little experience with unity and no at all when it comes to unity and webGL or the unity web player. But well, thats probably why i am premature on this topic : D

[Temechon]

In my opinion, Unity WebGL engine is too important to be used online. I had a client asking me to port one of their solutions from Unity WebGL to Babylon.js because the whole application was ~80Mo... Reduced to ~5Mo using Babylon.js.

[JCPalmer]

I think is time to start putting version #'s on references to WebGL.  WebGL 1.0 is a stripped down OpenGL 2.0 c.a. 2007.  Unless Unity were morons, they are probably OpenGL 3 or 4.  This might have a lot to do with them trying to move their code base to WebGL 1.0.

WebGL 2.0 looks close to done.  I check the spec page at least weekly.  Hardware, Apple at least, is already OpenGL 3.0 ES ready back to A7 processors. Once this is final, we should not wait for anyone to catch us.

We would do well to publish 2.3 when WebGL 2.0 goes final, then create a branch in the repository called "WebGL 1.0".  Use that branch only to fix bugs.  It will take a while for Browsers / apps like CocoonJS to start publishing production versions using WebGL 2.0.  That's ok.  I think we could redo a lot to change our vertex shaders to avoid uniform limits, using buffers, while we wait.  No more need to cpu skin do to too many bones.  Kill that.  There is probably a lot more that can be done.  Fuck 2007!

[Dad72]

WebGL 2.0 is already out since early January 2016 (If I understand well)

https://www.khronos.org/registry/webgl/specs/latest/2.0/

Babylon val be wear for WebGL 2.0?

[chg]

11 minutes ago, JCPalmer said:

WebGL 1.0 is a stripped down OpenGL 2.0 c.a. 2007.  Unless Unity were morons, they are probably OpenGL 3 or 4.

WebGL is moreorless OpenGL ES 2.0, yes that stripped a lot of junk out compared with OpenGL 2.0; but that same junk was stripped out of from OpenGL 3 & 4... there's a difference between "stripped out" and "stripped down" - don't mourn the legacy fixed function pipeline (which is the bulk of what was removed)

[JCPalmer]

@chg the stripped down part was not my point.  I could have just left it out.  Yeah, the stripped out part was mostly a turkey dump.  You cannot also use ES to fake it into doing GPGPU.

My point was, there is a lot of "new", post 2007, stuff in 3.0 that can be used to remove limitation we currently live under.

[Dal]

Unreal Engine 4 does compile to WebGL and works well. Unity can build for WebGL as well. They're both awesome engines.
The thing is, both are massive... even when they try to reduce the size for the web and mobile they have quite big footprints and, importantly, they need to turn off or change certain features that are used in the native builds, which means you have to worry about platform differences a lot more. If you just code directly for WebGL, the chances are the exact same code with run everywhere. Plus of course, neither are fully free in the way that Babylon is.

Where I think Babylon and other javascript engines really shine though is that they're completely dynamic. It's possible to make live code changes and see the results immediately on the screen or share online without any need for the slow compiling and packaging processes of most desktop engines. We can edit and run code directly on the browser and even on platforms that other engines can't reach. That makes it possible to do some really cool things and work very quickly and collaborate easily with others.

I certainly agree with @JCPalmer that it would be best to focus on the latest GL features we can. It makes little sense to be held back by limitations in the early standards when we're trying to make modern and awesome games. The natural choice for people that want to make a basic 3d scene that works everywhere is to use Three.js with its software fallbacks. Babylon can go all out for maximum eye candy  

[jahow]

Hey @jodo,

I think your question is interesting. Unity is already a very heavy engine and their apps ported to WebGL have all the reasons to be even heavier and bulkier. I think this is almost inevitable when you're "compiling" to javascript from an engine that is not engineered around web apps in the first place. Unity has a core software written in C++ and a system of scripting on top of it, with a serialization system that bridges the two. Try to imagine what it would take to transpose this system in JS... Either a complete rewrite of the C++ engine, or an awkward additional JS layer on top of all this, I really can't tell and feel bad for all the coders that have to work on this mess.

BabylonJS is written in javascript and designed for this language, so it will always beat a "compiled to JS" engine in terms of performance and ease-of-use. It's also a remarkably easy to use WebGL framework, so it should do fine for some more time.

On the other hand, I think that web browsers will become more and more attractive for game developers. I mean, they probably already are, but the tools are lacking. There are 3D frameworks but they're only doing a part of the job (render, audio, input... admittedly a lot but still) and they're not actual tools, unlike the ones you name in your post. Also, JS is a language that is (I think) not very well known by game developers because not yet used widely in the industry, and also not very fit to be used in large, organized project. Typescript does a better job at this but still, coming from strongly typed, low level languages (i.e. c++) is not easy.

Now, think of what gaming in web browsers opens up in terms of possibilities. You're not just running a piece of software that runs on its own or exchanges data with other clients or a server. You're basically opening a window to a virtual universe that is hosted elsewhere. This window can be opened from pretty much everywhere. There is nothing to download, nothing to install, nothing to patch. The whole concept of "software" is pretty much gone. You're only left with the data going back and forth between you and the server. I think that this is amazing in its own right.

So, in my opinion, the field is currently clear for new sets of tools dedicated to in-browser gaming. There are already some in development (for example this one that I like a lot: http://superpowers-html5.com/index.en.html), so time will tell who really takes advantage of the new possibilities. I think this is a pretty exciting time

That was my 2 cents, use it or throw it

[Dal]

1 hour ago, jahow said:

BabylonJS is written in javascript and designed for this language, so it will always beat a "compiled to JS" engine in terms of performance and ease-of-use. It's also a remarkably easy to use WebGL framework, so it should do fine for some more time.

I'm not sure if that's completely true... C++ engines are able to compile to asm.js and will soon be able to take advantage of WebAssembly as well. That means they might in theory run faster in some cases. It remains to be seen if Babylon can make use of that stuff too. 

 

1 hour ago, jahow said:

So, in my opinion, the field is currently clear for new sets of tools dedicated to in-browser gaming. There are already some in development (for example this one that I like a lot: http://superpowers-html5.com/index.en.html), so time will tell who really takes advantage of the new possibilities. I think this is a pretty exciting time

I am starting to work on something similar myself using Babylon at the core

[jerome]

I didn't know superpowers what seems really good

Too bad it's powered by 3js rather than bjs

[davrous]

I've already partly answered to this question here: https://news.ycombinator.com/item?id=9335460

"...First of all, babylon.js for instance, has been made specifically for the web. It's been tested on all browsers & on as much mobile devices as possible. Our shaders architecture has been made for that: to run on as much platforms as possible, mobile included. We're also spending a lot of time optimizing the performance for the web browsers and we're taking into account some of its specifics: offline via IDB, support for multi-touches (Touch & Pointer Events), streaming of assets, GC friendly, etc.

We have plenty of tools to help you testing the behavior of our engine and your code in the targeted env, the web: the sandbox tool, the debug layer, emitting user marks for F12 tools. We even have something we’re very proud of, our playground: http://www.babylonjs-playground.com/. Test & debug your code directly in the browser. Learn by experimenting in the target platform.

Moreover, babylon.js is free & open-source. You can debug your game and our engine directly in the browser. You can tune our engine to your needs if wanted as you have access to the source code, fork it and do whatever you want with it. You’ll also write the logic of your code in pure JS (or any great compiler like TypeScript or CofeeScript).

Babylon.js offers then a pure web experience. You can customize everything you want, handle the UI yourself with the ton of existing libraries, add some cool CSS features on top of it, mix it with SVG. Well, it is the web. Last but not least, we have almost finished our Unity exporter to Babylon.js that will dump all the graphics & sounds assets from the Unity scene to our .babylon format. It even seems much more efficient that the Unity 5 export.

Well, you see that this is a completely different philosophy. On the other hand, Unity 5 benefits from a huge community & assets. But creating a simple scene with a couple of meshes could take several minutes to export to WebGL and create up to 100MB of JS! And it's a very specific JS based on asm.js that can't be read by human nor modified. Plus it will only run correctly on Firefox (soon on Spartan too). At last, you will have to write the logic of your game in C#. But it’s a real great option for games developers that don’t master the beauty of the web. Unity is doing everything for them.

Conclusion: Unity 5 targets people with games already built for mobiles and will offer a very specific WebGL option. It's closed source. Babylon.js targets web games developers that build games specifically for this platform. It's free & open-source."

Moreover, I'd add that the WebGL export is currently based on asm.js which is only fully supported by Firefox and MS Edge. This means that targetting mobile is a no-go. In the future, they should use WebAssembly. WebAssembly can potentially used by Babylon.js in the future by adding some annotation to TypeScript for instance.

Talking about WebGL 2.0, yes this is in our roadmap for Babylon.js in a futur major release. But WebGL 2.0 support will be limited. Again, the main point of web technology is to target the most important number of platforms/users.

David

 

[gryff]

A nice synopsis David.

cheers, gryff

[JCPalmer]

On 1/20/2016 at 11:20 AM, Dad72 said:

WebGL 2.0 is already out since early January 2016 (If I understand well)

https://www.khronos.org/registry/webgl/specs/latest/2.0/

Babylon val be wear for WebGL 2.0?

@Dad72, The spec you reference is not final.  It is a working draft (see blue strip on left side).  There are not many editor's "to do" notes, so maybe the February print could be when they are finished.