Hey there! I’m new to the engine, found about it by looking around on YouTube but that’s it, I’ve tried to find some benchmarks for particles, mesh instantiation, etc, but so far have found none (and am not experienced enough to know how to do it myself). I’m new to game development and was looking into Godot with GDScript (as their c# alternative doesnt support web exports), but since I’m familiar with typescript and prefer code-frist approaches, babylon seemed like a good alternative.
But I’m worried that the underlying systems for physics and illumination, combined with JS itself might not be performant enough for 3d games with a decent amount of physics and lighting, as in Godot even though GDScript is slower, the underlying systems for Physics (Jolt) and illumination are really fast and produce a very small bundle.
I saw that babylon supports react native as the compiler (and potentially the forks for desktop and eventually static-hermes I suppose), which I believe could reduce the gap in the future, but I’m mostly concerned for the viability of the engine as of now for complex projects. Are there known complex 3d projects built upon Babylon? Thank you
In my opinion it’s not that useful to directly compare Babylon.js to Godot or Unity or Unreal. Yes they’re all 3D engines, but they serve different audiences and target different platforms.
A closer comparison would be Babylon.js vs THREE.js vs PlayCanvas etc, which are all WebGL/WebGPU engines targeting web browsers.
Your choice will depend on your skills, target platforms, type of project and myriad of other factors, not simply raw performance. Although Babylon.js is feature rich and extremely capable of producing amazing work, being web-based, it’s not a natural choice for say fast-paced first person shooters with AAA graphics, although that doesn’t prevent people from trying, with admirable results
If you want to leverage your existing web stack skills and deploy to the web, Babylon.js is awesome.
I would also say that you shouldn’t necessarily expect better performance using Babylon Native over just Babylon.js alone. That’s even stated in the Babylon Native docs.
I assumed that due to WebGPU being Vulkan under the hood, if the underlying systems were similar, the main bottleneck would be JS itself… which is not slow, but if most of the implementation is written on it, I suppose it’d be compared to a statically compiled language. That’s why I mentioned react native, mostly for the upcoming Static Hermes.
I see a lot of potential for Babylon being web based while supporting platform-specific builds given there’s room for optimization (it’d be amazing to be able to have a great web build either for demo/itch/live previews of open source subsystems, while being able to develop over it on the same project/codebase without having to migrate to a different engine and language eventually)!
Again, thanks!
I’m not a Babylon.js core developer, so I’m sure they’ll correct me if I’m wrong but the main performance constraints compared to a native engine like Godot are interpreted JavaScript and single-threaded web browser environment with resource constraints (memory usage, asset download times etc).
Having said that, performance intensive features like physics and particles are (or can be) handled by WebAssembly, WebGPU or shaders, rather than JS.
However, I’m constantly amazed at how far JS has come in terms of performance … a lot of work has gone into optimising JS code execution and JS engines like V8 over the years.
I totally agree! And that’s why I’m considering JS (TS) a good and viable alternative for game development, it looks like the main bottleneck for performance are browser technologies. I wonder if it’d be worth it to have different platforms with different backends/featuresets eventually (like Godot does for mobile/desktop/browser). But so far, Babylon looks to be a great introduction for JS in game development
All engines have their trade offs. Babylon can be code first, or if you like, there’s the Babylon Editor as well if you don’t. There’s the native version which will change how some things interact with your application and how you might have to go about it a little different but nothing too drastic. There’s good documentation for it as well, and always the forums if you get stuck.
Performances is closer to how you use it but from my experience it’s a lot easier to optimize and know what’s going on in babylon than three.js.If you like there’s also Havoc you can use for physics, which is hard to beat, even with the wasm version.
Based on how itch.io games are made with godot &c. (and presented on web), babylon as I’ve seen it is faster.
Even when those should be faster (downloading the games and run them locally), they often are not.
From my experience with regard to physics and particles:
Babylon’s current (v2) physics is using Havok (e.g. also used in CS:GO), built for wasm (WebAssembly). So far it has handled everything I’ve thrown at it (including full CS levels) with excellent performance.
If you make sure to use GPU particle systems, they aren’t really limited by the JS intepreter and easily supports 10000s of particles.
Oh funny, I’ve been using “&c.” for “etc.” since reading some Ben Franklin ;p (because it looks cool and Ben was a boss)
Meant godot and other such engines >.<
It is crazy though seeing 2d games built on those engines with frame lag, where babylon screams with similar scenes in tri-Dee. I like to think it’s the programmers’ fault, still a bad look for the engines though.
If your target is the web compile a couple of empty 3D WebGL based builds with both Unity/Godot then have a look at their framerates on a web page. On my “front desk office” tier hardware neither can’t even hit 60FPS with EMPTY BUILDS. BabylonJS hits 60fps with dozens of fully rigged game objects, with optimizations this can reach the hundreds complete with an environment and a GUI.
I can’t speak for performance on native platforms, but on the web it’s not even close. On mobile web the gap is even larger with the other engines having weaker intangibles. For example on mobile WebGL builds Godot isn’t capable of keyboard inputs (or rather they’re broken). These are things I personally found unacceptable but also don’t want to spend the time working on myself, so I trended towards BabylonJS.
A particular niche audience on the web is key for developing a seed player base for a game I’m building. So I literally need the web (and good performance), but if I didn’t I’d be happy with just Godot.
I studied in details unity vs godot vs babylon 2 years ago for web projects, it’s a bit old but it still stands.
The main takeaway is that godot and unity are not ready nor optimized for performant web games, as web does not look like their priority.
Their rendering engine with a web export is not the one you see in AAA games and is not more capable than babylon.js or three.js.
An empty project exported for web in godot is >30MB, the entire engine is included. It’s 10MB for Unity. It’s about 1MB for Babylon + 2MB if you use havok.
I did not find any way to enable webgl canvas antialiasing which is required if you want something nice-looking to start with (it looks like Unity does have a settings for that now)
At that time, Unity doc stated “Unity WebGL doesn’t support mobile devices. It might work on high-end devices, but current devices are often not powerful enough and don’t have enough memory to support Unity WebGL content.”. And multithreading was not supported.
I created a basic project displaying a sphere and listed their draw calls through spector.js. This was a big mess for both Unity and Godot (but especially Godot)
Exporting the Unity webgl project took initially 25 mins… the ~10s, making testing any change a chore
On the topic of general performance, you can test various benchmark for browser physics engine here. When I did, I found out havok was the best performing in some extreme cases.
But choosing a framework over performance questions is a bad reason. Unity, Godot, bjs or three.js will all perform roughly similar depending on the use case, but your target hardware is the limit and you will need to understand what’s going on and use the same optimization techniques (running code on GPU, instancing & limiting draw calls, multithreading…) when you reach the limits.
Unlike Unity or Godot, Babylon.js allows to troubleshoot and work within the browser (devtools, bjs inspector, etc). Compared to three.js, Babylon.js has more features and tooling: physics engine, node material editor, particles editor, etc.
that’s interesting and I believe it’ll be even better as Webgpu approaches general availability. I never considered js to be slow, specially compared to Gdscript. And it enables powerful patterns.
The bundle size is a big win for babylon. I just wonder how performant the underlying engines are and how much the gluing language affect (and how much does it matter depending on the scenario). I believe procedural generation would be times slower on js compared to go/rust/c# but it’ll also probably only affect load times and not general performance. I cannot think right now of real-time compute-heavy scenarios that could affect the general performance and even then if that’d make a perceivable difference… bullets? big loops of game object spawns?
I guess that the reason I wonder this is because I remember benchmarking a demo of just object spawns and physics on raylib a few years ago on Node and Go and the difference was huge
