Babylon.js: A Web-First Game Engine Powering Cross-Platform Experiences

Introduction

The Babylon.js team is a small (13 people) passionate group of computer graphics geeks, focused on pushing the boundaries of what’s possible with real-time rendering on the web. We come from many different backgrounds (Adobe, Microsoft, SAP, Notre Dame, GE, HP, Disney, Dreamworks, AnimaLogic, US Department of Defense, Neo Pangea, etc.) and cultures (US, Brazil, Germany, Israel, France).

Our team has worked on a wide breadth of different types of projects from Animated Feature Films (Lego Movie, Kung Fu Panda, Shrek), helped launch cutting edge Augmented Reality headsets (HoloLens 1,2), and shipped multiple games (Microsoft Flight Simulator, Project Spark, Minecraft, etc). We have all come together at Microsoft, united in a shared passion for creating one of the most powerful, beautiful, simple, and open web rendering engines in the world.

Babylon.js

Babylon.js was first introduced as an open-source project in 2013 with the simple goal of making it easier for web developers to access the GPU. Many game developers take for granted, the fact that access to the GPU is available through countless different interfaces, including game engines. In the early part of the 2000s, this wasn’t the case for web developers. The major browser providers (Chrome, Firefox, Edge, etc.) all agreed on an open standard called WebGL that provided web developers with an interface layer to access the GPU, however, there was one very big problem. WebGL is DENSE! It’s complicated and hard to learn….prohibitively so for many web developers.

This is where Babylon.js originally came into play. You can think of Babylon.js as an interface layer that sits on top of WebGL. It’s a simple javascript API that looks and feels familiar to web developers. Rather than needing 100 lines of code to draw a cube with raw WebGL, Babylon.js would allow web developers to do it with just one single line of code. In fact, this principle is still very alive today (10 years later). We try to provide advanced features to web developers in just a single line of code. So it all started as a way to simply access the GPU on the web.

Wow has it evolved! In over 10 years, Babylon.js has become a fully-featured game and rendering engine. We don’t just say that flippantly. It really does offer easy access to some of the most powerful features game developers have come to expect. Advanced Animation systems, 2D and Solid Particle systems, Sprites, Frustrum Culling, Hardware Scaling, LODs, PBR (Physically Based Rendering) Materials, Advanced Light and Shadow systems, some of the world’s most advanced Physics engines, Post-Processing, Video Textures… the list goes on and on. You can read more about just a few of the features here and find a full list here.

In addition to the list of features growing, Babylon has also evolved beyond the web. You can now create games and experiences in Babylon that work inside the browser OR as self-contained Native Applications on iOS, MacOS, Windows, Android, and Linux. The easiest way to think about Babylon.js today is as an advanced game and rendering engine that allows you to create your game once and deploy it anywhere (without sacrificing performance on the web).

Community Involvement in the Engine's Development

Babylon.js was born as an open-source project and will always remain so. It’s actually foundational to the success of the engine. Most people don’t fully appreciate the benefits of open-source software. Babylon.js has a vibrant community of people who use the engine to develop all sorts of different creative, interactive web experiences from games to virtual events. That community is engaged in active conversation every day on the Babylon.js forum.

This community of people initially come as a means of learning Babylon.js, but what we’ve seen over the past decade is that people come to stay and start to TEACH Babylon to new users. It’s this incredibly friendly place. Babylon’s popularity has grown significantly over the years, in large part because of the fact that there’s an active community of people surrounding its usage and adoption. After all, the best possible publicity you can have is positive word of mouth or a review from someone else.

The core Babylon.js development team staffs the forum every day. So the community has developers USING Babylon.js have active daily conversations with the core team BUILDING Babylon.js. There is no better feedback mechanism than this. To have a daily conversation with your audience, hearing their thoughts and getting their feedback and input. It’s one of the most foundational reasons Babylon has found success.

But you’re probably thinking to yourself, "The community concept is great, but a community can exist around closed-source software as well." Absolutely true it can! But where open-source shines is when many of the passionate members of the community who USE Babylon.js turn into people who help BUILD Babylon.js! That’s the truly humbling and amazing story of Babylon’s open-source story."

Throughout Babylon’s 10-year journey, we’ve had close to 400 people contribute back to the Babylon.js core repository, making it better for everyone. There are countless features in Babylon.js that were developed by talented folks outside of the core development team. That’s where open-source really shines. A community of people coming together to build something together. Disney couldn’t write a story that wholesome.

Babylon.js Developer Tools and Features

I’ve already listed many of Babylon.js tools and features earlier, but I’ll go deep on a couple of really special and powerful ones that are relatively newer to Babylon.js.

The first one is the powerful and simple Node Material Editor. Let's start with the basics... A shader is an operation or program that you hand over to the GPU to perform a task for you. In games, shaders are most commonly artistic in nature, allowing you to display something visually beautiful. Shaders can be as simple as displaying a texture on an object to as advanced as real-time ocean simulations.

In the browser, the shading language that WebGL uses is called GLSL. This is a specific programming language you can use to write operations for the GPU. There’s an inherent conflict that exists here. Shaders are artistic outputs, but technical inputs….highly visual outcomes, that require highly technical input.

While not universally true, most artists don’t tend to dabble in programming, and most programmers don’t trust their own artist sensibilities. Babylon.js has an advanced shader creation tool called the Node Material Editor. This is an easy-to-use UI that requires no programming but allows you to create GLSL shaders for the GPU. In the simplest form, it reduces the technical complexity of creating shaders allowing artists to jump in and iterate faster without needing to write a single line of code. For game creation teams, this type of tool is absolutely critical. Having an artist and a developer sit together to accomplish something has its benefits, but allowing them to focus on two different problems helps you scale the capabilities of your team.

You can find examples of some scenes that were created in large part through the Node Material Editor here, here, and here.

The second feature is one that’s brand new, having just released in April with the latest version – Babylon.js 6.0. Babylon.js is the first web engine to offer Havok Physics. Over the past year, we worked closely with the brilliant team at Havok to develop a special WASM package that offers a streamlined version of their decades of experience with Physics simulations. The result is some of the most advanced physics features available in any game engine that run at unheard-of performance levels on the web.

The introduction of Havok Physics shows up to 100x performance improvement over past popular physics engines that were incorporated into Babylon.js. Working with the Havok team was an absolute joy. Combining their world-renowned expertise in Physics and our comfortableness with web technologies made this a match made in heaven. Anyone can get up and running with Havok Physics in Babylon.js right away.

Optimizing Babylon.js for Seamless Web Deployment

Let’s face it, there are a TON of wonderful game engines out there. Each one has its own advantages and disadvantages. Babylon.js is no different. If I had to summarize the journey that most game engines seem to go on, it looks something like this:

• Step 1 – make a killer game creation experience;
• Step 2 – figure out how to package/export the game up for a single platform.
• Step 3 – add packaging/exporting support for other platforms.
• Step 4 – Oh gosh… we have to think about browsers too? Oh man, this is gonna suck!
  
  

All hyperbole aside, one of the main problems that most game engines seem to face is the fact that deploying to the web is a very complicated and different process from deploying a native application. Babylon.js has gone on a different journey:

• Step 1 – create a great game creation experience for the Web.
• Step 2 – add packaging/export support for native platforms.
  
  

Because Babylon started with the web first, the web deployment capabilities of this particular game engine are (saying this humbly) industry-leading. The web is not an after-the-fact thought, it’s table stakes. When you deploy to the web from many of the most popular game engines, you end up with large package sizes and large memory footprints. That’s just a byproduct of the fact that the web has unique requirements that those engines don’t take into account until packaging/exporting.

Babylon.js being web-first takes those requirements into account providing the most efficient use of resources possible on any device. Consistent performance across a broad range of devices isn’t easy. Babylon.js has many built-in optimization systems to help developers with the process of running their scenes smoothly on as many devices as possible.

Here’s a deep look at different optimization features available to developers. But if all of that feels overwhelming, just know that when you use Babylon.js out of the box, we turn on most of these optimizations for you. The "default" is built around running Babylon.js scenes at 60 FPS on as many devices as possible.

Leveraging Babylon.js in Web Browsers and Native Applications

The holy grail of development is to write one single program and have it work everywhere. We’ve heard this general platitude for 20 years now. In fact, I’d go as far as saying we’re exhausted by it. The interesting thing is that most of the time there are tools out there that allow you to develop a single application and deploy it across many platforms, but it comes with serious limitations.

As mentioned above, when using several of the most popular game engines out there and deploying to the web, you end up with massive package sizes and memory footprints just to get a game to run, let alone run at a quality level that players will want to play. Babylon.js targets the web first to allow for the maximum amount of performance for that platform… because it’s the lowest common denominator. Our philosophy has always been to make the lowest of the scenarios work like a charm and then build up from there. If it works wonderfully on the lowest-end devices, then it’s only going to be "icing on the cake" as the machine gets better and better.

We also recognize that monetizing games on the web is complicated. It’s not as simple as putting your game on Steam. The web is still a bit "wild west" in that way. So we understand that serious game developers that are looking to make a profit with their games will want to deploy to native applications as well. Babylon.js is a developer platform. It’s built to allow developers with little experience with computer graphics to get up and running quickly, but it’s also deeply versatile.

For more experienced game developers, the Babylon platform is fully flexible. You can take the same rendering code you use for the web version and "unshackle" it from the browser to use in a native application. Which native platform you want to target is completely up to you. Where this gets interesting and even more nerdy is access to native hardware and resources.

Let’s take iOS for example. If you want to create an AR application today on iOS, Apple forces you to use ARKit – an API that’s only supported with native technologies. Apple does NOT currently offer any means of AR capabilities for its web experiences. So if you are developing an AR app for the web, that means you’re out of luck with iPhone. That’s where Babylon Native comes in. You can take the exact same application you created for the web using WebXR and utilize ARKit instead, creating a deployable iOS build of your exact same app. You could even choose to use Native UI design widgets as well.

That’s a long-winded way of saying Babylon prioritizes performance on the web and builds from there, but is deep and flexible to allow developers to deploy to any platform. It truly is that moment of allowing you to create your code once and run it anywhere. The dream we’ve all been dreaming for decades.

Babylon.js's Roadmap

We ship a new minor version of Babylon.js every week. That means that new features, improvements, and fixes are coming online into Babylon.js every week of the year. That said, we ship one new MAJOR version of Babylon.js every spring. We’re actively developing Babylon.js 7.0 right now and are aiming to get it out to the entire community in April 2024.

We are smiling more and more every day with some of the new features and improvements coming online. I won’t tease all of them here, but people can look forward to a non-destructive node-based geometry creation tool, the foundation of a code-free logic programming tool, global illumination, more advanced physics features from Havok, and a whole lot more.

We’re also very happy to announce that we now have a BRAND NEW podcast all about Babylon.js. It is dedicated to taking a look at the inner workings, discussions, and shenanigans involved in making this crazy fun engine. It’s available to listen to on Spotify and Apple Podcasts or via video on YouTube.

Jason Carter, Principal Engineering and Product Lead at Babylon.js