Babylon.js 6.0 | Hacker News Reader

Babylon.js 6.0

babylonjs.com

154 pointsq_andrew30 comments

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.

hey this is total side tangent but what software do you use to develop your 3D art?

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.

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.

> 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.

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.

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.

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.

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.

Do you think the problems with scaling (particularly non-uniform) primarily arise because most physics, animation, etc., are biased towards uniform normalized scale? Or is there some other issue I am unaware of that causes the issues?

Not very relevant to the main topic here, but the site www.havok.com seems to have a SSL cert problem.

>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.

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.

Not gp but you could look at Phaser or Pixijs!

https://github.com/photonstorm/phaser

https://pixijs.com/

https://melonjs.org/

https://github.com/melonjs/melonJS

https://defold.com/

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

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.

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-dcb5f...

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

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.

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.

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-dcb5f...

Finally I stand corrected, even if there is some gap to cover relative to native APIs.

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.

Just start with making the game. Try unity and playmaker if you want to avoid that.

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.

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.

The part of my rant about a basic scene setup, was unclear. I'm disappointed about this part of the babylon design. It just doesn't work very well, and isn't very well thought through/designed (at least, I've seen better, in every way..)

Basically, this feels like the WPF of 3d to me :-/. If they have replaced this with something wonderful, I take it all back..

  <ground receive-shadows="true"></ground>
  <skybox></skybox>
  <camera>
      <use-bouncing-behavior type="false"></use-bouncing-behavior>
      <use-auto-rotation-behavior type="false"></use-auto-rotation-behavior>
      <behaviors>
          <auto-rotate type="0"></auto-rotate>
          <bouncing type="0"></bouncing>
      </behaviors>
  </camera>

</babylon>

It feels like something designed by somebody who was explained by someone else what they had to do, but never themselves understood the 'why'. Like WPF, which feels like it was made by someone who never had to actually do GUIs themselves.

WPF team was created from the IE team when it was disbanded during Longhorn days, hand plenty of Win32 folks, and was the original contributor to the CSS Grid design.

Reply on news.ycombinator.com