Choose between Three.js and Babylon.js

[3Dlove]

Hello everybody,

 

I am in a dilemma : the choice between Three.js and Babylon.js for a project similar to that one : https://www.chromeexperiments.com/experiment/webgl-bookcase

a virtual bookstore but in a more realistic environment where you can move between the shelves, with similar animation when you click on a book and change pages.

 

Which library do you recommend ? What are your arguments ?

 

To the pleasure of reading you

[dave]

Have you considered PlayCanvas?

 

If you looking for realistic rendering, our new physically-based shading workflow will be super useful: http://blog.playcanvas.com/physically-based-rendering-comes-to-webgl/

 

Depending on how you are going to be creating the assets, but if you've got FBX/Collada/Obj files for the models you're going to be using. You'll be saving time as you can just drag and drop them into the tools, set up the materials and hit "play".

 

Engine-wise, they all have a similar feature set. It's going to come down to tools, support, which API you prefer. 

[MarianG]

I worked before with ThreeJs. it's a wonderfull framework, with strong documentation and examples, but it consume a lot of resources. I think it is ok for little projects.

If you want a big project,  Babylon.js is what you need, the most powerfull and free library. 

Or for unlimited experience, but very new on Webgl, you can try UnrealEngine, or Unity.

 

Have fun !!!

[Mikhail Luzyanin]

Hello everybody,

 

I am in a dilemma : the choice between Three.js and Babylon.js for a project similar to that one : https://www.chromeexperiments.com/experiment/webgl-bookcase

a virtual bookstore but in a more realistic environment where you can move between the shelves, with similar animation when you click on a book and change pages.

 

Which library do you recommend ? What are your arguments ?

 

To the pleasure of reading you

 

You can try https://www.blend4web.com/en/ . It's absolutely free and open source and can be easily integrated with the web page. The Blend4Web framework is closely integrated with Blender - the 3D modeling and animation tool. You can check http://www.zeusmedien.com/zeus3D/ it's complitely made with Blend4Web. You can find many tutorials that can help you to start your project using Blend4Web on our site or you can ask your questions on the forum. https://www.blend4web.com/en/forums/ . Also, check our demo scene page for the comparison with other WebGl engines rendering possibilities. https://www.blend4web.com/en/demo/

[lo.th]

for me three is the best solution 3 big reason for that 
1 _ is the lightweight library for web is perfect. (blender js code on html is unreadable)
2 _ this is the fastest and most comprehensive.
3 _ many many exemples and possibility (codding shader is the best option for your project )

you don't need unity or unreal for web is not usable (html5 code > 3 Gb both  )
 

ps: i'm not user of Babylon (just tested one time first version for my physics library, slow with many objects ).

[Blender man]

for me three is the best solution 3 big reason for that 

1 _ is the lightweight library for web is perfect. (blender js code on html is unreadable)

2 _ this is the fastest and most comprehensive.

3 _ many many exemples and possibility (codding shader is the best option for your project )

you don't need unity or unreal for web is not usable (html5 code > 3 Gb both  )

 

ps: i'm not user of Babylon (just tested one time first version for my physics library, slow with many objects ).

 

Blend4Web has a JSON export option (only scene data) alongside the HTML export option (scene data + web player).

 

The code is 870k (without addons), 910k (with addons). The app code can be optionally obfuscated to become unreadable.

 

Agreed about U&U though

[Sebi]

I don't know about babylon, but I know that threejs is a nightmare regarding garbage collection. Sure if you have a small project, heck, don't care what you use, jut be familiar with the framework. Only thing that matters is that you are able to easily change the code. Keep in mind, you are not writing a framework.

[mfdesigner]

I don't know about babylon, but I know that threejs is a nightmare regarding garbage collection. Sure if you have a small project, heck, don't care what you use, jut be familiar with the framework. Only thing that matters is that you are able to easily change the code. Keep in mind, you are not writing a framework.

 

Really? How easy is it for you to change the code of three.js or babylon.js?  

 

The more features they add to the code base, the harder it becomes for a third party to customize the code.

 

This is because the code is built from bottom-up and often in multiple hierarchical levels.  All the mid-level  intermediary objects were designed by a few individuals to be interdependent in a certain way.

 

That's why our platform (oTakhi Platform) opts to use a top-down approach.  A user can wrap any low level codes, even emscripten compiled c/c++ code,  into reusable components and extend the platform in arbitrary ways.  The interface providing service from the said component is designed by users not platform developers.

 

On other platforms, users can only relies on the APIs that the platforms provide for features.  Basically, a few developers playing gods controlling the design of mid and low level software objects.

[jerome]

Babylonjs takes care about garbage collection. It focuses on game/animation rendering.

[mfdesigner]

Garbage collection (GC) is precisely the reason why web apps should be built from top down.

 

The issue with GC is that Javascript Engine has no idea what applications are doing, since GC is implemented by Javascript Engines,

the best it can do is either periodic GC or upon process idle.  The problem arises when the amount of memory it needs releasing is 

huge and subsequently causes delay and thus frame drops.

 

The obvious solution is to let applications control the GC process, not by middlewares such as three.js or babylon.js, but by the end applications.

(For example, three.js or babylon.js doesn't know if an app is playing web audio and video, if they choose to do GC because no animations is playing, it will immediately lead to hiccups.)

 

Unfortunately, until all Javascript engines (IE, Chrome, Firefox, Safari) relinquish control of the GC process, it is still a pipe dream.

 

Generally speaking, Software design, at all level, should be driven by application requirements, not by a few developer imagining what applications need.  When a few developers choose to design software one way, they automatically exclude users who want to do it the other way.   Choosing to perform a particular step FIRST would automatically exclude users who want to do it LATER.  Every software design decision a developer made has potential of limiting general applicability of a framework or library.

 

Designing object oriented software from top down solves all these issues.  Instead of adapting to how a library works, users can make codes at any level to adapt to his/her workflow (by wrapping it into a reusable component).

[MasterSplinter]

Babylonjs takes care about garbage collection. It focuses on game/animation rendering.

mesh.dispose(); is sooo haard.

[Nikos123]

What about not using a framework to build a webGL game? Is it possible?

[PsychoD]

This is my first post, so first of all: Hi everyone!

 

The question in this topic is exactly mine currenly, though the application to be developed is not a game, but a CAD-like web tool, which needs to be rock solid and run stable. I really appreciate any experience reports or suggestions regarding those two frameworks. Currently, I have a slight preference to Babylon.js.

 

Best regards

psy

[mattstyles]

You'll have a rough set of requirements that you need out of a framework, and I'd also assume you're invested enough to knock up a few short demos to test that frameworks meet those requirements. 

 

For many small to medium projects it is likely that any mature framework will meet your requirements. One might be slightly quicker than the other in a certain respect, or you managed to knock up your demos marginally faster in one of the other, but, as they perform roughly comparably you probably dont care all that much. So how do you choose?

 

Given that a framework passes your basic requirement tests I'd approach it from a `developer ergonomics` standpoint (or the human standpoint):

 

* Is the framework well documented? Without it you're going to be wasting a lot of time working out how to do framework-dependent stuff. At a high level this is syntax but it also includes project structure yada yada yada. This includes how well written and documented the source is, in addition to the documentation.

 

* How mature is the framework and how much active development? Active development means at least someone still cares about the project (hopefully more than just a someone). How quickly do PR's get merged? How quickly do issues get responded to? If you're investing in this framework then I'd say its essential that maintainers still are. It would be ball-breaking to get 90% into a project and need help on a specific thing in the framework and have no means of contacting the framework developers/collaborators—at the end of your project you want to be polishing/hardening/optimising, not fighting with minor framework issues.

 

* How does the coding style match your own? There are different ways of structuring APIs, ideally you dont want to be learning new ways of writing code, you want to write it the way you write it, letting you focus on application logic over learning new/different methods. Ideally frameworks implement framework-dependent stuff as little as possible, if the framework is highly opinionated there is a learning cost, one that you'd ideally want to avoid (i.e. if the framework takes 6 months to learn then its gotta absolutely hit your brief bang on and let you knock up the actual app far faster because anyone who starts with a less-opinionated framework is 6 months ahead of you).

 

If your initial preference is Babylon and you're happy with the developers/documentation/community then I'd say go balls deep. I dare say you'll be able to finish this project (you've done pre-qualification that the framework can handle it right?) and if you end up hating Babylon by the end of it you'll know to try something else next time.

[mfdesigner]

Software frameworks require continuing maintenance because every time a new feature needs be added, it often necessitates changes to the low level objects and its interfaces.  Only a few original developers know how these low level objects were designed from day one and how they should be used to complete a task. 

 

Using a top-down object-oriented strategy, our framework, oTakhi platform, enable every participant to extend the framework independent of other participants by designing their own objects and interfaces.  As long as the simple core is stable (for handling event passing, object construction, destruction), it is virtually maintenance free.

 

In this open framework, every participant is responsible for maintaining his own objects and their documentations, not the framework developers.  Hence, in a way, it is truly democratic in nature.  No single developer dictate how the framework should evolve.

 

The traditional language-level object-orientation does more evil then good here, because it places a limit on a platform's scope (what it can do) to what was originally envisioned by a few developers.

 

That being said, a good criteria for evaluating a framework is whether it is hiding information due to lower-level object encapsulation.  If a framework can be used to build itself, it does not reduce information and can be used to build anything.  (This is called bootstrapping, a good compiler is the ones that can compile itself.)