Our mission is to build one of the most powerful, beautiful, simple, and open web rendering engines in the world. Today, we are thrilled to announce that mission takes a monumental leap forward with the release of Babylon.js 9.0.

Babylon.js 9.0 represents our biggest and most feature-rich update yet. This is a celebration of an incredible year of new features, optimizations, and performance improvements that push the boundaries of what’s possible on the web. From groundbreaking lighting and particle systems to geospatial rendering, animation retargeting, and an all-new inspector … Babylon.js 9.0 empowers web developers everywhere to create richer, more immersive experiences than ever before. Whether you’re just beginning your Babylon journey, or you’re a graphics expert leveraging 327 simultaneous AI agents, Babylon is built for you!

Before we dive in, we want to take a moment to humbly thank the incredible community of developers, contributors, and advocates who pour their knowledge, expertise, and passion into this platform. Babylon.js would not be here without you.

So, let’s dive in and see what’s new!

Clustered Lighting

When a scene has a lot of lights, per-pixel lighting calculations can get incredibly slow. Every single pixel has to compute the lighting contribution from every single light, even if those lights aren’t actually affecting that pixel. Clustered Lighting changes all of that.

Babylon.js 9.0 introduces a powerful new Clustered Lighting system that dramatically speeds up lighting calculations by intelligently grouping lights into screen-space tiles and depth slices. At render time, each pixel only calculates lighting from the lights that actually affect it. The result? Scenes with hundreds or even thousands of lights running at buttery smooth frame rates! This system works on both WebGPU and WebGL 2, bringing next-generation lighting performance to the broadest possible audience.

Check out a demo: https://aka.ms/babylon9CLDemo

Learn more: https://aka.ms/babylon9CLDoc

Textured Area Lights

Building on the Area Lights introduced in Babylon.js 8.0, we’re excited to announce that area lights in Babylon.js 9.0 now support emission textures! This means you can use any image as a light source for your rectangular area light, enabling effects like stained glass projections, LED panel displays, or cinematic lighting setups, all with physically accurate light emission. An offline texture processing tool is also available for production workflows, and a runtime processing option is provided for quick prototyping and experimentation.

Check out a demo: https://aka.ms/babylon9TALDemo

Learn more: https://aka.ms/babylon9TALDoc

Node Particle Editor

We are absolutely thrilled to introduce the Node Particle Editor (NPE), a brand-new visual tool that lets you create complex particle systems using a powerful, non-destructive node graph. If you’re familiar with Babylon’s Node Material Editor, you’ll feel right at home! The NPE gives you complete control over every aspect of your particle systems (from emission shapes and sprite sheets to update behaviors and sub-emitters) all through an intuitive drag-and-connect interface. Whether you’re creating simple smoke effects or elaborate procedural fireworks, the Node Particle Editor makes it easy, visual, and fun.

Check out a demo: https://aka.ms/babylon9NPEDemo

Learn more: https://aka.ms/babylon9NPEDoc

Particle Flow Maps and Attractors

Want even more control over how your particles behave? Babylon.js 9.0 introduces Flow Maps, a screen-aligned texture that controls the direction and intensity of forces applied to particles based on their position on the screen. Each pixel in the flow map encodes a 3D direction vector and strength, giving you fine-grained, artistic control over particle movement. Flow maps work with both CPU and GPU particle systems, and integrate seamlessly with the new Node Particle Editor.

Babylon.js 9.0 also adds gravity attractors to the particle system toolkit. An attractor is a simple but powerful concept: define a position and a strength, and watch as particles are pulled (or pushed!) toward that point in space. Set a negative strength to create a repulsor. Attractors can be repositioned and adjusted in real time, making it easy to create dynamic, interactive particle effects like swirling vortexes, magnetic fields, or explosion shockwaves.

Check out a demo: https://aka.ms/babylon9PartFMDemo

Learn more about Particle Flow Maps: https://aka.ms/babylon9PartFMDoc

Learn more about Particle Attractors: https://aka.ms/babylon9PartAttDoc

Volumetric Lighting

Realistic light shafts streaming through fog, dust, or haze can transform a scene from flat to cinematic. Babylon.js 9.0 makes this easier than ever with a powerful new Volumetric Lighting system.

The result is stunningly realistic light scattering with configurable extinction and phase parameters that give you artistic control over how light interacts with the atmosphere. The system supports directional light sources, and takes full advantage of WebGPU compute shaders for optimal performance. WebGL 2 is also supported with graceful fallbacks. Whether you’re building a moody dungeon crawler, a foggy forest, or an atmospheric architectural visualization, Volumetric Lighting brings your scenes to life.

Check out a demo: https://aka.ms/babylon9vlDemo

Learn more: https://aka.ms/babylon9vlDoc

Frame Graph

One of the most transformative features in Babylon.js 9.0 is the Frame Graph system. Introduced as an alpha feature in 8.0, the Frame Graph is now a fully realized v1 feature that gives you complete, fine-grained control over the entire rendering pipeline.

A Frame Graph is a Directed Acyclic Graph (DAG) where each node represents a rendering task, from object culling to post-processing. You declare what resources each task needs and produces, and the system intelligently manages texture allocation, reuse, and optimization. This means substantial GPU memory savings (we’ve seen 40% or more in some cases!) and a level of rendering flexibility that was simply not possible before. You can customize and compose your own rendering pipeline visually using the Node Render Graph Editor, or programmatically through the class framework. No more opaque render black boxes!

Check out a demo: https://aka.ms/babylon9FGDemo

Learn more: https://aka.ms/babylon9FGDoc

Animation Retargeting

Animation retargeting is a game-changer for anyone working with character animations. New in Babylon.js 9.0, the retargeting system allows you to take an animation created for one character and apply it to a completely different character, even if they have different skeleton structures, bone proportions, or naming conventions. The system mathematically remaps each animated bone transform from the source skeleton to the target, compensating for differences in reference pose, bone length, and hierarchy. This means you can share an entire library of locomotion, combat, or facial animations across many characters. An interactive Animation Retargeting Tool is also available for experimentation without writing any code!

Check out a demo: https://aka.ms/babylon9ARDemo

Learn more: https://aka.ms/babylon9ARDoc

Advanced Gaussian Splat Support

Babylon.js 7.0 introduced Gaussian Splatting, and Babylon.js 9.0 takes it to the next level. This release brings a host of advanced capabilities including support for multiple file formats (.PLY, .splat, .SPZ, and Self-Organizing Gaussians .SOG/.SOGS), Triangular Splatting for opaque mesh-like rendering, shadow casting support, and the ability to combine multiple Gaussian Splat assets into a single scene with global splat sorting. You can now programmatically create, modify, and download Gaussian Splat data, and each part of a composite splat scene can be independently transformed and animated. The result? Unprecedented flexibility for working with photorealistic volumetric captures on the web. Huge shout out to Adobe for their wonderful contributions to advancing Gaussian Splat support!

Check out a demo: https://aka.ms/babylon9GSDemo

Learn more: https://aka.ms/babylon9GSDoc

Babylon.js Editor

The Babylon.js Editor has been a passion project from community member Julien Moreau Mathis for many years. His progress on this amazing tool is seriously impressive and with Babylon.js 9.0, the Babylon.js Editor takes a substantial leap forward in rendering and capability. This powerful desktop application is the ideal tool for a more artist-friendly approach to building Babylon.js experiences. Available on Windows, macOS, and Linux, the Editor provides a full scene editing environment with support for scripting, physics, asset management, and project building, all wrapped in a familiar, intuitive interface.

Editor Download (Win, Mac, Linux): https://aka.ms/babylon9EditorDemo

Learn more: https://aka.ms/babylon9EditorDoc

Inspector v2

We are excited to introduce Inspector v2, a ground-up rebuild of Babylon’s beloved debugging and inspection tool. The new Inspector features a modern, extensible architecture built on a service-oriented model with full React-based UI components. It supports overlay and inline layout modes, light and dark themes, and is fully extensible through static and dynamic extensions. Developers can now add custom panes, toolbar items, property editors, and debug views, all through a clean, well-documented API. Inspector v2 is a massive step forward for developer experience and tooling in Babylon.js.

Check out a demo: https://aka.ms/babylon9iv2Demo

Learn more: https://aka.ms/babylon9iv2Doc

Babylon Viewer Updates

The Babylon.js Lightweight Viewer, introduced in 8.0, continues to receive enhancements in 9.0. The Viewer makes it easy to embed stunning 3D content on any web page with just a few lines of HTML. This update brings greatly improved shadows, including IBL dominant light direction for shadow maps and SSAO for untextured models. Whether you need a quick product showcase or a fully interactive 3D embed, the Viewer has you covered. Another shout out to Adobe for contributing more advanced shadow rendering to the Babylon Viewer this year!

Check out a demo: https://aka.ms/babylon9VDemo

Learn more: https://aka.ms/babylon9VDoc

Playground Updates

The Babylon.js Playground (the beloved online sandbox for experimenting with Babylon.js) receives a major upgrade in 9.0 with multi-file editing, ESM module imports, and local session history. The code editor now supports a tabbed interface that lets you split your Playground into multiple files with full support for local module imports and exports between them (e.g., `import MyClass from ‘./module.ts’`). You can add, remove, rename, and reorder tabs, and designate any file as the entry point for execution. Beyond local modules, the Playground now supports importing NPM packages directly via esm.sh with version pinning, opening the door to a much richer development experience right in the browser. The Playground also now automatically saves your work to local storage, so if you hit an infinite loop, accidentally navigate away, or experience a crash, your code is never lost. Previous sessions can be restored at any time. Whether you’re prototyping a quick idea or building out a complex multi-file project, the Playground is now more powerful than ever. These fantastic and substantial playground updates were contributed to Babylon.js 9.0 by community member knervous.

Check out a demo: https://aka.ms/babylon9PGDemo

Learn more: https://aka.ms/babylon9PGDoc

Large World Rendering

When working with scenes that span large coordinates, 32-bit floating point numbers lose precision, causing visible jittering. Meshes wobble, shadows flicker, and animations stutter. Babylon.js 9.0 solves this with a comprehensive Large World Rendering / Floating Origin system. By keeping the active camera conceptually at the world origin and offsetting all geometry and shader uniforms, the math is precise and the rendering is smooth no matter how far you travel. The system also integrates with Havok physics through a multi-region architecture that distributes physics bodies across multiple simulation regions, each with its own floating origin, allowing physics to function in enormous worlds. From flight simulators to space games to geospatial applications, smooth rendering of large world coordinate scenes is now possible in Babylon.js!

Check out a demo: https://aka.ms/babylon9LWDemo

Learn more: https://aka.ms/babylon9LWDoc

Geospatial Camera

Babylon.js 9.0 introduces the all-new Geospatial Camera, designed for orbiting and navigating a spherical planet centered at world origin. It provides map-like interactions out of the box: globe-anchored drag to pan, scroll to zoom toward the cursor scaled with radius, and right-click to tilt. It comes with keyboard and touch support, configurable limits, smooth animated flights via flyToAsync, collision detection, and optional automatic clip plane adjustment based on altitude. When used alongside useLargeWorldRendering, this camera is the foundation for a whole new class of geospatial web experiences.

Check out a demo: https://aka.ms/babylon9GSCDemo

Learn more: https://aka.ms/babylon9GSCDoc

3D Tiles Support

3D Tiles is an open standard created by Cesium and adopted by the Open Geospatial Consortium (OGC) for streaming massive, heterogeneous 3D geospatial datasets. The recommended solution for rendering 3D Tiles with Babylon.js is to use the new babylonjs/renderer in NASA/AMMOS 3DTilesRendererJS (made possible thanks to Garrett Johnson), which handles tile set traversal, level-of-detail selection, and tile loading. This enables efficient visualization of enormous datasets loaded on demand based on the camera’s position. Paired with the new Geospatial Camera and useLargeWorldRendering engine option, this opens the door to using Babylon to render map data!

Check out a demo: https://aka.ms/babylon93DTDemo

Learn more: https://aka.ms/babylon93DTDoc

Physically Based Atmosphere

Babylon.js 9.0 introduces a stunning Physically Based Atmosphere addon that provides realistic sky and aerial perspective rendering. Using physically accurate Rayleigh and Mie scattering models, along with ozone absorption and multiple scattering, the atmosphere produces breathtaking sunrises, sunsets, and day-night cycles. It integrates seamlessly with PBR materials and directional lights, and supports customizable scattering parameters to create atmospheres for any planet or scene — from Earth to entirely alien worlds. The addon is available as a lightweight, opt-in package.

Check out a demo: https://aka.ms/babylon9ATMDemo

Learn more: https://aka.ms/babylon9ATMDoc

OpenPBR Support — Alpha

Babylon.js 9.0 begins implementation of OpenPBR, an open standard hosted by the Academy Software Foundation (ASWF), that defines an artist-friendly, interoperable material model. OpenPBR is designed so that materials authored with it look consistent across any platform that supports the standard. Babylon.js now maps many of the OpenPBR parameter groups (including Base, Specular, Coat, Thin-film, and more) to the existing PBR material system. This is a significant step toward industry-wide material interoperability and ensures that Babylon.js stays at the forefront of rendering standards. This is another major contribution from Adobe.

Check out a demo: https://aka.ms/babylon9OPBRDemo

Learn more: https://aka.ms/babylon9OPBRDoc

Dynamic IBL Shadows

Image-Based Lighting (IBL) has been a cornerstone of Babylon.js rendering for years, and in version 9.0, IBL gets even better with Dynamic IBL Shadows. Building on the IBL Shadow feature first contributed in Babylon.js 8.0 by Adobe, this update brings enhanced, dynamic environment shadows that respond to changes in lighting conditions in real time. Both light and shadow for the scene environment can now be approximated from a source image with greater fidelity and flexibility than ever before. Adobe continues their contribution hot-streak with this fantastic and easy-to-use new addition to image based lighting/shadowing in Babylon.js 9.0.

Check out a demo: https://aka.ms/babylon9IBLSDemo

Learn more: https://aka.ms/babylon9IBLSDoc

Signed Distance Field Text

Rendering crisp, scalable text in 3D environments has always been a challenge. Babylon.js 9.0 introduces Signed Distance Field (SDF) text rendering, a technique that produces resolution-independent, beautifully smooth text at any size or zoom level. Unlike traditional bitmap fonts that become blurry or pixelated when scaled, SDF text maintains sharp edges and clean outlines no matter how close you get. This is perfect for in-world UI, labels, signage, HUD elements, and any scenario where readable text needs to exist in 3D space.

Check out a demo: https://aka.ms/babylon9sdfDemo

Learn more: https://aka.ms/babylon9sdfDoc

Outline Renderer

Babylon.js 9.0 introduces a new Outline Renderer that makes it easy to add stylized outlines to meshes in your scene. Whether you’re building a cartoon-shaded world, highlighting selected objects, or creating a technical visualization, the Outline Renderer provides clean, customizable outlines that integrate seamlessly with the rest of the rendering pipeline. This fantastic contribution comes courtesy of community member noname0310. Not all heroes wear capes.

Check out a demo: https://aka.ms/babylon9OLDemo

Learn more: https://aka.ms/babylon9OLDoc

Nav Mesh Updates

Navigation meshes are essential for pathfinding and AI movement in games and simulations. Babylon.js 9.0 brings updates to the Nav Mesh system, improving the accuracy, performance, and ease of use of navigation mesh generation and agent pathfinding. Whether you’re building an RTS, an open-world exploration game, or an architectural walkthrough, updated nav mesh capabilities make it easier than ever to get your characters and agents moving intelligently through your scenes. Thanks to community member Roland who brings this new capability to everyone!

Check out a demo: https://aka.ms/babylon9NMDemo

Learn more: https://aka.ms/babylon9NMDoc

Audio Engine Updates

Sound is a critical part of any immersive experience, and Babylon.js 9.0 continues the evolution of the audio engine that was overhauled in 8.0. This release brings further refinements, expanded features, and improved API ergonomics aligned with modern web-audio standards. The modular audio engine makes it easier than ever to add spatial audio, ambient soundscapes, and interactive sound effects to your Babylon.js experiences.

Check out a demo: https://aka.ms/babylon9AudioDemo

Learn more: https://aka.ms/babylon9AudioDoc

3MF Exporter

Babylon.js 9.0 brings a new exporter, allowing you to export your scene geometry to the popular 3D printing format 3MF! Why are you still reading this? Go print stuff!!! This wonderful new contribution comes courtesy of community member Guillaume_Pelletier.

Learn more: https://aka.ms/babylon93MFdoc

What’s Next?

Babylon.js 9.0 is our most ambitious release yet, and we couldn’t be more excited to put it in your hands. Every feature, optimization, and tool in this release was built with one goal in mind: empowering you to create the most beautiful, performant, and interactive web experiences imaginable.

As always, Babylon.js is completely free and open source. We invite you to dive in, explore the new features, and share what you create with the community.

Welcome to Babylon.js 9.0. Let’s build something amazing together.

🚀 Babylon.js | Documentation | GitHub | Forum

Our mission is to build one of the most powerful, beautiful, simple, and open web rendering engines in the world. Today, web graphics and rendering hit the accelerator with the release of Babylon.js 8.0.

Babylon.js 8.0 represents a year of new features, optimizations, and performance improvements aimed at helping you create more compelling, interactive web experiences faster than ever.

IBL Shadows

Image-Based Lighting (IBL) is a computer graphics lighting technique that approximates environment lighting based on a source image. Originating in the visual effects world as a way to blend computer-generated effects with real photography, IBL has become a ubiquitous tool for computer graphics wizards around the world.

Babylon.js first introduced support for IBL over 8 years ago and it has quickly become one of the most commonly used features of the engine.

Today, we are absolutely thrilled to announce that our good friends at Adobe leveled up IBL in Babylon by adding shadows to the mix! Yup, that’s right, now both light and shadows for the scene environment can be approximated from a source image. Special shout out to Michael Bond at Adobe for his incredible work on this!

Check out a demo: https://aka.ms/babylon8IBLShadows

Learn more: https://aka.ms/babylon8IBLShadowsDoc

Area Lights

We are thrilled to announce that Babylon.js 8.0 brings a frequently requested feature…Area Lights! This amazing new addition to the lighting palette allows you to specify a 2D shape that emits light from it, much like a large diffuse light that you might find on a movie set! We can’t wait to see how you use this new light type to bring a new dimension to your scene!

Check out a demo: https://aka.ms/babylon8AreaLightsDemo

Learn more here: https://aka.ms/babylon8AreaLightsDoc

Node Render Graph — Alpha

One of the most powerful new features in Babylon.js 8.0 is something we call the “Node Render Graph.”

Up to now, the specific rendering pipeline for Babylon has been a black box. You tell Babylon what to render and it goes off and does it for you. There have been observables that allow you to manipulate the result after completion of a render, but the render process itself has been opaque. Well…not anymore!

With Babylon.js 8.0 you now have full control of the entire render pipeline. This means that you can fully customize and control every part of the process of how your frames are rendered on the GPU. And if that wasn’t enough, you also now have a fancy new Node Graph tool to allow you to customize your own render pipeline, without writing complex render process code! Please note that the Node Render Graph is in Alpha for you to test and discover but should not be used in production yet as it is subject to change.

Try out the editor (on desktop): Babylon.js Node Render Graph Editor

Check out a demo (on desktop): https://aka.ms/babylon8RenderGraphDemo

Learn more here: https://aka.ms/babylon8RenderGraphDoc

All New Lightweight Viewer

Babylon.js is used by tens of thousands of people and organizations across the globe to bring complex visual ideas to life on the web. Babylon.js 8.0 unlocks a new super-powered tool for the other end of the spectrum…those scenarios where you want to display a simple 3D object on a web page with zero complexity, and stunning visuals in a tiny package.

Introducing the all new Babylon.js Lightweight Viewer. This new viewer is designed to harness the same rendering beauty and power of the full engine but comes in a smaller bundle footprint and uses dynamic imports and capabilities (audio or animation for example) depending on the model that is loaded. It can be added to any web page with just a few lines of HTML and is also fully extensible. We’re excited to see it starting to gain traction and see contributions from Adobe making it even better, and we can’t wait to see how you use it in your websites!

Of course, this new Lightweight Viewer wouldn’t be complete without a super easy-to-use configurator along with it! The Viewer Configurator is a simple tool that allows you to customize the Viewer to your exact specifications and give you the simple .html properties to set so it looks the same in your website!

Play with the Configurator (on desktop): https://aka.ms/babylon8ViewerConfig

Check it out: https://aka.ms/babylon8viewerHome

Learn more here: https://aka.ms/babylon8viewerDoc

WGSL Core Engine Shaders

Babylon.js has had support for WebGPU since its inception. The core engine shaders in Babylon.js, however, have been written in GLSL (WebGL shading language) from the beginning. Because WebGPU has its own shading language (WGSL) this posed a very interesting challenge. How do you get GLSL shaders to render in WebGPU? Fortunately, there is a conversion library that’s been available. So, anyone wanting to target WebGPU with Babylon can leverage this library to convert the Babylon shaders into something WebGPU can use. The downside of this is that this conversion library is over 3MB, requiring users to double their download size for a standardBabylon.js project.

With Babylon 8.0, this problem is a thing of the past. All of the core engine shaders for Babylon.js are now available in both GLSL and WGSL. This means direct support for WebGPU right out of the box with no conversion layer, essentially making Babylon.js 2x smaller when targeting WebGPU than in the past!

Check out a demo: https://aka.ms/babylon8WGSLDemo (try switching between WebGL2 and WebGPU)

Learn more here: https://aka.ms/babylon8WGSLDoc

NME -> WGSL Support

Well, why stop at core engine shaders? Why not unlock the ability to create custom WGSL shaders using Babylon’s Node Material Editor as well!

Ok! Check!

Ability Unlocked! Let’s go Babylon 8.0!!!!!

Check out a demo (on desktop): https://aka.ms/babylon8nmeWGSL

Learn more here: https://aka.ms/babylon8nmeWGSLDoc

Overhauled Audio Engine

Babylon’s audio engine is long overdue for a tune-up and Babylon.js 8.0 swings for the fences, bringing an entirely fresh audio engine to your ears. This new engine was designed to be powerful — taking advantage of the full suite of web-audio features, modern — class names and architecture you’ve come to expect, and simple-to-use — allowing anyone to leverage these features, no matter what your experience level. For those of you who care passionately about the marriage of audio and visuals to tell a compelling story, Babylon.js 8.0 was built for you!

Check out a demo: https://aka.ms/babylon8AudioEnginev2Demo

Learn more here: https://aka.ms/babylon8AudioEnginev2Doc

Gaussian Splat Updates

Babylon.js 8.0 builds on the exciting foundation of Gaussian Splat support with some exciting new updates such as SPZ and compressed PLY formats, spherical harmonics, as well as runtime optimizations for memory footprint and CPU/GPU usage.

Check out a demo (SPZ): https://aka.ms/babylon8gsplatImrovementsDemo

Learn more here: https://aka.ms/babylon8gsplatImprovementsDoc

Havok Character Controller

With Babylon.js 8.0, we’ve continued our amazing partnership with the very talented team at Havok, this time bringing their fully featured character controller into Babylon.js. This brings a state-of-the-art character controller to your toolbox allowing you to start making your very own character-centered game with just a few lines of code!

Check out a demo: https://aka.ms/babylon8havokCCDemo

Learn more here: https://aka.ms/babylon8havokCCDoc

Smart Filters

Babylon.js 8.0 builds on our rich library of node-based creation tools with the introduction of Smart Filters and the Smart Filter Editor. This new tool allows you to create video filters, texture treatments, post-processes, you name it. If it’s a 2D visual effect, This tool is for you! Under the hood it leverages shaders in the same way you’d expect any of our GPU based tools to do, but it focuses on helping you create elaborate 2D visual treatments for web experiences. We can’t wait to see what you make with this exciting new tool!

Try it out yourself (on desktop): https://aka.ms/babylon8sfe

Check out a demo (on desktop): https://aka.ms/babylon8sfeDemo

Learn more here: https://aka.ms/babylon8sfeDoc

Environment Improvements

Babylon.js 8.0 continues to improve visual realism, leveling up the environment lighting to look closer and closer to real-time ray traced results! Another shout out to Michael Bond at Adobe for this additional great contribution.

Check out a demo: https://aka.ms/babylon8EnvImprovementsDemo

Learn more here: https://aka.ms/babylon8EnvImprovementsDoc

Node Geometry Editor Updates

Last year, Babylon.js introduced the ability to procedurally generate geometry without writing any code through the Node Geometry Editor.

With Babylon.js 8.0, Node Geometry takes a big step up with a massive list of new features including a lattice deformer, point list, clean geometry, interceptor, an aggregator, and the ability to subdivide.

Check out a demo (on desktop): https://aka.ms/babylon8ngeDemo

Learn more here: https://aka.ms/babylon8ngeDoc

Node Material Editor Debug Node

Babylon’s Node Material Editor makes it incredibly simple to create complex visual shaders without writing any code. This artist friendly tool bridges the gap between the complexity of building GPU shaders, and the way artists think and work.

Babylon.js 8.0 introduces some exciting UI improvements as well as the new incredibly useful “visual debug node.” This node allows you to see the visual output at any point in your Node Tree. You no longer have to move the output around and hook it up to different places in your graph. It’s as simple as adding debug nodes throughout your tree to see how your shader changes throughout the computation!

Check out a demo (on desktop): https://aka.ms/babylon8nmedebugnodedemo

Learn more here: https://aka.ms/babylon8nmedebugnodedoc

Improved Booleans

No, not those Booleans. True and False are just fine the way they are. We’re talking about Geometric Booleans!

Babylon.js 8.0 introduces support for the popular Manifold.js library, allowing you to create new shapes with more consistent Geometric Booleans. Or more simply put, “Finally some Booleans that look the way I expect them to look!”

Check out a demo: https://aka.ms/babylon8booleanDemo

Learn more here: https://aka.ms/babylon8booleanDoc

Updated glTF Support — KHR_materials_diffuse_transmission

Babylon.js 8.0 continues the long rich tradition of supporting every extension update to the glTF format. As glTF advances, Babylon.js is in lock-step with support for those advancements. Babylon.js 8.0 brings support for the very beautiful KHR_material_diffuse_transmission!

Check out a demo: https://aka.ms/babylon8gltfdemo

Learn more here: https://aka.ms/babylon8gltfDoc

glTF Exporter Improvements

Babylon.js introduces a host of new improvements to the glTF serializer, allowing you to export your Babylon scenes as glTF objects with support for the latest extensions and features!

Check out a demo: https://aka.ms/babylon8gltfSerializerDemo (try exporting as glTF and opening in your favorite 3D tool)

Learn more here: https://aka.ms/babylon8gltfSerializerDoc

More glTF Loader Options

Babylon.js 8.0 unlocks new loader options for .glTF objects allowing you to programmatically load your assets with pre-determined specifications, such as loading at a specific LOD (Level of Detail). These new loader options will provide new flexibility and control of how you bring assets into your Babylon.js scenes!

Check out a demo: https://aka.ms/babylon8glTFLoaderDemo

Learn more here: https://aka.ms/babylon8glTFLoaderDoc

IES Light Support

IES Lighting is a technique that describes the “shape” of a light that emits from a lamp. You can read more about it here: IES-Library. Babylon.js brings support for IES files, unlocking new ways to express dimension and lighting in your scenes!

Check out a demo: https://aka.ms/babylon8IESLightDemo (click/touch to see different IES light shapes)

Learn more here: https://aka.ms/babylon8IESLightDoc

USDZ Export

Babylon.js 8.0 allows you to export .usdz files, making it easier than ever for you to build AR experiences targeted for iOS devices!

Check out a demo: https://aka.ms/babylon8usdzDemo

Learn more here: https://aka.ms/babylon8usdzDoc

GPU Mesh Picking

Picking meshes in a scene can be an expensive feature since the CPU has to loop through every piece of geometry to find the triangle that most closely intersects the ray cast from the picking location.

Ready for some wizardry? Babylon.js 8.0 introduces the ability to pick meshes from directly from the GPU! Yup, that’s right. This means that in complex scenes, where picking is required, you can boost performance by offloading this to the GPU.

Check out a demo: https://aka.ms/babylon8gpuPickDemo

Learn more here: https://aka.ms/babylon8gpuPickDoc

GPU Bounding Box

Bounding Box calculation can be expensive, especially if you have a few animated meshes with a large number of vertices. Babylon.js 8.0 introduces the ability pass Bounding Box calculation to the GPU, freeing up valuable cycles on the CPU and improving performance for your scene.

Check out a demo: https://aka.ms/babylon8gpuBBoxDemo

Learn more here: https://aka.ms/babylon8gpuBBoxDoc

EXR Texture Support

Babylon.js 8.0 also brings support for EXR files. This feature-rich image format unlocks some new superpowers for you to use in Babylon.js. Negative pixel values for example can be used to store complex visualizations as a texture format that can now be read in Babylon.js!

Check out a demo: https://aka.ms/babylon8exrDemo

WebXR Depth Sensing

Babylon.js 8.0 brings support for a new and exciting WebXR feature called “Depth Sensing.” This feature uses depth information captured from devices to give developers the ability to overlay real world visuals “on top” of computer-generated images! You just have to see it to believe it. It feels like magic!

Check out a demo (on recent Android devices or Oculus Quest 3): https://aka.ms/babylon8webxrDSDemo

Learn more here: https://aka.ms/babylon8webxrDSDoc

A Peek Ahead

Phew! Babylon.js 8.0 is by far the platform’s biggest release to date. There’s so much goodness packed into it that it feels like you’ve been scrolling forever! Would you believe there’s even more in active development?!!! Here’s a tiny tease about a couple of things on the horizon.

glTF Interactivity Support — If you follow the advancement of the glTF file format, then you know that exciting things are coming with the interactivity workstream. We’re actively working on supporting this incredible new extension that will allow asset behaviors to travel with your assets. That means that interactivity is no longer tied to one specific creation tool or engine!

OpenPBR Support — OpenPBR is an open standard for how Physically Based Rendered materials look when rendered. Guess what’s in active development in Babylon? 😉

Tooling For Everyone — We understand that everyone who comes to the Babylon platform comes from different backgrounds and experience levels, from software engineers at the top of their game, to students and artists just beginning their computer graphics journey. We are passionate about ensuring that everyone who is interested in leveraging Babylon.js has the tools and workflows to do so. We’ll have more to share on this later this year.

Thank You

With each evolution of Babylon.js comes a revolution in web rendering technology and an overwhelming feeling of gratitude. The Babylon platform simply wouldn’t be possible without the incredible community of developers, the 500+ contributors, and the steadfast advocates that contribute their knowledge, expertise, help, and passion to this amazing technology. “Thank you” to each one of you for all that you do to help make Babylon.js one of the most powerful, beautiful, simple, and open web rendering platforms in the world.

Babylon can be used to build just about any kind of 3D or graphical web (or native!) experience. The sky is the limit! That said, a specific but common use case is viewing a single 3D model on a web page. E-commerce is a prime example, where you might just want to render an interactive 3D model for a piece of furniture, a shoe, an engine part, etc. Since this use case is so common, we want it to be super simple to achieve with Babylon, and that’s what the new Babylon Viewer is all about!

Why do we need a Viewer?

Simplicity is a core tenet of Babylon, and it’s true that it doesn’t take much code to setup a canvas, engine, and scene and load a model. But a lot more goes into making a great model viewing experience:

• Configuring the best rendering modes (such as WebGL vs. WebGPU), running an efficient render loop…
• Showing loading progress, scale normalization (when appropriate), efficiently supporting multiple formats and multiple glTF extensions…
• Setting up a skybox, using environment lighting when possible, alternate lighting configurations, shadows, tone mapping…
• Interaction hints, page scrolling vs. camera orbit on pointer input…
• Suspending/resuming camera auto orbit, points of interest, animations when resetting/changing the camera pose…
• Selecting/starting/stopping and scrubbing animations, switching between material variants…
• Entering/exiting full screen, WebXR and XR alternatives (like QuickLook)…
• And more!

A model viewer might start simple, but it can get complex quickly!

What about the “old” Babylon Viewer?

Back in 2017 (7 years ago!) a Babylon Viewer was created, was evolved over the course of a year or so, and since then has been more or less dormant. This existing Babylon Viewer made design choices that resulted in large bundles with poor tree shaking and was heavily entrenched in legacy tech (Handlebars, UMD, etc.). After some consideration, we decided it would be more efficient to just start over and replace the existing Babylon Viewer with the new one once we are close enough to feature parity.

Design Principles

The Babylon Viewer is not the only solution out there for viewing 3D models, but it is a solution that builds on top of Babylon tech, and it has its own design principles, some of which differentiate it from alternatives.

Easy to Integrate

It should be dead simple to use the Babylon Viewer to render a model in an app. For example, you can already use the new Babylon Viewer in pure html relying on ESM (no bundler) like this:

The Viewer package also includes library files that can easily be used with a bundler as well (without bringing its own copy of the Babylon packages it depends on).

The bulk of the Viewer logic and state lives in a lower pure JS layer, which is also simple to use:

Lastly, we also plan to introduce a “Viewer Configurator” tool. This will let you fully configure the Viewer through UI, see a real time preview, and get the associated code snippet to reproduce exactly what you see on screen.

Compact

The old Babylon Viewer had a very large footprint (in terms of final bundle size). This was partly because of design decisions of the old Viewer, and partly because of limitations of @babylonjs/core and @babylonjs/loaders. For the new Viewer, minimizing final bundle size is a top priority as it can reduce hosting costs and reduce the time before the first frame is rendered. Currently the new Viewer will download about 470kb (compressed) to render a basic glTF model.

We are driving size down by:

1. Introducing tooling to deeply understand the composition of a final bundle when using the Viewer as well as identifying code that is not actually executed at runtime.
2. Making architectural changes to the underlying Babylon libraries to improve tree shaking.
3. Making architectural changes to the underlying Babylon libraries to allow features and capabilities to be lazily downloaded (e.g. dynamic imports).
4. Carefully designing the new Viewer to balance a comprehensive feature set with a small footprint.

Flexible

Many apps will want more or less the same things from a model viewer, but inevitably there will be that one extra thing that is needed but is too niche to be built into the Babylon Viewer. When this happens, we don’t want the answer to be “oh well, I guess you can’t use the Babylon Viewer!” For this reason, we will not abstract away the Babylon API, but rather will formally expose it to allow for unlimited customization.

The new Babylon Viewer will also support any model format or glTF extension that Babylon itself supports, but by default the code supporting a specific model format or glTF extension will not be downloaded until a model requiring it is loaded. If you have a known set of formats and/or extensions you need to support, you can also choose to statically import them to include them in your top level bundle.

As mentioned, the Viewer includes a pure JavaScript layer so it can easily be used with your framework of choice (e.g. React or even Babylon Native). For framework specific layers (such as the HTML custom element), default UI for many features (such as animations) will be provided, but will give you full control to change the style or completely change the UI.

Modern

The old Babylon Viewer uses a lot of legacy tech. The new Babylon Viewer will be modernized in many ways:

• WebAPI — using standard Web Components / Custom Elements.
• WebGPU — full support for Babylon’s WebGPUEngine in supported browsers.
• Distribution — an ESM bundle is already provided in the NPM package and can be used directly in the browser.
• Frameworks — easy to use the Babylon Viewer in UI frameworks like React.
• XR — support for WebXR as well as QuickLook for XR scenarios.
• And more!

Easy to Use

When an app integrates the Babylon Viewer, an end user will interact with that app, and we want to do everything we can to make sure the user has a good experience. This means things like having interaction hints to guide the user in interacting with the model, always interpolating changes to the camera pose so a user is not disoriented, ensuring good performance across a wide variety of devices and 3D models, being friendly to mobile device batteries, and so on.

Want to give it a try?

The new Babylon Viewer is already available via npmjs.com in the form of a preview package. Check out the readme to get started! Please note (as described in the readme!), when installing the npm package you will need to specify the @preview tag, otherwise you will be installing the old Babylon Viewer.

Want to join the discussion?

If you have feedback or ideas, or certain features are important in your scenarios, head over to the Babylon forum to join the discussion in the Babylon Viewer announcement thread!

Ryan Tremblay | LinkedIn

https://forum.babylonjs.com/u/ryantrem

Ryan Tremblay (@ryan_w_tremblay) / X

Our initial motto was ‘One feature, one line of code,’ and we have tried to stay true to that ideal ever since.

The idea was that the user should declare their intent, and then the engine would figure out how to render it in a performant way. You want shadows and post-processes? No problem — let me schedule everything for you while optimizing the process to remove unnecessary computations.

Layers of complexity

Of course, over the years, we added so many features that can be intertwined or interdependent. This led us to build a rather complex rendering loop within the scene.render() function. The first layer for the user is to simply ignore this complexity and only declare what they want by creating objects and setting properties. The scene will then orchestrate everything to render it correctly. This is why the scene must be passed to almost all constructors, so it can keep track of the overall state.

However, as time passed, we began to have more advanced users who wanted greater control over the rendering process, which led us to introduce the second layer: booleans that can turn off certain aspects of the pipeline (such as scene.animationsEnabled to entirely remove the animation step, or mesh.alwaysSelectAsActiveMesh to skip culling for that mesh). Most parts of the rendering pipeline can be toggled on or off thanks to these switches.

To provide even more control, we then introduced the third layer: Observables. These tools enabled an incredible level of control because you can register to an event and change the state of the engine accordingly. For example, you can register for an event when a mesh is about to be rendered, disable certain features, and restore them after the mesh is rendered. This layer is really powerful, but I have to admit it isn’t the easiest to maintain since anything can happen in the observables. 😄

Here is a short example: Babylon.js Playground (babylonjs.com)

sphere.onBeforeRenderObservable.add(() => {
    engine.setColorWrite(false);
});

sphere.onAfterRenderObservable.add(() => {
    engine.setColorWrite(true);
});

The new stage we want to add will give you even more control. We want to let you create your own rendering sequence!

With great control comes more work!

With the latest version of Babylon.js, you can now override the scene.render function and provide yours:

Babylon.js Playground (babylonjs.com)

scene.customRenderFunction = () => {
  // Clear back buffer
  engine.clear(new BABYLON.Color4(0, 0.3, 0.5, 1), true, true);

  // Update view and projection matrices based on active camera
  scene.updateTransformMatrix();

  // Set viewport size
  engine.setViewport(camera.viewport);

  // Compute world matrix and render
  for (let index = 0; index < scene.meshes.length; index++) {
      const mesh = scene.meshes[index];

      mesh.computeWorldMatrix();
      mesh.directRender();
  }
}

But as you can see you have to take care of everything (clearing, setting up the states, etc…)

For instance, if some materials are transparent, it is on you to enable the correct states:

Babylon.js Playground (babylonjs.com)

scene.customRenderFunction = () => {
  // Clear back buffer
  engine.clear(new BABYLON.Color4(0, 0.3, 0.5, 1), true, true);

  // Update view and projection matrices based on active camera
  scene.updateTransformMatrix();

  // Set viewport size
  engine.setViewport(camera.viewport);

  // Compute world matrix and render
  for (let index = 0; index < scene.meshes.length; index++) {
      const mesh = scene.meshes[index];

      if (mesh.material.needAlphaBlending()) {
          engine.setAlphaMode(BABYLON.Constants.ALPHA_COMBINE);
      } else {
          engine.setAlphaMode(BABYLON.Constants.ALPHA_DISABLE);
      }

      mesh.computeWorldMatrix();
      mesh.directRender();
  }
}

And of course you will have to also render the transparent AFTER the opaque:

Babylon.js Playground (babylonjs.com)

scene.customRenderFunction = () => {
  // Clear back buffer
  engine.setAlphaMode(BABYLON.Constants.ALPHA_DISABLE);
  engine.clear(new BABYLON.Color4(0, 0.3, 0.5, 1), true, true);

  // Update view and projection matrices based on active camera
  scene.updateTransformMatrix();

  // Set viewport size
  engine.setViewport(camera.viewport);

  // Compute world matrix and render
  const transparents = [];
  
  for (let index = 0; index < scene.meshes.length; index++) {
      const mesh = scene.meshes[index];

      mesh.computeWorldMatrix();
      if (mesh.material.needAlphaBlending()) {
          transparents.push(mesh);
          continue;
          
      } else {
      }

      mesh.directRender();
  }

  engine.setAlphaMode(BABYLON.Constants.ALPHA_COMBINE);
  for (const mesh of transparents) {
      mesh.directRender();
  }
}

And this goes with every feature you will want to add. We are giving you the choice to either go with a fully functioning car or a build your own car. It is up to you! Control vs Simplicity. You can choose where to set the cursor.

One more thing

But this is not all. In the upcoming weeks, we will release the very first (and still really experimental) version of our Render Graph: A new system that will let you design your rendering pipeline by connecting nodes!

Here is a very very early sneak peek to get you excited:

David ‘Deltakosh’ Catuhe

Two Babylon Native application running the Doom Fire algorithm, one doing calculations in JavaScript and the other in C++.

Choosing a computational intensive algorithm

For this particular demo we needed a algorithm that would be simple to understand and modify but it would also be computational intensive enough to have an impact in our frame time. I have chose the DOOM fire algorithm because it is simple to understand and can give us cool visual results. This algorithm basically take intensity values and update them very frame based on the values of the pixels below minus a random value.

Doom fire algorithm.

In order for use to have a big number of things to apply the propagation to, I’ve created a cube of 80 x 80 x 80 Babylon.js Thin instances objects. We will use the Doom Fire algorithm to set the color value of each of those instances very frame.

All calculations are done using integer values for fire “intensity”, those values are later converted into color by using a table similar to the one below.

Color table for colors based on fire intensity.

The algorithm has basically 3 steps, first we set the fire at the base of the cube, then we propagate the fire up using a random number for decay and finally we convert the fire intensity into color using the color table. The rendering loop in the Babylon.js scene looks like the following:

The main part of the algorithm is the fire propagation logic, even though it is fairly simple it must run for every single instance in our scene. The goal for our comparison is to have to very similar implementation of the algorithm, one done purely in JS and the other done using C++.

C++ implementation:

JavaScript implementation:

The goal was to keep those two implementation as similar to each other as possible to allow for a fair comparison. It would not make much sense to compare the performance if both runtimes are using completely different implementations. However, there are many possible performance optimizations that could be done in either C++ and JavaScript.

Sending Data from JS to C++

To be able to send data from JS to C++ we must first register a C++ callback function in the JavaScript global scope. To do this we use the Babylon::AppRuntime class from the Babylon Native API to dispatch code to be executed by a JavaScript thread. This will also give us access to the Napi::Env object that basically holds the state of our JavaScript runtime.

Using the Napi::Env we can get access to the global scope of the JavaScript runtime and set the ‘nativeUpdate’ name to be bound to a function object. This function object will callback into C++ when executed by JavaScript.

Calling this code from JS is really simple and it behaves exactly like a standard JavaScript function.

There are other ways to send data from JS into C++. It is possible to create classes and complex objects that can be marshaled back and forth. However, using simple data structures such as integers, floats or Arrays is by far the most performant way, since the JavaScript runtime will do very little manipulation with the objects.

Problem 1 — The random number generator problem

When doing the first tests for the blog I noticed that the pure JavaScript version of this demo was running faster than the C++ counterpart!

This shows us not only how well optimized modern JavaScript engines are but also that moving heavy logic to C++ might not always lead you to better results as most people might think. Sometimes performance problems can be very tricky to track down.

After doing some investigation on the code and what could cause JavaScript to perform so well compared to C++ I was able to narrow it down to one thing: The STL random number generator vs Math.random().

The code of the fire algorithm is to update the fire propagation based on a random number. We also use random number to determine the wind contribution and the base fire intensity. Therefore, this code calls Math.random multiple times. It seems like Math.random in JavaScript is a lot faster than the random number generators provided by the C++ STL library.

Random number generator are a very complex and deep topic and can be a science on its own. There are multiple tradeoffs when choosing a random number generation algorithm and sometimes the quality of the random distribution can compromise speed. It is very possible that the C++ STL have chosen a more precise but slower algorithm compared to the one used by JavaScript, but I haven’t done further investigations on this to know the exact reason.

To account for that, I took the implementation of a RandomNumberGenerator class from DirectX 12 Mini engine project that allows you to choose if you want to use a STL version or a custom “faster” algorithm for the random number. By setting the USE_STL define in Random.h you can switch between the two approaches and see how that impacts the overall performance.

One important lesson to take from this is that performance usually comes with tradeoffs, it is not because something is implemented using language A that it is going to faster or slower than language B. Modern compilers and interpreters are very smart and can optimize your code in non-obvious ways. So the first thing about is to always measure, and don’t just assume things are fast or slow.

Problem 2 -JIT vs no JIT

Modern JavaScript engine have a technology called Just In Time Compilation (JIT). This technology allows JavaScript to be compiled to platform specific assembly code during first execution and then be reused during code execution. This can vastly improve the performance of JavaScript since this process only happens once and after that the code will have performance similar to native code.

Knowing how to make your code JIT properly is one the most important performance optimizations web developers can do to speed up their code.

However, some platforms do not allow JIT (mainly iOS). This is very important to be considered since JavaScript will probably run much slower that way.

Demo running with no JIT but computation happens in JavaScript.

For these cases it is even more important to consider moving heavy tasks to C++ since they will not be affected by the fact that iOS does not support JIT.

Demo running with no JIT but computation happens in C++.

Final considerations

Hopefully this blog was able to show a very simple example on how C++ and JavaScript can work together in a Babylon Native project to deliver the best performance to users in each scenario. Even though this example was simple I think I was able to show how performance is not always obvious and require careful consideration about technologies and approaches.

The project can be found at the following Github repo: SergioRZMasson/BabylonNativeDoomFireDemo: Demo showing cases where computation can be formed by JS vs C++ in a Babylon Native project. (github.com)

Also, for those who want to view it on the web, I’ve also created a Babylon.js Playground: DOOM Fire 3D | Babylon.js Playground (babylonjs.com)

References

Used C++ Random number generator: DirectX-Graphics-Samples/MiniEngine/Core/Math/Random.h at master · microsoft/DirectX-Graphics-Samples (github.com)

Doom Fire algorithm: filipedeschamps/doom-fire-algorithm: Playground for the fire effect from DOOM. Really simple algorithm and all experiments are welcome! (github.com)

Sergio R. Z. Masson — Babylon.js Team

Sergio Ricardo Zerbetto Masson (@ZerbettoMasson) / Twitter

Hey everyone!

I’m Alex Huber, the newest Software Engineer on the Babylon team. After graduating from the University of Florida, I’m happy to be returning to the team after a rewarding internship last summer. I thought I’d share a bit about my journey here — how an early obsession with ice cream led me to explore graphics, the learning curve I faced as a newbie, and what excites me about joining the team.

An Unlikely Early Influence

My interest in graphics started with a simple love for frozen treats.

When I was 8, I built my first website: the “Super Ice Cream Fanclub”. It was a blog and forum where my classmates and I could debate the all-important question, “What’s your favorite ice cream flavor?” I spent an afternoon spreading the word in my computer lab class, thrilled at the idea of creating a secret social space to chat with my classmates. My teacher? Not so thrilled.

While the website was a fun start, I always felt something was missing. Text on a forum isn’t the most expressive medium. Could I somehow make this social space more interactive?

At 10, I discovered I could achieve this by hosting a 3D game on Roblox. Graduating from my ice cream obsession, I moved onto smoothies — my new frozen treat of choice — and built a smoothie parlor game for my friends and me to hang out in. It was the first time I had coded anything, and I was hooked.

The Road to Babylon

Over the next decade, I got to watch in real-time as 3D worlds became increasingly more beautiful, thanks to advancements in graphics. I realized I wanted to be part of this evolution. After starting my Computer Science degree, and a couple internships at Premera Blue Cross and NASA, I finally got the chance to do so.

I remember casually telling my Microsoft interviewer, “I’d love to work in something near graphics, if possible”. So, when I got the news that I’d be interning with the Babylon.js team, I was over the moon.

I’d been tinkering with games for a decade, taken a few courses on game development, and knew enough linear algebra to make transformation matrices do what I want. I felt reasonably prepared for the challenge ahead… but I soon realized there was a lot more to learn.

The Internship

Do you ever wonder what it’s like for small-town football players to join the NFL? I didn’t. At least not until I joined the Babylon team.

These guys are experts at their craft. At first, I struggled to keep up with the technical discussions happening around me. Every question I had seemed to lead to 10 more. I couldn’t tell whether this feeling was normal, or if the answers I needed were somewhere in a textbook I’d long forgotten. (Spoiler alert: they weren’t.)

To my relief, the team proved to be the most approachable group of all-stars I could’ve hoped for. They love what they do, and in the spirit of Babylon’s open-source principles, they’re eager to share their knowledge with the world. They get how complicated this domain can be. So, faced with my dozens of questions, the team took the time to help me understand the complex nature of graphics. I couldn’t be more grateful.

That summer, I collaborated with my new teammates to create the MeshDebugPluginMaterial, a debugging tool for models that could power the visualizations behind Window’s 3D Viewer. I went from asking things like, “Isn’t a shader the thing that gives some nice filters to the final image?” to “How can we get geometry information in a fragment shader without geometry shaders or extra passes?” (Shout-out to Alexis who found this solution, and even wrote a post about it!)

Back to School and Back to Babylon

I left my internship determined to continue working with graphics. Armed with new “known unknowns” from my time in Babylon, I set out to make the most of my final year in school. I talked my way into a graduate-level graphics course and finished top of the class. I made a couple more small games; this time, with much more mastery over the game engine, thanks to Babylon. And, for my senior project, I teamed up with classmates to build a simple 2D game engine/editor.

When I was offered the chance to return to the Babylon team full-time, I jumped at the opportunity. There’s something truly inspiring about this team and community that I haven’t seen elsewhere. What sets them apart is how deeply they live the open-source values they stand by. Calling it a “culture of collaboration” isn’t just me throwing around buzzwords — it’s how they operate, every day. They’re not just building a product; they’re fostering a community, actively engaging with users, and constantly learning from them.

Each team member brings a specialized skill set to the table, and they know exactly when to lean on each other’s expertise. Whether it’s taking on a complex shader problem, exploring new rendering techniques, or fine-tuning user experience design, no one works in isolation. That’s what makes the Babylon team so strong.

I’m SO excited to be joining this incredible group of people, and I can’t wait to see what we’ll create together next. In the meantime, see you all on the forum!

Alex C. Huber — Babylon.js Team

Alex Cornide Huber (@alexchuber) / X

Hi Babylon Community!

My name is Kevin Brown, and I’m super excited to have recently joined the amazing Babylon team! As I’m settling in and joining more discussions on the forum, I wanted to take this chance to introduce myself to all of you.

My Path So Far…

I joined Microsoft a little more than 20 years ago and, as you’d imagine, during that time I’ve worked on a wide variety of projects.

I started working on Exchange Server, on UI for administrators to more easily configure new domains and then on the user facing UI of Outlook Web Access.

Later I decided to join the Microsoft Security Response Center (MSRC) where I got to dive deep into how attackers would exploit security issues and how to defend against them. When Windows Phone 7 came out, I was inspired by its UI and moved over there to work on the Photos and Camera apps and underlying services that gave camera access to all apps.

My work eventually evolved into the Video Editor that was part of the Photos app in Windows 10. From there I moved into the Microsoft Stream team, where I worked until just recently on building a feature-rich and performant web-based video player for Microsoft 365.

And Now, Babylon!

My interest in graphics goes way back to my early days of coding. My earliest programs were text-based (the earliest program I remember writing was a horse racing game that used &s to represent the horses!). Later in high school I started scratching the surface of graphics, writing an animated flame effect using a pixel blurring approach (inspired by Winamp visualizers and probably written in Pascal!), and then learning DirectX so I could write a Tetris-like game (the rule of the computer lab was no games — unless you wrote them 😊).

Throughout my career I’ve had opportunities to dive deep into areas that I’d long be interested in but hadn’t been able to explore much yet, like my security work in the MSRC. Now I’m thrilled to go deep into another one of those areas — graphics — on an amazing team with an outstanding culture, and to be a part of this fabulous community!

What’s Next

Given my recent focus on web-based video, my first project is looking into how we can use Babylon (and the GPU) to make video more engaging, personalized, and even interactive. I’m looking forward to sharing more with all of you in the future! I’m also the new owner of the input system for Babylon, so feel free to tag me in the forum (@amoebachant) for anything input related.

I’m having a blast diving into this awesome tech, looking forward to seeing you all on the forum, and want to thank all of you for making this such a fantastic community!

Thanks!

-Kevin Brown

Wait, AmoebaChant?

P.S. You may be wondering, what does AmoebaChant mean? One of the highlights of my teen years was running a Wildcat! BBS in the 90s, where I had a ton of fun building ANSI graphics and animations.

I wanted to pick a name for the board that would be near the top of the alphabetized BBS lists, not be too specific about what the board focused on, and odd enough to catch the eye, and so the name AmoebaChant was born!

A sneak peek into the planned features and enhancements

Hello, fellow Babylonians! I hope you are having a great time creating amazing 3D scenes and games with Babylon.js. If you are like me, you probably use the Babylon.js playground a lot, to test your ideas, share your code, and learn from others. The playground is a wonderful tool that lets you write and run Babylon.js code in your browser, without any setup or installation. It is fast, simple, and fun!

The playground hasn’t changed in a while. Yes, we had some awesome new features, and new editors joining the party, but the playground itself, its editor and the way we organize code stayed roughly the same for the last few years.

I have been working on a list of features and enhancements for the playground, and I would love to get your feedback and suggestions. Please note that these are not final or guaranteed features, just some ideas that I think would improve the playground experience. I believe all of these features are implementable — nothing is rocket science. It will just take time 😊

1. Implement a new URL schema

No more double-hash (#) in the address bar, which was confusing and didn’t work well on some browsers (looking at you, Safari!). Instead, you will see a simple URL schema that contains the playground ID and the version number.

Of course, we will maintain the wonderful advantages of using hashes — no need to reload the page to update the code or move from one snippet to the other. And of course, we will maintain backwards-compatibility with existing hashes.

2. Add the ability to add external javascript resources from npm as part of the stored playground

At the moment, it is not the easiest task to add new external dependencies to your playground. You had to manually add the script element every time you opened or shared a playground. This could lead to a dependency being reloaded every time we run the playground, which doesn’t work well with frameworks that have side-effects.

With this change, you will be able to add external JavaScript resources from npm as part of the stored playground, and they will be automatically loaded when you run or share the playground. This means you can use any npm package that you want, without any hassle. You can use any library that you like, and they will be available in the playground. How cool is that?

3. Update Monaco to the latest version

Monaco is the awesome code editor that powers the playground, and it is also used by VS Code, one of the most popular code editors in the world. Monaco provides a great editing experience, with features like syntax highlighting, auto-completion, code formatting, and more. However, the playground is using an old version of monaco, which was missing some of the latest features and improvements.

Updating Monaco will open the horizon to a set of new features.

4. Add experimental ESM support, instead of only supporting UMD

ESM, or ECMAScript modules, are the standard way of importing and exporting modules in JavaScript. They are supported by most modern browsers, and they offer many advantages over the traditional UMD, or Universal Module Definition, format. ESM allows for dynamic imports, which means loading modules on demand, instead of loading everything upfront. ESM is the future of JavaScript, and I want the playground to be ready for it. That’s why I want to add experimental ESM support, instead of only supporting UMD. This means you will be able to use the import and export keywords in the playground, and they will work as expected. You will be able to use dynamic imports, and they will be resolved at runtime.

The feature, at least at the beginning, will be experimental. We still need to see how we provide the es6 packages in order to use them in the playground.

5. Allow adding more than one file

Sometimes, you may want to organize your code into multiple files, instead of putting everything in one big file. This can make your code more readable, maintainable, and reusable. However, until now, the playground only allowed you to have one file, which was limiting and frustrating. Well, not anymore. You will be able to add more than one file to your playground, and they will be saved and loaded as part of the playground snippet. You can also rename, delete, or reorder your files, as you wish. You can also import and export modules between your files, using either UMD or ESM syntax. This will give you more flexibility and control over your code, and allow you to create more complex and modular playgrounds.

6. Improve the support for the babylon versioning system.

Babylon.js is a fast-moving and constantly evolving framework, which means that new features and improvements are added regularly. However, this also means that sometimes, things may change or break between different versions of the framework. That’s why it is important to be able to check your playground with different versions of Babylon.js, and see how they behave. Until now, you could only choose between the latest stable version, the last major version, or a custom version of Babylon.js, which was not very convenient or intuitive. That’s why I want to improve the support for the Babylon.js versioning system, and make it easier to check any playground with any version of the framework. With this feature, you will be able to choose from a list of all the available versions of Babylon.js, from the oldest to the newest. You can also type in a specific version number, and it will be loaded automatically. This will make it easier to test your playground with different versions of Babylon.js, and see how they affect your code and scene.

7. Allow defining the needed dependencies, instead of loading all of them.

Babylon.js is a very rich and powerful framework, that offers many features and capabilities. However, not all of them are needed for every playground, and some of them require external dependencies, such as physics engines, mesh decimation, or polygon triangulation. Until now, the playground was loading all of these dependencies by default, which was unnecessary and wasteful. This feature will allow you to set the dependencies you need and only load them on runtime. This will make your playground load faster, and use less bandwidth and memory. You will also have more control over your playground, and avoid potential conflicts or errors with unwanted dependencies.

8. Full TypeScript support, including tsconfig adjustment (related to the updated monaco)

TypeScript can help you write more robust and reliable code, by catching errors and bugs at compile time, instead of runtime. TypeScript can also provide better tooling and documentation, by using type annotations and declarations. However, until now, the playground did only partly support TypeScript. I want to add full TypeScript support, hopefully including tsconfig adjustment, to the playground. This is connected to the updated monaco version and the TypeScript abilities of the editor. Now, you will be able to write and run TypeScript code in the playground, and enjoy all the benefits of TypeScript. You will also be able to adjust the tsconfig options, such as strict mode, target, module, and more. This will make your playground more powerful and versatile, and allow you to use TypeScript with Babylon.js.

9. Allow changing the snippet server’s base URL — to use your own snippet server with the playground

The snippet server is the service that stores and loads the playgrounds, using a unique ID and a version number. The snippet server is hosted by Babylon.js, and it is free and open for everyone to use. However, sometimes, you may want to use your own snippet server, for various reasons. For example, you may want to have more control over your playgrounds, or you may want to use a different storage or database system. At its current state, the playground does not allow you to change the snippet server’s base URL. That’s why I want to add the option to change the snippet server’s base URL, and use your own snippet server with the playground. This will make your playground more flexible and customizable, and allow you to use your own snippet server with The Babylon.js ecosystem. Our own implementation of the snippet server is available on GitHub — BabylonJS/SnippetServerExpress, so you will be able to have your own version of it. You can also make any modifications you want, such as adding authentications.

10. Allow users to create a fork of an existing playground

One of the best things about the playground is that you can share your playgrounds with others, and learn from their playgrounds. However, until now, anyone who had the playground URL could generate new versions of the same playground, which could be confusing at times. The feature I want to add is a forking mechanism for existing playgrounds. If you open someone else’s playground you will not be able to save it with a new version number, but fork it and get your own snippet ID. Only the creator of the original playground will be able to generate new versions of the same playground, and no one else. This will make your playground more secure and organized, and avoid unwanted changes or conflicts. It is still unclear how we will deal with user detection. One thing for sure — we don’t want to add user authentication. So it will probably be a generated unique key stored locally.

11. Improve the export/download process

At the moment, downloading a playground provides you with a single HTML file, binary dependencies (like textures) and nothing else. We didn’t have a problem with that for quite some time, but just like the playground, the HTML file contains every single Babylon.js package. The method we are currently using will certainly not work with all of the changes I am suggesting. So let’s improve that!

The new export feature will provide everything needed, based on the user’s input — dependencies, assets, different files, everything needed in one zip file. This method will also support ESM! And optionally we could generate a project that you can open and work on locally — with everything needed, like package.json, tsconfig and more. So you could start your work in the playground, and once you are happy with the prototype, you can move to local development and really bring the experience to life!

And that’s it for now.

There are many other improvements that can be done to the playground. This was an overview of what I think are important steps forward to make the playground the best experience possible for the Babylon.js community.

Got a suggestion? a comment? think we are missing a whole different set of features? Let me know what you think!

Interpolation is a cornerstone of computer science, particularly in rendering. Whether it’s triangle rasterization, shaders, image magnification, or skeletal animation, linear interpolation plays a crucial role.
In this blog post, I’ll demonstrate some practical uses of interpolation that I incorporate into all my playgrounds and demos. You don’t need to be a math expert; with just a few lines of code, you can significantly enhance your animations, controls, cameras, and more.

Interpolation smooth value over time

Linear interpolation exposed above is useful when you know the start,end value and the time it takes to interpolate. This is an easy way to smooth animation over time for example:
https://playground.babylonjs.com/#EU3YIP

This technique is incredibly useful for smooth interpolation of camera movements, including targeting, aiming, and angle adjustments. You can find it applied in the camera controller featured in this blog post.

The formula is simple:

value = value + (target - value) * factor;

Here, the factor ranges between 0 and 1. The closer the factor is to 1, the faster the value will converge to the target.

Framerate Independent

This simple interpolation has a big drawback: It’s dependent of the framerate. Experience will be different depending on the framerate. As the code is executed once per frame, having more frames per second will make the effect run faster or slower. But with just a small update, it’s possible to make it framerate independent.

With https://playground.babylonjs.com/#T6KNCC#4 you can test the influence of the display frequency with and without framerate independent computation.

The interpolation code becomes:

value = value + (target - value) * (1-Math.pow(2, -frequency / factor));

It’s just a tiny change to be sure to have the same experience with different device configurations.

Acceleration and end value

With constant speed (zero acceleration), a moving entity can be seen as an interpolation between two locations. Imagine the ISS orbiting around the earth at constant speed.
But what about a bit more complexity with an acceleration? Let’s say we are coding a car simulator and need precise control on its acceleration curve. You end up with some code like this:

speed += acceleration * deltaTime;
position += speed * deltaTime;

Acceleration value is 1 when going faster, and -1 when braking. Values, 1 and -1 can be tweaked by car to make cars different. It’s fine but if acceleration is always the same, then you’ll get infinite speed. The trick here is to interpolate acceleration between (1 = full acceleration to 0 = can’t accelerate more). As an analogy, a car will have maximum acceleration when its speed is 0 and no acceleration with it reaches its maximum speed.

Resulting code:

acceleration = maximumAcceleration * (1 - speed / maximumSpeed);
speed += acceleration * deltaTime;
position += speed * deltaTime;

Another use case for this is the jump control for characters. For a game featuring characters like Celeste or Mario, you’ll need very precise control on jump height, jump distance, etc. This can be evaluated with this Playground : https://playground.babylonjs.com/#VNFPQL#3

In this jump example, speed is interpolated based on height but the principle is the same.

Linear Interpolation in Babylon.js

Helper function are available in Babylon math class. Like Lerp method in Vector3 https://doc.babylonjs.com/typedoc/classes/BABYLON.Vector3#Lerp

The animation feature provide ways to animate and interpolate object position easily : https://doc.babylonjs.com/features/featuresDeepDive/animation/animation_design

This is just 2 examples of Liner interpolation in Babylon. Check shader code for example. Any use of mix function is an interpolation. Each triangle rendered is using hardware interpolation on the GPU and so on.

Takeaways

Linear interpolation is ubiquitous in 3D experiences. Understanding and utilizing it extensively can significantly enhance your projects. However, it’s crucial to consider the influence of time on interpolation. With a few mathematical tricks and analogies, you’ll be able to create incredible and enjoyable experiences.

Here are a few of my experiences in the 3D and XR space where I first got the chance to work with some of the fantastic members of the Babylon team:

• Flight Sim and Train Sim (with Gary!)
• Skype for HoloLens (with Gary, Jason, and Patrick!)
• 3D for Everyone (with Gary, Jason, Patrick, David, Sebastien, and Cedric!)

More recently (hard to believe it started over 4 years ago!), I worked closely with the Babylon Native team building out the XR support in Babylon Native as well as building out the full Babylon React Native layer on top. This was motivated by need for a web tech based 3D/XR platform that was portable across browsers and mobile devices, and this was the topic of my first actual post on the Babylon blog.

This partnership was truly an amazing experience, and gave me the opportunity to see first hand the power of the Babylon platform as well as the passion of the Babylon team and the incredible culture they have built. I was super excited when I had the chance to join the team a couple months ago!

What’s Next?

As a new member of the team, there are a few areas I’m thinking about and that I hope to work on.

Babylon + AI: Generative AI is growing like wild fire, and there are a ton of scenarios where a rendering engine (including 3D) can help support this growth. A few that we have already started exploring or intend to explore are:

• Visual effects for interactive image generation
• 3D scene templates with generated non-3D media elements
• Full 3D model generation
• 3D AI embodiments

Babylon Viewer: Babylon.js is a very powerful platform that can enable an extremely broad spectrum of rendering and 3D experiences. Viewing 3D models is a very specific but very common use case, and the existing Babylon Viewer aims to make this use case simple. That said, the Babylon Viewer is a bit aged at this point and could use a rework. Here are some of the principals we are thinking about when considering a redesign of the viewer:

• Easy to integrate — bringing a fully featured model viewer into your app should be dead simple, at either the JS layer or within your UI framework of choice.
• Compact — if you don’t need support for all the model formats or features Babylon.js offers, you shouldn’t pay the bundle cost for them. This will require some architectural changes to Babylon.js.
• Flexible — the viewer should make the most common scenarios simple, but should also allow any customization by exposing the underlying Babylon.js API, not abstracting it away.
• Modern — the viewer should integrate with modern Web API and web frameworks, it should support modern distribution models, and it should support modern rendering techniques.
• Easy to use — interacting with the viewer should be very intuitive for end users, and knobs should be provided to ensure good performance across a range of devices.

Extensible Sandbox: Often the most successful tools are those with an extensibility model (e.g. plugins that can extend the default set of features). Consider Visual Studio Code as an example. I probably use 0.1% of the full functionality available in Visual Studio Code. This is because I have a very specific set of technologies, tools, and workflows that I use in my job. Imagine if Visual Studio Code tried to just support every single possible developer scenario out of the box. It wouldn’t scale. You’d end up with a 1TB tool with a million buttons! The same idea can be applied to 3D content and Babylon.js based workflows, and the Sandbox could be the entry point. I’ve been doing some prototyping and pitching some ideas, and here are some of the top level thoughts:

• Extension feeds — the Babylon.js team could provide an “official” extensions feed, but there could also be a public community feed governed by the community (no reviews needed from the Babylon team), or even private organization specific feeds to integrate with their own existing workflows.
• Tooling — some lightweight tooling would make it easy to develop and publish new extensions.
• Experiences — the initial “experience” could be all about viewing 3D models (hopefully using a new Babylon Viewer!), just like the Sandbox is today. But any number of additional experiences could be supported, and other Babylon.js tools could be rolled in. For example, NME could be a new “experience” and itself would be extensible (with new node types, for example).
• Apps — the extensible Sandbox could be installed as an app, leveraging PWA, WebViews, Electron, or perhaps even Babylon Native.

I’d love to hear any feedback on these ideas, and hope to write about them each in more depth in the future!

https://www.linkedin.com/in/ryantrem

ryantrem

Ryan Tremblay (@ryan_w_tremblay) / X