7 ms·

Babylon.js 6.0

154 points by q_andrew 3y ago

q_andrew 3y ago
I think Havoc physics will be a very welcome addition. Threejs has an adjacent library based off of bullet physics -- a solid library, but one that can be a bit finicky to set up. Although, physics engines are inherently difficult to work with in the first place. As a technical 3D artist, Babylon has been a great way to dive into web dev, and it parallels with standard game engines just enough that I can easily find my way around the documentation.
- nerdchum 3y ago
  hey this is total side tangent but what software do you use to develop your 3D art?
  - q_andrew 3y ago
    Blender is definitely the weapon of choice. Substance 3D is almost required nowadays for proprietary rendering, and the occasional Autodesk+VRAY combo for older established clients. Edit: On the coding side, python is great for pipelines (especially now that blender has its own module). Imagemagick is great for formatting textures and huge .tiff files. ffmpeg is the king of video formatting.
- ajdoingnothing 3y ago
  Havok physics is certainly an interesting addition! Especially since Cannon.js & Oimo.js are not being maintained anymore. Ammo.js (port of Bullet) seems to have some updates here and there (IIRC, it was easier to setup using Babylon considering that it used a wrapper across all physics libraries). Good to see that Babylon.js is doing well.
- looklookatme 3y ago
  > Although, physics engines are inherently difficult to work with in the first place. Do you have any insights into why this is the case? What areas of simulation or tooling are difficult to work with? Disclaimer: I'm on the Havok team and worked on the Babylon.JS integration.
  - capableweb 3y ago
    Unrelated but related to Havok: I love Havok, and love to see a Bevy integration, is there one in the works? Doesn't seem like anyone in the Bevy community has yet to stepped up to the plate, and considering Havok is not FOSS, maybe it's unlikely to. But still wanted to ask.
    - looklookatme 3y ago
      I haven't come across Bevy before, but it certainly looks very neat from the example demos. If there's a WASM runtime for Rust, I _imagine_ it's possible to take the HavokPhysics.wasm used by Babylon.JS and calling the functions it exposes - the physics functionality exported by that WASM is pretty general and does not make any assumptions about the engine it's running in.
  - q_andrew 3y ago
    Hey! Congrats on the launch, the touted performance increases are mind blowing. I think physics engines are difficult for a few reasons: - They don't mesh with a lot of features that modelers take for granted (non-uniform scaling, concave meshes, lax model scaling) - It's hard know intuitively what values to use for things like acceleration, density, velocity, damping, friction. Especially because they are very inter-dependent. - Interaction with moving kinematic or non-physics objects is an undefined behavior that has to be tested pretty rigorously. - In gamedev, rigidbody physics are basically a trojan horse for gameplay bugs like clipping through the map and sudden bursts of high speeds (Which is both magical and frustrating). It's a non-trivial task to sandbox those behaviors completely. - Projectiles. There's no catch-all solution for small fast-moving objects, it's always a tradeoff. But that's mostly because big O dictates it to be so.
    - looklookatme 3y ago
      Thanks for those insights! I think some of the things you mention (non-uniform scaling, concave meshes) are getting easier these days, thanks to tooling around things like convex decomposition and relaxed memory requirements, although, even without considering physics, it seems scaling causes huge problems for _everyone_ - feels like every Blender tutorial out there will say "remember to apply scale" to sidestep those scale issues. The other things you talk about feel very second-nature to me at this stage, so it's interesting to hear that kind of perspective. I think physics engines in general could certainly be doing a better job at documenting how the exposed physical parameters map unto use-cases.
- yodon 3y ago
  >I think Havoc physics will be a very welcome addition No kidding. The "Physics" in Babylon.js is at the inexcusably "my first game engine" level of incompetence. Velocity and acceleration are treated as if they have the same dimensions. All kinds of deeply embedded movement code lacks any understanding of world time. You can definitely get a little game going quickly in it because you don't have to think about any "hard" things, but when you try running your game on systems whose frame rates differ wildly you suddenly understand why real game engines care about the fact that velocity is measured in units of m/s and acceleration in units of m/s^2, and that it matters whether you build your art assets at meter scale or centimeter scale or etc.
  - hu3 3y ago
    Hi. I'd like to leverage your experience to ask for a JS game engine suggestion for a 2D game that I plan to publish on web and mobile. I'd like to use something lighter than Unity or Godot.
    - beepbooptheory 3y ago
      Not gp but you could look at Phaser or Pixijs! https://github.com/photonstorm/phaser https://github.com/photonstorm/phaser https://pixijs.com/ https://pixijs.com/
    - aww_dang 3y ago
      https://melonjs.org/ https://melonjs.org/ https://github.com/melonjs/melonJS https://github.com/melonjs/melonJS
    - nomadtwin 3y ago
      https://defold.com/ https://defold.com/
  - hutzlibu 3y ago
    To be clear, you are only talking about the previous implementation of physics in babylon, now called V1? Do you have insights, into whether the new havoc port is better designed? They seemed to have reimplemented the whole physic architecture which they now call V2: https://doc.babylonjs.com/features/featuresDeepDive/physics https://doc.babylonjs.com/features/featuresDeepDive/physics
janosdebugs 3y ago
Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning curve is steep, it doesn't blindside you.
- q_andrew 3y ago
  Yes, I'm a big fan of the documentation. According to the release blog, they are re-organizing the docs for 6.0 -- hopefully a further improvement: https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f1662e3a https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f...
jalino23 3y ago
this is so nice! I shall be making my game with this! just kidding I need to learn - linear algebra first - then that opengltutorial - learn 3d modeling, animation, rigging, uv, texturing.
- stuckinhell 3y ago
  Just start with making the game. Try unity and playmaker if you want to avoid that.
- z3t4 3y ago
  In a high level 3d engine like this you do not need advanced math. You basically only need to know about coordinate systems. Linear algebra is good if you want to make your own 3d engine from scratch. Just start with something simple and learn along the way.
tppiotrowski 3y ago
What is the high level difference between Babylon.js and Three.js?
- esperent 3y ago
  Babylon.js is (working towards) being a batteries included game engine. Three.js is a rendering engine with a lot of first and third party plugins. Add the right plugins and you can probably do anything Babylon can, or use as is and you can make a lightweight landing page. An analogy is an IDE vs VSCode. Pre-built vs lightweight and extensible. Until recently, I think Three.js has been a better fit for the "web" paradigm where everything has to be lightweight and the main focus of 3d graphics is landing pages that need to load in 3s or so. On the other hand, Babylon.js is also an amazing tool and I think the comparison to Three.js is a little unfair to both. They solve different problems in the 3D space, and both are great at what they do. A better comparison for Babylon.js is Playcanvas.
- janosdebugs 3y ago
  My wife did a lot of research into this when we picked an engine for our website and she found that the API of ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior documentation and doesn't seem to suffer from lag spikes as much. However, it's an oldschool API (did I mention they really value backwards compatibility?) and requires quite a bit of learning to get going. Also, it's three times the size of ThreeJS, so bandwidth optimization is absolutely required.
deleted 3y ago
[deleted]
pjmlp 3y ago
I am usually quite negative regarding Web 3D APIs given how little we got to see with stuff that actually impresses, WebGL 2.0 is after all kind of Playstation 3-like in capabilities. However the babylonjs 6 release video has several goodies in there that are actually at a quality level, that shows there are a few gems out there after all. https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f1662e3a https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f... Finally I stand corrected, even if there is some gap to cover relative to native APIs.
fifticon 3y ago
I wonder if it has become easier to use and more useful. I had a brief stint where I became exited about it (based on what I later came to view as hype), and spent some effort trying to make it do cool stuff. I ended up abandoning it for a number of reasons. I've served time with a number of 3d tech through the ages. My favorite was VRML from 25 years ago (sigh..), which to me is still unmatched - you could open up a notepad file and just plunk in a 3d model structure in ASCII, then load it immediately in the browser AND WALK AROUND IN IT. Sadly, the browser plugins were binary, and have died out together with web browsers you can no longer download or install (Netscape, where are you?..) If you like pain, you can still get hold of "client technology" that will run (some) VRML models, but you must like pain, both to get hold of them, and as you afterwards try to run and use them. So yeah, VRML is gone, I know. Then there is AFrame.IO, which I've used some. It doesn't offer much, so it doesn't disappoint on what it delivers.. It is probably the closest to VRML, but sadly doesn't offer as good an experience as we had around 1999/2000 :-/. So, I've tried babylon.js. My gripes with it are: - for the usual demos it loads, it doesn't seem to have a 'preferred navigation feel'. - it doesn't seem to care for planet earth physics much. I'm probably not describing this aspect the right way. VRML used to have 1.0 units correspond to 1 meter, and people would size their content based on this. Similarly, rendering client navigation would base on this, so you would move around at speeds akin to walking - it would even default the viewpoint height to 1.8 or something like that (to resemble a human being about 180cm of height.) It's about the look&feel, how it FEELS when you try to navigate the 3d world. If it feels janky, not smooth, that is bad.. And if 10 different 3d/VR experiences have different navigation model feels, that does not feel good to the end user. VRML had this down - in 2001. TL;DR: Default navigation UIs in babylon seems like a kludgy afterthought, instead of a "Steve Jobs design priority". Another example: Setting up a default test scene. If I were trying to push my 3d engine/tech to people, I would prioritize tools to set up small "hello world" scenarios. Supporting a good 'hello world' is not frivolous. It is about selling your tech, and convincing. If I try out a small demo, and I feel it is intuitive and easy, and that "I am in control", I think 'Yeah I can build something on this!', and get the impulse/momentum to want to build something in this. Again, VRML did this well: You could set up a scene in like 5 lines of code. For example, you could specify a sky sphere, or a sky box, with 3-5 lines of code. I would often do a 3d world, where I started specifying a ground and a sky and colors for them, with such 5 lines. Being able to load your 3d scene already with this and walk around in it, is COOL! It makes you want to "put further stuff in there", because you can already see it. Babylon.js, in theory, has similar stuff. But if you try to actually use it, you find out that it wasn't really intended for general use, and not really intended for any real use either, it seems more like a sort of 'can't you throw _something_ like that in there?'. _SOMETHING_.. - not something good. So - another strike - for setting up a basic sky and ground, babylon.js is worse/not as good as HTML from 25 years ago :-/. They may have fixed some of this, but past disappointed experience makes me reluctant to take the effort to check it out again :-/ Another thing that put me off: I never found any community actively using babylon.js, at least not that I could find with google? (Discord & your ilk be damned.) I found reddit's /r/babylonjs, but it was mostly empty, apart from release announcements by MS, and random demos done by MS people. So if there is any active community using BJS, I haven't found them? What I've mostly used instead, is - the roblox engine (I use all this to try out ideas, not to serve a commercial purpose.) - the GODOT engine, which I am willing to praise as high as I am willing to .. not? praise babylonjs? - Unity, but for what I do, roblox serves as well, plus I don't have to handle publishing. I had high hopes for babylon.js - as a wrapper that would shield me against three.js changes - but I am still looking.

154 points by q_andrew 3y ago

I think Havoc physics will be a very welcome addition. Threejs has an adjacent library based off of bullet physics -- a solid library, but one that can be a bit finicky to set up. Although, physics engines are inherently difficult to work with in the first place. As a technical 3D artist, Babylon has been a great way to dive into web dev, and it parallels with standard game engines just enough that I can easily find my way around the documentation.

nerdchum 3y ago
hey this is total side tangent but what software do you use to develop your 3D art?
- q_andrew 3y ago
  Blender is definitely the weapon of choice. Substance 3D is almost required nowadays for proprietary rendering, and the occasional Autodesk+VRAY combo for older established clients. Edit: On the coding side, python is great for pipelines (especially now that blender has its own module). Imagemagick is great for formatting textures and huge .tiff files. ffmpeg is the king of video formatting.
ajdoingnothing 3y ago
Havok physics is certainly an interesting addition! Especially since Cannon.js & Oimo.js are not being maintained anymore. Ammo.js (port of Bullet) seems to have some updates here and there (IIRC, it was easier to setup using Babylon considering that it used a wrapper across all physics libraries). Good to see that Babylon.js is doing well.
looklookatme 3y ago
> Although, physics engines are inherently difficult to work with in the first place. Do you have any insights into why this is the case? What areas of simulation or tooling are difficult to work with? Disclaimer: I'm on the Havok team and worked on the Babylon.JS integration.
- capableweb 3y ago
  Unrelated but related to Havok: I love Havok, and love to see a Bevy integration, is there one in the works? Doesn't seem like anyone in the Bevy community has yet to stepped up to the plate, and considering Havok is not FOSS, maybe it's unlikely to. But still wanted to ask.
  - looklookatme 3y ago
    I haven't come across Bevy before, but it certainly looks very neat from the example demos. If there's a WASM runtime for Rust, I _imagine_ it's possible to take the HavokPhysics.wasm used by Babylon.JS and calling the functions it exposes - the physics functionality exported by that WASM is pretty general and does not make any assumptions about the engine it's running in.
- q_andrew 3y ago
  Hey! Congrats on the launch, the touted performance increases are mind blowing. I think physics engines are difficult for a few reasons: - They don't mesh with a lot of features that modelers take for granted (non-uniform scaling, concave meshes, lax model scaling) - It's hard know intuitively what values to use for things like acceleration, density, velocity, damping, friction. Especially because they are very inter-dependent. - Interaction with moving kinematic or non-physics objects is an undefined behavior that has to be tested pretty rigorously. - In gamedev, rigidbody physics are basically a trojan horse for gameplay bugs like clipping through the map and sudden bursts of high speeds (Which is both magical and frustrating). It's a non-trivial task to sandbox those behaviors completely. - Projectiles. There's no catch-all solution for small fast-moving objects, it's always a tradeoff. But that's mostly because big O dictates it to be so.
  - looklookatme 3y ago
    Thanks for those insights! I think some of the things you mention (non-uniform scaling, concave meshes) are getting easier these days, thanks to tooling around things like convex decomposition and relaxed memory requirements, although, even without considering physics, it seems scaling causes huge problems for _everyone_ - feels like every Blender tutorial out there will say "remember to apply scale" to sidestep those scale issues. The other things you talk about feel very second-nature to me at this stage, so it's interesting to hear that kind of perspective. I think physics engines in general could certainly be doing a better job at documenting how the exposed physical parameters map unto use-cases.
yodon 3y ago
>I think Havoc physics will be a very welcome addition No kidding. The "Physics" in Babylon.js is at the inexcusably "my first game engine" level of incompetence. Velocity and acceleration are treated as if they have the same dimensions. All kinds of deeply embedded movement code lacks any understanding of world time. You can definitely get a little game going quickly in it because you don't have to think about any "hard" things, but when you try running your game on systems whose frame rates differ wildly you suddenly understand why real game engines care about the fact that velocity is measured in units of m/s and acceleration in units of m/s^2, and that it matters whether you build your art assets at meter scale or centimeter scale or etc.
- hu3 3y ago
  Hi. I'd like to leverage your experience to ask for a JS game engine suggestion for a 2D game that I plan to publish on web and mobile. I'd like to use something lighter than Unity or Godot.
  - beepbooptheory 3y ago
    Not gp but you could look at Phaser or Pixijs! https://github.com/photonstorm/phaser https://github.com/photonstorm/phaser https://pixijs.com/ https://pixijs.com/
  - aww_dang 3y ago
    https://melonjs.org/ https://melonjs.org/ https://github.com/melonjs/melonJS https://github.com/melonjs/melonJS
  - nomadtwin 3y ago
    https://defold.com/ https://defold.com/
- hutzlibu 3y ago
  To be clear, you are only talking about the previous implementation of physics in babylon, now called V1? Do you have insights, into whether the new havoc port is better designed? They seemed to have reimplemented the whole physic architecture which they now call V2: https://doc.babylonjs.com/features/featuresDeepDive/physics https://doc.babylonjs.com/features/featuresDeepDive/physics

janosdebugs 3y ago

Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning curve is steep, it doesn't blindside you.

q_andrew 3y ago
Yes, I'm a big fan of the documentation. According to the release blog, they are re-organizing the docs for 6.0 -- hopefully a further improvement: https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f1662e3a https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f...

jalino23 3y ago

this is so nice! I shall be making my game with this! just kidding I need to learn - linear algebra first - then that opengltutorial - learn 3d modeling, animation, rigging, uv, texturing.

stuckinhell 3y ago
Just start with making the game. Try unity and playmaker if you want to avoid that.
z3t4 3y ago
In a high level 3d engine like this you do not need advanced math. You basically only need to know about coordinate systems. Linear algebra is good if you want to make your own 3d engine from scratch. Just start with something simple and learn along the way.

tppiotrowski 3y ago

What is the high level difference between Babylon.js and Three.js?

esperent 3y ago
Babylon.js is (working towards) being a batteries included game engine. Three.js is a rendering engine with a lot of first and third party plugins. Add the right plugins and you can probably do anything Babylon can, or use as is and you can make a lightweight landing page. An analogy is an IDE vs VSCode. Pre-built vs lightweight and extensible. Until recently, I think Three.js has been a better fit for the "web" paradigm where everything has to be lightweight and the main focus of 3d graphics is landing pages that need to load in 3s or so. On the other hand, Babylon.js is also an amazing tool and I think the comparison to Three.js is a little unfair to both. They solve different problems in the 3D space, and both are great at what they do. A better comparison for Babylon.js is Playcanvas.
janosdebugs 3y ago
My wife did a lot of research into this when we picked an engine for our website and she found that the API of ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior documentation and doesn't seem to suffer from lag spikes as much. However, it's an oldschool API (did I mention they really value backwards compatibility?) and requires quite a bit of learning to get going. Also, it's three times the size of ThreeJS, so bandwidth optimization is absolutely required.

deleted 3y ago

[deleted]

pjmlp 3y ago

I am usually quite negative regarding Web 3D APIs given how little we got to see with stuff that actually impresses, WebGL 2.0 is after all kind of Playstation 3-like in capabilities. However the babylonjs 6 release video has several goodies in there that are actually at a quality level, that shows there are a few gems out there after all. https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f1662e3a https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f... Finally I stand corrected, even if there is some gap to cover relative to native APIs.

fifticon 3y ago

I wonder if it has become easier to use and more useful. I had a brief stint where I became exited about it (based on what I later came to view as hype), and spent some effort trying to make it do cool stuff. I ended up abandoning it for a number of reasons. I've served time with a number of 3d tech through the ages. My favorite was VRML from 25 years ago (sigh..), which to me is still unmatched - you could open up a notepad file and just plunk in a 3d model structure in ASCII, then load it immediately in the browser AND WALK AROUND IN IT. Sadly, the browser plugins were binary, and have died out together with web browsers you can no longer download or install (Netscape, where are you?..) If you like pain, you can still get hold of "client technology" that will run (some) VRML models, but you must like pain, both to get hold of them, and as you afterwards try to run and use them. So yeah, VRML is gone, I know. Then there is AFrame.IO, which I've used some. It doesn't offer much, so it doesn't disappoint on what it delivers.. It is probably the closest to VRML, but sadly doesn't offer as good an experience as we had around 1999/2000 :-/. So, I've tried babylon.js. My gripes with it are: - for the usual demos it loads, it doesn't seem to have a 'preferred navigation feel'. - it doesn't seem to care for planet earth physics much. I'm probably not describing this aspect the right way. VRML used to have 1.0 units correspond to 1 meter, and people would size their content based on this. Similarly, rendering client navigation would base on this, so you would move around at speeds akin to walking - it would even default the viewpoint height to 1.8 or something like that (to resemble a human being about 180cm of height.) It's about the look&feel, how it FEELS when you try to navigate the 3d world. If it feels janky, not smooth, that is bad.. And if 10 different 3d/VR experiences have different navigation model feels, that does not feel good to the end user. VRML had this down - in 2001. TL;DR: Default navigation UIs in babylon seems like a kludgy afterthought, instead of a "Steve Jobs design priority". Another example: Setting up a default test scene. If I were trying to push my 3d engine/tech to people, I would prioritize tools to set up small "hello world" scenarios. Supporting a good 'hello world' is not frivolous. It is about selling your tech, and convincing. If I try out a small demo, and I feel it is intuitive and easy, and that "I am in control", I think 'Yeah I can build something on this!', and get the impulse/momentum to want to build something in this. Again, VRML did this well: You could set up a scene in like 5 lines of code. For example, you could specify a sky sphere, or a sky box, with 3-5 lines of code. I would often do a 3d world, where I started specifying a ground and a sky and colors for them, with such 5 lines. Being able to load your 3d scene already with this and walk around in it, is COOL! It makes you want to "put further stuff in there", because you can already see it. Babylon.js, in theory, has similar stuff. But if you try to actually use it, you find out that it wasn't really intended for general use, and not really intended for any real use either, it seems more like a sort of 'can't you throw _something_ like that in there?'. _SOMETHING_.. - not something good. So - another strike - for setting up a basic sky and ground, babylon.js is worse/not as good as HTML from 25 years ago :-/. They may have fixed some of this, but past disappointed experience makes me reluctant to take the effort to check it out again :-/ Another thing that put me off: I never found any community actively using babylon.js, at least not that I could find with google? (Discord & your ilk be damned.) I found reddit's /r/babylonjs, but it was mostly empty, apart from release announcements by MS, and random demos done by MS people. So if there is any active community using BJS, I haven't found them? What I've mostly used instead, is - the roblox engine (I use all this to try out ideas, not to serve a commercial purpose.) - the GODOT engine, which I am willing to praise as high as I am willing to .. not? praise babylonjs? - Unity, but for what I do, roblox serves as well, plus I don't have to handle publishing. I had high hopes for babylon.js - as a wrapper that would shield me against three.js changes - but I am still looking.