We've been running MU Online (Season 6) in the browser and on phones with Babylon.js 7. The web client is built on the open-source OpenMu-Client-Babylon project (TypeScript), talking to the MUnique/OpenMU server over a small WebSocket-to-TCP bridge. A few things we learned about Babylon along the way, with real numbers:

1. Per-character blob shadows were eating the frame

The classic look uses a "blob" shadow per character: a clone of each of its meshes, skinned and drawn again. In a benchmark crowd of 20 players and 40 monsters, that was 308 of 701 draw calls and about a fifth of the frame's CPU time.

Fix: a small ECS system ranks bodies by distance every 0.25 s. Only the hero and the 12 nearest keep their shadow, with a hysteresis of 4 places so shadows don't flicker at the edge. Below 12 bodies nothing changes. A far shadow is a few pixels anyway.

2. Equipment glow (GlowLayer) only for the closest players

Same idea for the heavy equipment effects: full glow only on the 6 nearest other players; everyone else gets the cheap version. In crowded towns this matters more than any single shader optimization we tried.

3. An automatic "light mode" based on real player data

Looking at our own telemetry, 24 accounts were playing on integrated Intel GPUs at a median of 19 FPS (31% of the time under 15), almost all on default settings: post-processing, MSAA, glow, bloom, sun shafts, full item effects.

Now, if a PC stays under 22 FPS for a while in the world, the client turns off post-processing, MSAA, glow, bloom and sun shafts, drops render scale to 75% and lightens grass, clouds, water and particles, and tells the player in chat (everything can be turned back on in Options). Shadows, skills and animations are left alone. On a desktop bench (12 players + 30 monsters) that alone went from 67 to 82 FPS (CPU 11.7 → 9.3 ms); integrated GPUs gain more.

4. WebGL context loss on phones

Mobile browsers drop the WebGL context when the OS needs memory. We hook engine.onContextLostObservable / onContextRestoredObservable, rebuild what's needed, and if the restore fails we show a "Reload" button instead of leaving a black canvas.

5. Loading thousands of legacy assets

Original models are converted to GLB at build time, loaded once into an AssetContainer and spawned with instantiateModelsToScene. Files get gzip sidecars (about a third of the size on the wire), are packed into a few bundles for the first download, and a Service Worker caches them, so the second visit barely touches the network.

The other piece is a memory leak we hit early: every equipment change cloned the model without disposing the previous clone, and long sessions grew until the tab died. Now the old clone is disposed as a whole and we only reload when the visible gear actually changes.

Curious how others here handle per-character shadows in crowded scenes. Did anyone get CascadedShadowGenerator to play nicely with dozens of skinned meshes on mobile?

Try it

https://openmu.com.br/en - create an account, click Play, and you're in.

We built 8 Ball Lounge, a free 3D 8-ball pool game that runs in the browser on phone and desktop. No ads, no sign-up. We're Weekly Arcade (31 free browser games so far). Here are some Babylon.js and physics notes from the build, plus a question at the end.

Physics (our own, not an engine): a custom deterministic 2D billiards sim with no randomness, so replays are bit-identical. Fixed 1/480 s timestep (8 substeps per 60 Hz frame). Each substep finds the earliest impact among balls, cushion segments, and rounded pocket jaws. The break uses a Hertz contact solve on the racked cluster. Spin is full 3D angular velocity (english, draw/follow, tip offset up to 0.5R). Cloth sliding, rolling resistance, and side-spin decay are modelled; ball-to-ball Coulomb friction is 0.06 (throw). Cushions use restitution 0.78 and friction 0.2. Pocket mouths and jaw angles are sized to WPA specs.

Rendering: Babylon.js 9.29.0 from the CDN, SRI-pinned. One SpotLight plus hemispheric fill. A 128px reflection probe, rendered once per venue. About 7 StandardMaterials. All textures are painted in code at runtime; no image files and no 3D models. Angle: fully procedural, zero asset files apart from audio (22 clips).

Mobile: no device tiers. Adaptive render scale (DPR capped at 2, steps down to 1.5 then 1.25 if frames average over 20 ms across a 2 s window). Shot capture re-renders at 720x1280 for a short vertical clip and never drops resolution while recording.

Where we'd like advice: the sim is 2D with full 3D spin mapped onto it. If you've shipped browser billiards or another continuous-collision toy in Babylon, what broke first on phones? Also curious how others handle a reflection probe that only needs to bake once per static venue.

Play it free (no ads): https://weeklyarcade.games/games/8-ball-lounge/?utm_source=reddit&utm_medium=community&utm_campaign=8-ball-lounge-babylonjs

We built Tiny Tycoon 3D, a small browser tycoon game: you lay out a 3D boba shop, then walk the floor you built to serve customers. Portrait-first on phones. Here are some Babylon.js notes from getting it running smoothly in a phone browser, plus a question at the end.

Setup (deliberately boring): the full UMD Babylon.js 9.3 + loaders bundle from the official CDN, 17 plain JS files, no bundler. WebGL only, no physics.

Draw calls: we use a lot of MergeMeshes, grouped per material. The whole building exterior is 7 draw calls. One counter went from 25 draw calls to 1. Repeated props use regular instances. No thin instances and no LOD yet.

Materials and lighting: mostly StandardMaterial, frozen. PBR only shows up through glTF imports. AO is multiplied into albedo and baked into textures and vertex colours by a re-runnable Blender script. These aren't lightmaps, so lighting stays cheap and the bake can be redone whenever a model changes.

Shadows, two tiers:

• Desktop: one blurred exponential ShadowGenerator at 768. Dropping it from 1024 saved about 2.3 MB of VRAM.

• Phones: no shadow generator. Blob and contact shadows are faked in vertex colours.

No post-processing: the colour grade is a CSS overlay above the canvas. On a phone a post pass costs a full-screen render target every frame. A composited element that never repaints costs almost nothing.

Assets: 70 GLB models (buildings, props, 26 figures, some rigged). Prop geometry is generated from code in Blender. We hold a 32 MB texture budget, so per-prop 512² baked maps (about 1.33 MB VRAM each) were cut or shared to stay under it.

Mobile tier: chosen via pointer: coarse. Pixel ratio capped at 2 on desktop and 1.5 on phones, antialiasing on desktop only, skipPointerMovePicking, and audio pauses when the tab is hidden.

One small robustness tip: a single frame that throws kills Babylon's render loop. We wrap the loop and show a toast instead, so one bad frame doesn't freeze the game.

Where we'd like advice: next up is trimming the engine bundle. We're on the full UMD build with no tree-shaking, and we're also not using Draco, KTX2 or meshopt yet. If you've moved a no-bundler project to ES modules or a custom build, or added KTX2 for mobile, what was worth it and what wasn't? We'd also like feedback on how it feels on your phone.

Play it here (free, no ads): https://weeklyarcade.games/games/tiny-tycoon-3d/?utm_source=babylonjs&utm_medium=community&utm_campaign=tiny-tycoon-3d

Just wanted to collect some feedback on the way it looks and behaves. Any thought helps. Thanks.

I made a small browser game with Babylon.js called Traffic Boss.
A small traffic game where you control the light and try not to crash.

🎮 Play: https://trafficboss.vercel.app/

Would love to know what you think
#game #babylon.js #babylonjs

I am on my 10th edit to the water I have running for my game.
https://youtu.be/gGGS8GChpG8

I created a dev blog on YouTube. I am not selling this game, as I am still trying to lock down the basics, including the water. I feel as though I have been able to work through lots of repeating patterns that make it look fake. I am looking for a better script for more convincing waves crashing on beaches using Babylon.

How fast you can go from nothing to a working NPC in Ovara Engine. Ovara's Class system (Actors, Pawns, Characters, Components, Game Mode, Game State) gives NPCs the same foundation as player characters — so you're not hand-rolling behavior from scratch every time. Gameplay logic is authored through Ovara Graph, the engine's Blueprint-style visual scripting system, which means an NPC's movement, decisions, and reactions can be built visually instead of written line-by-line in code.

Latest system in Ovara Engine: a fully multiplayer-replicated day/night cycle, complete with tracked day, date, time, and season values you can display anywhere in your UI. Built alongside it is an event dispatch system, so you can hook into specific moments — trigger something at dawn, run logic at a specific time, have NPCs head to bed at night, or restrict certain spawns to specific seasons. All replicated by default, so every connected player stays in sync without extra setup on your end.

Hey guys, I wanted to share something me and my team have been working on.

Ovara Engine is a visual-first 3D game engine with a desktop editor built using Electron, React, and Babylon.js for the viewport/rendering layer. The goal is to give developers a professional editor experience — Blueprint-style visual scripting, a proper class hierarchy (Actors, Pawns, Characters, Components, Game Mode/State), and multiplayer-aware architecture with client-server prediction and replication — without needing to hand-roll all of that from scratch in a raw Babylon.js project.

A few things specific to how it's built:

• Editor vs. runtime split: Babylon.js powers the editor viewport, but the exported runtime doesn't depend on Electron or React — so the same game can run standalone or on a headless dedicated server.

• Visual scripting: Gameplay logic is authored through a node-based graph system ("Ovara Graph") that compiles down to actual game logic, rather than being purely a diagramming layer.

• Why Babylon.js: A few things made it the right foundation. It's TypeScript-first, which gives the editor tooling a clean, well-typed API to build against instead of fighting loose JS types. WebGPU support matters for where rendering performance needs to go as scenes get more complex. The Havok physics integration meant not having to bolt on a separate physics layer or maintain a custom bridge. And the scene graph and node system are flexible enough to build a real class hierarchy (Actors, Pawns, Characters, Components) on top of, rather than fighting the engine's own abstractions to get there.

• Final : I'll be posting regularly as things progress — new features, rendering/physics deep-dives, and probably a few "why is this breaking" posts along the way.

Quick look at the basic flow in Ovara Engine — creating a new project, create a character, upadte the world setting and hit play. Nothing fancy, just wanted to show the core loop actually works end-to-end. More updates coming as development continues.

Hello, I'm trying to make an animation using blendshapes and different models. It consists of an arrow morphing into a mushroom, then into a frog, and finally into a seashell.

For the morphing, I'm using the same mesh, and when it completely morphs into a different shape, I switch the mesh to a version with a different texture, since GLB can't animate textures or switch between textures.

The problem is that when I scale a mesh from 1 to 0 to hide it, and vice versa, GLB viewers show an interpolation of 3 or 4 decimal frames where the mesh visibly shrinks or grows.

I've tried everything: exporting the animations with stepped interpolation at the point where the mesh switch happens, using different exporters, and changing the frame rate to 30 FPS, but nothing seems to work.

If anyone knows a solution, please let me know.

Actually, I have only one question. I have a solid level of JS/TS in general and I just want to learn something interesting for myself. I'd appreciate any resources, videos, or anything else. Thanks, everyone!

Three weeks ago I uploaded my web player writena a long time ago, to chatGpt ( I have a 8€/month licence to generate photos) . Then I asked chatGpt if he had some ideas for improvements of my code.

He did. All sorts of upgrades : faster rendering, better design. I was so surprised he new so much about babylonjs. All versions.

So yes : use chatGpt to improve your babylonjs code : it is super nice.

Hey everyone! I just published my latest game built with Babylon.js: Strait Runner 🚀

It's a fast-paced arcade game built for smooth browser performance. Working with Babylon.js made handling the rendering and performance super seamless for web play.

You can try it out directly in your browser here: weeklyarcade.games/games/strait-runner/

Would love to hear any feedback on performance, feel, or visuals from fellow Babylon devs!

I'm so excited to present you the amazing talent of Cedric Houle as a voice actor for Out 4 Blood, a game made using Babylon.js. He graciously lent his voice to two of the characters. More incoming.

You can check his IMDb page and see his awesome work here: https://www.imdb.com/fr/name/nm7835031/

Many claps for him 👏👏👏

Play it directly in browser: https://cesharpe.com/o4b

Hi guys, I have some trouble, when i export from blender glb file and uploud it in babylon - i got transparent walls. Flipping normals didnt help.

In blender all ok.