Is Babylon.js for me ?

[GrosSacASacs]

Hi, my team and I are going to create a new game that will run in the browser. I searched a few hours and found a ton of game engines for the web platform, and it takes a lot of time to compare them all. I can program in JS and understand the Web platform well. I want to use a game engine with at least the following functionalities,

• a 3D API with the basic stuff (camera, meshes, materials, animations)
• Dynamic Shadows, Lights
• scene management
• good fps (frames per seconds)
• Uses WebGl (or other standards)
• Can import 3D files from other programs (ex Blender)
• Scales well (Big big game project)

Does Babylon.js satisfy my needs ? I think yes but I am not sure. If not, what should I use ?

[GameMonetize]

Hello and welcome!!!

• a 3D API with the basic stuff (camera, meshes, materials, animations): For sure ;D
• Dynamic Shadows, Lights: Yes sir! (http://doc.babylonjs.com/tutorials/Shadows, http://doc.babylonjs.com/tutorials/Lights)
• scene management: of course!
• good fps (frames per seconds): It depends on the content but we work hard to make babylon.js the faster engine ever !
• Uses WebGl (or other standards): Yes!
• Can import 3D files from other programs (ex Blender): Blender, 3dsmax, unity and also file formats: fbx, stl, obj
• Scales well (Big big game project): Really hard to respond but one sure thing: this forum will be your best sidekick !

[Dad72]

Babylon perfectly meets your needs. it is a very good engine, a very good developer team and a great community.

You looking good engine? You found it... 

[NasimiAsl]

yes  i recommended for you make test for yourself with top engines.

i guaranteed BJS can do more than you want .;)

[GrosSacASacs]

Ok thanks. In what situation is three.js a better option ?

[adam]

40 minutes ago, GrosSacASacs said:

In what situation is three.js a better option ?

If you like using stackoverflow for help.

https://github.com/mrdoob/three.js/issues/1979

http://stackoverflow.com/questions/tagged/three.js?sort=newest&pageSize=10

[prvi_treti]

55 minutes ago, GrosSacASacs said:

Ok thanks. In what situation is three.js a better option ?

probably only in case you're interested in software / canvas rendering.

[Dad72]

ThreeJS is more complicated. Babylon is much simpler

[jerome]

Actually, 3JS provides many renderers : canvas2d, webgl, CSS3render, SVGRenderer and tries to abstract the way to design a scene the same way for all these renderers.

Moreover, the library is smaller (even with all these renderers), this means that a lot of features are external ones (cameras, for instance). It's not focused on game development initially either, this means for example, that there's no dedicated method to handle the render loop (you have to do it by your own) and no specific concerns about the memory allocation or the garbage collection or any other optimization about the CPU/GPU pipeline (ex : no use of indices, only flat vertex array, no memory reuse on normal computations, etc).

There's no dedicated support forum either. You need to use StackOverFlow.

The project is older than BJS, there are some books about the framework (not all are updated to the latest version actually) and some existing commercial projects. If you dig a little in the commercial project codes, you quickly notice that the framework provided functions are more or less used and a lot of genuine WebGL is deployed : shadders, GLSL, etc. Because the needs quickly overpass what 3JS initially provides.

 

BJS focuses only on WebGL, so no other stuff. The library is twice bigger than 3JS one... for only one renderer. This means BJS intends to embbed the more features as possible for the final user, but keeping only on the WebGL + animations way. As it intends to be a game framework, it provides everything about animations and concentrates on keeping fast. This means a lot of process, memory, bandwith optimizations, especially in the render loop. If you have a look at existing demo codes done with BJS, you'll see that the lib provides almost everything to do simply what you need to code a complex game or any other WebGL rendered animated project.

When features are provided as external ones, such as the material library, they remain supported by and in the official repo. This forum is the official place for community help and even core team support. Moreover some official tools like the playground, the CYOS, or the sandbox are provided to help you to share your issues or realizations.

As the project is less old than 3JS, there are currently less available books (two for what I know so far), but you'll find the biggest online doc ever : tutorials, API doc (in improvement), videos, curses, tons of running and detailed examples from the forum/playground, etc.

 

We have plenty of examples of people having started a project under 3JS, then tried and ported it to BJS and never switched back. Make a quick search on this forum, you'll understand why ;-)

[Kesshi]

Some time ago i also needed to decide between ThreeJs and BabylonJs for our webgl projects.
I decided to use BabylonJs because:

• better out of the box experience with a lot of features
  ThreeJs has also a lot of features but often you need to include some plugins for it. This can be an issue later on because some plugins may be no longer supported.
• BabylonJs is written in Typescript
  In my opinion this alone makes the whole library more stable than ThreeJs. You need to be very carefull if you want to write big libraries like this in pure JS.
• Very active developement. It feels almost like every day a new awesome feature is added 
• very very nice community which tries to help everyone
  If you have a problem. Just ask. We try to help.
• Bugs get fixed very fast after they get reported.

If you have a simple project and you need have a fallback for old browsers without WebGL support, than i would go for ThreeJs because of the Canvas renderer.

[al404]

since I just started messing with threejs for a project and thinking to switch to babylon i notice that many threejs example i found report a notice in console for deprecated or not valide code 

I get deprecated code on mid 2015 examples and not working code with 2 / 3 years old examples and latest library

I was wondering if babylon did change that fast too?

as far as i read it is possible to write babylon code with JS or Typescript, is that correct?

[GameMonetize]

We add a lot of features but we have on golden rule (I'm the keeper of this rule): NEVER break backward compatibility.

 

(To be honest in really rare occasions, we need to break a little thing but it is like 0.0001% of all changes)

 

Regarding languages, you can use JS or TS :). If you want to contribute (we would love to welcome you in our contributors list) you will have to use TS to submit a pull request.

[al404]

@deltakosh thanks for your reply 

I'm going to see some video and MS tutorials to find out something more about babylon and TS

 

[Tomm Huth]

On 4/10/2016 at 6:41 PM, Deltakosh said:

We add a lot of features but we have on golden rule (I'm the keeper of this rule): NEVER break backward compatibility.

 

(To be honest in really rare occasions, we need to break a little thing but it is like 0.0001% of all changes)

 

Regarding languages, you can use JS or TS :). If you want to contribute (we would love to welcome you in our contributors list) you will have to use TS to submit a pull request.

Is this the reason why there seems to be (more than a little) stuff that is marked as deprecated, but is not removed? It strikes me as less optimal to leave deprecated stuff in, even when releasing new major versions (which explicitly indicates possible breaking changes)? Isn't that going to bloat the framework and make the API more confusing, especially with changes that aren't too difficult to migrate? If people aren't willing to do the work needed to upgrade, they can easily just stick with the version they have until they can. 

[tomer]

@Tomm Huth I practically asked the same question a few weeks ago, and still completely agree.

[Guest]

We will remove SOME of them for 4.0 but not all depending on how many people still use them.

 

But this will be really a few as we do not want to break changes because then playgrounds will have to be fixed, etc... as I mentioned in the other topic

[Guest]

Here is the current breaking change list:

## Breaking changes

 

- `Database.IDBStorageEnabled` is now false by default ([Deltakosh](https://github.com/deltakosh))

- `Database.openAsync` was renamed by `Database.open` ([Deltakosh](https://github.com/deltakosh))

- `scene.database` was renamed to `scene.offlineProvider` ([Deltakosh](https://github.com/deltakosh))

- `BoundingBox.setWorldMatrix` was removed. `BoundingBox.getWorldMatrix` now returns a `Readonly<Matrix>` ([barroij](https://github.com/barroij))

- `Matrix`'s accessor `m` and method `toArray` and `asArray` now returns a `Readonly<Float32Array>` as the matrix underlying array is not supposed to be modified manually from the outside of the class ([barroij](https://github.com/barroij))

- Removed some deprecated (flagged since 3.0) properties and functions ([Deltakosh](https://github.com/deltakosh))

- `scene.getInterFramePerfCounter()`: use SceneInstrumentation class instead

- `scene.interFramePerfCounter`: use SceneInstrumentation class instead

- `scene.getLastFrameDuration()`: use SceneInstrumentation class instead

- `scene.lastFramePerfCounter`: use SceneInstrumentation class instead

- `scene.getEvaluateActiveMeshesDuration()`: use SceneInstrumentation class instead

- `scene.evaluateActiveMeshesDurationPerfCounter`: use SceneInstrumentation class instead

- `scene.getRenderTargetsDuration()`: use SceneInstrumentation class instead

- `scene.getRenderDuration()`: use SceneInstrumentation class instead

- `scene.renderDurationPerfCounter`: use SceneInstrumentation class instead

- `scene.getParticlesDuration()`: use SceneInstrumentation class instead

- `scene.particlesDurationPerfCounter`: use SceneInstrumentation class instead

- `scene.getSpritesDuration()`: use SceneInstrumentation class instead

- `scene.spriteDuractionPerfCounter`: use SceneInstrumentation class instead

- `engine.drawCalls`: use SceneInstrumentation class instead

- `engine.drawCallsPerfCounter`: use SceneInstrumentation class instead

- `shadowGenerator.useVarianceShadowMap`: use useExponentialShadowMap instead

- `shadowGenerator.useBlurVarianceShadowMap`: use useBlurExponentialShadowMap instead

[Nodragem]

Yeah! Let's break everything  

30 minutes ago, Deltakosh said:

Here is the current breaking change list:

@Deltakosh Concerning the compatibility issues with the PGs, you could add a droplist where the devs/users could select if their PG is to be run with BabylonJS 3.x or with BabylonJS 4.x.

For instance, as Python 2 and Python 3 are both used in data science, jupyter-notebooks would let you start a notebook with whichever version.

You can have a look here, Go in File/New Notebook or in Kernel/Switch Kernel: https://hub.mybinder.org/user/ipython-ipython-in-depth-ry7uv1oa/notebooks/binder/Index.ipynb

The online jupyter-notebooks only have Python 3 installed, but I can swear that if you have both versions, you can switch.

On 3/20/2016 at 12:33 AM, GrosSacASacs said:

Scales well (Big big game project)

@GrosSacASacs I started to use BabylonJS recently, and my feeling is that it has a lot of potential, but it might miss few things to be easily scalable for a Big Big game. But at the same time, the community is great and the devs are nice, so the ideas you have to make the engine better and scalable will probably be heard, discussed and implemented. Some times they just get implemented straight away. This opportunity to be at the heart of the development loop is something you won't find in Unity or Unreal (too many people). 

Also, maybe more than the engine, it is also the game developer who needs to write scalable code  ! I let you know how it goes for me (fingers crossed!).

On 3/20/2016 at 1:55 AM, Deltakosh said:

scene management: of course!

I was actually wondering how I was going to do that  Just discovered we could have several scenes! this PG rocks: https://www.babylonjs-playground.com/#MXCRPS#1

[NasimiAsl]

hi 

i like share my  words too 

i wanna change a main Question to who wanna use babylonjs ? 

1. a starter web programmer but he/she have experience with web browsers limitations (if he dont it is soon for start working with webgl for him) so babylonjs 100% do all  expectations 

he/she can be sure  about that because this forum fully support that  

 

2. a perfect web programmer  need a 3d framework 

      2-a : he/she start learning first about how to use all part of BJS

     * he/she can be a good webgl programmer in 3 or 4 week if he practice a while or find a good solution for short requirement in 2 days

      2-b : he/she try some example  or try mix them by her/him old experience with other  3d system

      * he/she failed and try make new engine by copy and past and collect from others framework (i hope he/she success) 

      2-c : he/she use from BJS core and make all requirement  by himself and use all benefit and new option every day appended to babylonjs

      * nobody care about what he do but he still working   ( i don't see any she in this part yet )

      2-d: others 

      * i don't know about them  i need research more

 

3. others again that option added  for support all visitors 

so after you choose that don't ask this questions   

[any framework] cant make big big project ? (why ???? a lot hidden parameters ) 

[framework a] render better than [framework b] ? (GPU render both maybe you use bad tools from framework or maybe you need some new tools just research before you ask)

 

someone say babylonjs is better in shader management and support   i don't know who but i am sure he accept all shader challenge 

** oh and GeometryBuilder too (please use them plzzzzz )

[Guest]

18 hours ago, Nodragem said:

Concerning the compatibility issues with the PGs, you could add a droplist where the devs/users could select if their PG is to be run with BabylonJS 3.x or with BabylonJS 4.x.

Already the case (check the Version: Latest combo box)

[Tomm Huth]

@Deltakosh If there is concern around playgrounds not working, then that seems to be very much already the case. If I find a playground at least a couple of years old, there's a 50-50 chance they break, and it happens very frequently. The playground desperately needs: 

- Defaulting to most recent stable version.

- The option to set any previous stable version

- Saving that chosen version along with the playground, so that in two years time it will still run, because its's not being auto upgraded. 

[Spankied]

On 3/20/2016 at 6:43 PM, adam said:

If you like using stackoverflow for help.

https://github.com/mrdoob/three.js/issues/1979

http://stackoverflow.com/questions/tagged/three.js?sort=newest&pageSize=10

10-32 shots fired