three.js vs Babylon.js
open-source
·open-source
Babylon.js wins · 6–20 (21 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round drawnthree.js publishes a llms.txt at its site root (HTTP 200 confirmed by probe) with an explicit 'Instructions for Large Language Models' section and a 363KB llms-full.txt covering complete docs, giving agents a direct machine-readable path. missing for 10: independent/community confirmation that agents actually use this llms.txt successfully in practice, and per-page markdown docs are hash-routed rather than statically addressable.
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [claimed-docs] “TSL benefits: - Works with both WebGL and WebGPU backends - No string manipulation or onBeforeCompile hacks”
- [claimed-docs] “TSL benefits: - Works with both WebGL and WebGPU backends - No string manipulation or onBeforeCompile hacks - Type-safe, composable shader n…”
Both doc.babylonjs.com and www.babylonjs.com serve dedicated llms.txt files (confirmed by live probe returning HTTP 200) with structured, categorized documentation summaries covering setup, features, and tooling, directly enabling an agent to be pointed at these files. missing for 10: no independent third-party confirmation of agent usage/consumption of these files in practice, and no .md mirrors of the full docs for deeper agent crawling.
- [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
- [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
- [claimed-docs] “Scene Management: Multiple canvases, offscreen rendering, optimization”
- [claimed-docs] “Playground: Interactive code editor and sharing”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Babylon.jsthree.jsnone0/10Three.js is fundamentally a browser WebGL/WebGPU library requiring a GPU-backed rendering context; the evidence pack contains no mention of headless rendering, Node.js server-side use, headless-gl/puppeteer integration, or CI automation support. This is a fair question for a rendering engine (other engines in this space document headless CI paths), so absence of evidence means 'none' rather than 'na'.
Babylon.js explicitly documents server-side/Node.js usage and provides a NullEngine specifically for headless rendering without a browser/WebGL context, which is the standard mechanism for running Babylon in CI or automated pipelines; NPM packages and ES6 modules further support scripted/headless integration. missing for 10: no independent/hands-on report of a CI pipeline actually using NullEngine, no explicit CI recipe or GitHub Actions example, and no MCP/agent-specific automation tooling.
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “NPM packages for all modules”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
ai-native userConnect an agent via an official MCP server
weight 3 · round drawnthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Babylon.jsnone0/10Babylon.js is a rendering/game engine (not an agent), so the MCP-server axis applies as an ecosystem feature, but evidence explicitly shows no official MCP server exists — only a tiny, inactive community repo with 9 stars.
- [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”
ai-native userUse an official CLI
weight 2 · round drawnthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userDrive the product through a documented public API
weight 3 · round to Babylon.jsthree.js exposes a well-documented JS API (WebGLRenderer/WebGPURenderer, TSL, GLTFLoader, controls) and even publishes llms.txt/llms-full.txt files explicitly aimed at LLM consumption, which supports AI-native driving of the library via npm. However this is a client-side JS library API, not a service with an OpenAPI/REST spec or an MCP server, and probes confirm no OpenAPI endpoints and no official MCP server exist. missing for 10: OpenAPI/machine-readable API spec, official MCP server, per-page static doc URLs (docs are hash-routed, only llms.txt is the structured machine path).
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [probe] “PROBE openapi: all candidate paths 404 (https://threejs.org/openapi.json, https://threejs.org/swagger.json, https://threejs.org/api/openapi.…”
- [claimed-docs] “TSL benefits: - Works with both WebGL and WebGPU backends - No string manipulation or onBeforeCompile hacks”
- [claimed-docs] “[GLTFLoader](https://threejs.org/docs/#examples/en/loaders/GLTFLoader)”
- [github] “const renderer = new THREE.WebGLRenderer( { antialias: true } ); renderer.setSize( width, height );”
Babylon.js exposes its full functionality through a well-documented TypeScript/JavaScript API (TypeDoc class references, NPM packages for all modules, tree-shakable ES6 modules) that is the primary way any AI or human driver would programmatically control the engine, and community feedback independently praises the documentation quality and API discoverability. Missing for 10: no formal API stability/versioning contract or independent third-party audit of API completeness beyond community sentiment.
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “TypeScript support with full IntelliSense”
- [claimed-docs] “NPM packages for all modules”
- [claimed-docs] “Modular design with tree-shakable ES6 modules”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
- [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
- [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
ai-native userBuild against official SDKs
weight 2 · round to Babylon.jsthree.js publishes an llms.txt/llms-full.txt with explicit LLM instructions and is consumable directly via npm, and it is an official, well-documented SDK (WebGL/WebGPU renderers, TSL, GLTFLoader, controls). However, this is a library/API rather than an 'agentic' SDK with tool-calling or agent-specific integration hooks, and there is no official MCP server or agent-oriented tooling beyond docs formatted for LLM consumption. missing for 10: no agent-specific SDK features (e.g., function-calling schemas, MCP server), no independent verification of llms.txt actually improving agent code generation, human docs are hash-routed rather than crawlable per-page.
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
- [claimed-docs] “TSL benefits: - Works with both WebGL and WebGPU backends - No string manipulation or onBeforeCompile hacks”
- [claimed-docs] “[GLTFLoader](https://threejs.org/docs/#examples/en/loaders/GLTFLoader)”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
Babylon.js ships official, versioned NPM packages (@babylonjs/core, etc.), full TypeScript typings/IntelliSense, modular ES6 tree-shakable modules, and extensive first-party API docs plus a Playground/Inspector for iterative development — exactly what an AI-native builder needs to target a stable official SDK, corroborated by the npm registry probe (234k weekly downloads, Apache-2.0) and multiple community accounts of strong documentation and active maintenance. missing for 10: no AI-specific SDK affordances like llms.txt-formatted API references beyond the top-level doc index, and no evidence of official AI-agent tooling (MCP server) wrapping the SDK.
- [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
- [claimed-docs] “TypeScript support with full IntelliSense”
- [claimed-docs] “NPM packages for all modules”
- [claimed-docs] “Modular design with tree-shakable ES6 modules”
- [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
- [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round drawnthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userSet up automations that run autonomously in the background
weight 2 · round drawnthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · round drawnthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userOperate the product with natural-language commands
weight 2 · round to three.jsthree.js publishes an llms.txt/llms-full.txt specifically to let AI coding agents generate code that drives the library, which is a step toward AI-native operability, but there is no natural-language command interface, chat layer, or MCP server that lets a user directly 'command' the renderer in natural language — an agent still has to write and run JavaScript. Missing for 10: a direct natural-language control layer, an MCP server or agent API, and independent evidence of agents successfully operating three.js purely via NL commands.
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
- [claimed-docs] “TSL benefits: - Works with both WebGL and WebGPU backends - No string manipulation or onBeforeCompile hacks”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnthree.js has a documented interactive examples gallery (threejs.org/examples) and an extensive docs/manual with API references, plus an llms.txt/llms-full.txt tailored for AI agents to consume the API reference programmatically. However, the examples are not runnable/editable inline within the docs reference itself in an AI-native interactive way, there's no API playground or embedded live code editor tied to reference pages, and human doc pages are hash-routed rather than having stable per-page URLs, limiting agentic navigation. missing for 10: inline runnable/editable examples embedded in API reference pages, stable per-page doc URLs for agent navigation, and any dedicated interactive playground/sandbox tool.
- [claimed-docs] “three.js examples”
- [claimed-docs] “[docs](manual/#en/creating-a-scene) [examples](examples/#webgl_animation_keyframes)”
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
- [community] “the three.js examples are good (if a little sloppy in coding style). I think the main thing that helps is some kind of previous knowledge ab…”
Babylon.js has a TypeDoc-based API reference (e.g. BABYLON.NullEngine class docs) and a separate interactive Playground for runnable code examples/sharing, which together support exploring the API with live examples. However, the evidence doesn't show these are integrated (e.g. runnable snippets embedded directly inside API reference pages) nor is there independent/hands-on corroboration of this specific workflow. Missing for 10: evidence of direct API-reference-to-playground integration, and community validation of the interactive-reference experience.
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “Playground: Interactive code editor and sharing”
- [claimed-docs] “Playground: Interactive code editor at playground.babylonjs.com”
- [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to three.jsThree.js has no OpenAPI/Swagger spec (explicit probe of openapi.json/swagger.json paths all 404), but it does publish an 'equivalent' machine-readable artifact for AI consumption: a root-level llms.txt with an explicit 'Instructions for Large Language Models' section and a 363KB llms-full.txt covering the full API surface. This is a documentation-style machine-readable spec rather than a structured, typed API schema (no parameter/type schema, no endpoint-like structure). Missing for 10: a structured schema format (OpenAPI-equivalent with typed signatures), and any indication the llms.txt is treated as a formal versioned spec rather than prose docs.
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
- [probe] “PROBE openapi: all candidate paths 404 (https://threejs.org/openapi.json, https://threejs.org/swagger.json, https://threejs.org/api/openapi.…”
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
Babylon.jsnone0/10Babylon.js exposes only human-oriented TypeDoc API references and llms.txt files; explicit probes for OpenAPI/swagger endpoints (openapi.json, swagger.json, etc.) all returned 404, showing no machine-readable API spec is published.
- [probe] “PROBE openapi: all candidate paths 404 (https://doc.babylonjs.com/openapi.json, https://doc.babylonjs.com/swagger.json, https://doc.babylonj…”
- [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to Babylon.jsthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Babylon.js offers a NullEngine for headless/server-side testing and dedicated Playground/Sandbox tools (playground.babylonjs.com, sandbox.babylonjs.com) that let developers test scenes and code in isolation, which loosely maps to sandboxed testing without touching a 'production' environment. However, as a client-side rendering engine there is no concept of production data/environments analogous to a SaaS backend, so the story only partially applies. Missing for 10: explicit documentation framing these tools as a prod/test separation mechanism, and independent evidence of AI-native agents actually using NullEngine/Playground as a safe sandbox.
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “Playground: Interactive code editor and sharing”
- [claimed-docs] “Sandbox: Model viewer at sandbox.babylonjs.com”
- [claimed-docs] “Playground: Interactive code editor at playground.babylonjs.com”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnThere is a Migration Guide and per-release notes documenting breaking changes between versions (e.g. 185→186), and npm shows a clear version number (0.186.0), but nothing describes a formal deprecation policy (notice periods, stable API guarantees, semver commitments) — three.js is known for frequent breaking changes on its own rolling release cadence. missing for 10: explicit deprecation policy statement, semver/API-stability guarantees, notice period before removals.
- [claimed-docs] “[Migration Guide](/mrdoob/three.js/wiki/Migration-Guide)”
- [claimed-docs] “https://github.com/mrdoob/three.js/wiki/Migration-Guide#185--186”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
Babylon.js ships versioned npm packages (e.g. @babylonjs/core at 9.26.1) and community reports strong backward compatibility across releases, but there is no evidence of a documented, formal deprecation policy (e.g. deprecation timelines, breaking-change notices, semver commitments in docs). missing for 10: explicit documented deprecation policy, versioning/semver commitment docs, migration guides for breaking changes.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
- [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
- [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
Ai workflows — AI in the engine loop — agent-driven editors, copilots, codegen-friendly APIs, runtime inferenceAi workflows
AI in the engine loop — agent-driven editors, copilots, codegen-friendly APIs, runtime inference
Agent editor
ai-native userAn agent can drive the editor and project programmatically — create scenes and nodes, edit properties, trigger builds — through a documented scriptable interface
weight 3 · round drawnThree.js's core JS API lets an agent create scenes, nodes, meshes, and materials and edit properties programmatically (documented in llms.txt for LLM consumption), but this is just using the library — there's no evidence of a documented scripting/automation interface for the standalone three.js editor app itself, nor any 'trigger build' concept or API. Missing for 10: documented editor automation/scripting API, evidence of programmatic control of the editor UI, and any build/export trigger mechanism.
- [claimed-docs] “three.js editor”
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [github] “This code creates a scene, a camera, and a geometric cube, and it adds the cube to the scene. It then creates a `WebGL` renderer for the sce…”
- [claimed-docs] “[docs](manual/#en/creating-a-scene) [examples](examples/#webgl_animation_keyframes)”
Babylon.js exposes a fully documented JS/TS API (scenes, meshes, materials, physics, NPM packages, TypeScript IntelliSense) letting code programmatically create scenes/nodes and edit properties, plus browser tools like Inspector, Playground, and Node Material Editor for scene editing. However these are interactive browser UIs, not designed for external programmatic driving by an agent, there's no 'build' trigger concept, and a runtime probe explicitly notes no official MCP server or agent-integration layer exists (largest community MCP repo has 9 stars, inactive since mid-2025). missing for 10: a documented agent-facing interface (e.g. MCP server or CLI) to drive the Playground/Inspector/NME externally, a build-trigger mechanism, and independent evidence of agents successfully automating editor workflows.
- [claimed-docs] “Scene Management: Multiple canvases, offscreen rendering, optimization”
- [claimed-docs] “Inspector: Visual debugging and scene editing”
- [claimed-docs] “Playground: Interactive code editor and sharing”
- [claimed-docs] “Node Material Editor: Visual shader editor at nme.babylonjs.com”
- [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”
Codegen
ai-native userLLM-generated code mostly works on the first try — stable, well-documented APIs with abundant public examples the models have seen
weight 2 · round drawnThree.js is hugely popular (12M weekly npm downloads) with abundant public examples and even a dedicated llms.txt/llms-full.txt tailored for LLM consumption, which strongly favors first-try LLM code generation. However, community evidence and the docs themselves point to real friction: frequent breaking API changes requiring per-version migration guides, explicit warnings to use 'CORRECT - modern pattern' import maps (implying old LLM-trained patterns break), and hands-on reports that seemingly simple tasks (loading a model) were unexpectedly hard, undermining 'mostly works on the first try.' Missing for 10: independent benchmark/report of LLM-generated three.js code success rate, and stronger evidence that API stability (not just doc richness) prevents version-mismatch failures.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [claimed-docs] “CORRECT - modern pattern (always use latest version): html <script type="importmap">”
- [claimed-docs] “[Migration Guide](/mrdoob/three.js/wiki/Migration-Guide)”
- [community] “I've tried to follow three.js's own tutorials, and slip into coma every time. These are a vast improvement!”
- [community] “I was super excited to use Three.js and thought it would be easy to do what I wanted. What I wanted to do was load a simple .obj model and d…”
- [community] “there are some function signatures that don't match what's in the code using @types/three, and mrdoob does not want to maintain this. This g…”
Babylon.js ships dedicated llms.txt files, extensive typed API docs, and community testimony praising documentation quality and strong backwards compatibility (stability helps LLM-generated code stay valid across versions). However, community evidence also notes it has notably less public content/examples than competitors like Three.js ('a lot more written about three than Babylon'), which limits training-data exposure for LLMs, and docs are client-rendered Next.js with no markdown mirrors, hurting scrapability. Missing for 10: direct evidence of LLM code-generation success rates, broader public example corpus comparable to more-documented competitors, and machine-readable doc mirrors beyond llms.txt.
- [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
- [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
- [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
- [community] “Babylon seemed much more approachable than three for basic stuff (a box and a camera). However there is a lot more written about three than …”
- [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”
Copilot
ai-native userAn official AI assistant inside the engine helps with engine tasks — generating scripts, answering API questions, scaffolding scenes or assets
weight 2 · round drawnthree.jsnone0/10Evidence shows only LLM-friendly documentation (llms.txt) and no in-engine AI assistant, chat copilot, or code-generation assistant feature; probe explicitly notes no MCP server or agent integration exists, official or community.
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
Babylon.jsnone0/10No evidence of an official in-engine AI assistant for generating scripts, answering API questions, or scaffolding scenes; the pack only shows llms.txt documentation files (aimed at external AI tools consuming docs) and explicitly notes an essentially nonexistent MCP ecosystem with no official server.
- [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”
- [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”
Asset pipeline — getting content in — automated import, formats, marketplacesAsset pipeline
Getting content in — automated import, formats, marketplaces
Formats
technical artistStandard interchange formats — glTF, FBX, USD — import cleanly
weight 2 · round to Babylon.jsOnly GLTFLoader is explicitly evidenced as a documented import path; there is no mention of FBX or USD loaders in the evidence pack, and a community report describes friction loading even a simple OBJ model, undercutting the 'imports cleanly' framing. Missing for 10: FBXLoader/USDLoader documentation or examples, first-party guidance on interchange-format fidelity, and independent confirmation that glTF/FBX/USD assets import without manual fixes.
- [claimed-docs] “[GLTFLoader](https://threejs.org/docs/#examples/en/loaders/GLTFLoader)”
- [community] “I was super excited to use Three.js and thought it would be easy to do what I wanted. What I wanted to do was load a simple .obj model and d…”
Babylon.js has strong, well-documented glTF import support (dedicated importer docs, sandbox/model viewer, and general multi-format support including .babylon/glTF/STL/OBJ), and community feedback praises smooth import of 3D model data. However, there is no evidence in the pack of native FBX or USD import support, which are explicitly part of the story's required format set — missing for 10: FBX import documentation/tooling, USD import support, independent confirmation of clean FBX/USD round-tripping.
- [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
- [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”
- [claimed-docs] “Sandbox: Model viewer at sandbox.babylonjs.com”
- [community] “Babylon.js is an amazing framework. The 3d concepts are ingrained into the API and framework. The ability to read 3d model data from Blender…”
Import
technical artistAsset import is automatable — import hooks, presets, and pipeline scripts process incoming assets without hand-clicking each one
weight 2 · round to Babylon.jsthree.jsnone0/10three.js is a rendering library with a GLTFLoader and asset loaders, but there is no evidence of automatable asset-import pipelines, import hooks, presets, or scripted batch-processing of incoming assets — everything in the evidence pack concerns runtime rendering APIs, TSL/WebGPU, and manual loader usage rather than pipeline automation.
- [claimed-docs] “[GLTFLoader](https://threejs.org/docs/#examples/en/loaders/GLTFLoader)”
- [github] “The current builds only include WebGL and WebGPU renderers but SVG and CSS3D renderers are also available as addons.”
Babylon.js exposes glTF/OBJ/STL import via a programmatic SceneLoader API and can run headlessly via NullEngine/server-side rendering (babylonjs-docs-2, babylonjs-docs-3, babylonjs-docs-6, babylonjs-docs-8), which implies imports can be scripted rather than hand-clicked, but there is no dedicated documentation of import hooks, batch presets, or a formal asset-pipeline/automation tool for technical artists. Missing for 10: explicit pipeline/preset tooling, CLI or build-step asset processors, documented hook system for custom import automation, and independent evidence of technical artists using it this way.
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
- [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”
Marketplace
game developerA large asset store or package ecosystem gives me ready-made models, tools, and plugins
weight 2 · round to Babylon.jsthree.jsnone0/10Evidence only shows three.js's own built-in addons (GLTFLoader, OrbitControls, editor, devtools) and npm package popularity, not a third-party asset store or plugin marketplace comparable to Unity/Unreal ecosystems; community commentary even notes basic model loading (.obj) was painful. missing for 10: any evidence of a dedicated asset store, marketplace, or curated third-party plugin ecosystem for game assets/tools.
- [claimed-docs] “[GLTFLoader](https://threejs.org/docs/#examples/en/loaders/GLTFLoader)”
- [claimed-docs] “[OrbitControls](https://threejs.org/docs/#examples/en/controls/OrbitControls) - [TransformControls](https://threejs.org/docs/#examples/en/co…”
- [claimed-docs] “three.js editor”
- [claimed-docs] “[devtools](https://chromewebstore.google.com/detail/threejs-devtools/jechbjkglifdaldbdbigibihfaclnkbo)”
- [community] “I was super excited to use Three.js and thought it would be easy to do what I wanted. What I wanted to do was load a simple .obj model and d…”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
Babylon.js has a real npm package ecosystem (234k weekly downloads, modular tree-shakable modules) and supports many asset import formats (glTF, OBJ, STL, .babylon), plus community-built tools like Spector.js debugger and React-BabylonJS integration mentioned in community threads. However, there is no evidence of a dedicated asset store or marketplace for ready-made models comparable to Unity/Unreal asset stores, and the runtime probe explicitly notes the ecosystem around it (e.g., MCP tooling) is thin. Missing for 10: a curated marketplace/asset store for models, a rich plugin directory analogous to Unity Asset Store, and independent evidence of third-party asset packs beyond a couple of community-mentioned tools.
- [claimed-docs] “NPM packages for all modules”
- [claimed-docs] “Modular design with tree-shakable ES6 modules”
- [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”
- [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
- [community] “Babylon is awesome! I just started writing a game with it. The integration with TypeScript works well and there also are very fun things lik…”
- [community] “The impressive thing about Babylon.js is Spector, a fully functional WebGL debugger extension in Chrome which makes 3D development on the we…”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
- [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnthree.jsnone0/10No evidence describes batch/bulk APIs (e.g., instancing, scene-graph batch edits) or automation tooling for operating on many items at once; the evidence pack only covers renderer setup, TSL, loaders, and controls.
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to Babylon.jsthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Babylon.js does include an ActionManager subsystem for defining triggers (e.g., on-pick, on-intersect) that fire actions automatically, referenced by a community user noting it 'has an action manager,' but this is not documented in the first-party doc excerpts provided and no detail on its rule scope or AI-native usage is given. Missing for 10: official documentation of the ActionManager/trigger system, examples of complex rule chaining, and any AI-agent-specific automation hooks.
- [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”
ai-native userVersion, review, and roll back my automations
weight 1 · round drawnthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Core engine — the engine core — rendering, 2D, physics, performance at scaleCore engine
The engine core — rendering, 2D, physics, performance at scale
2d
game developer2D is a first-class workflow — sprites, tilemaps, 2D physics — not a 3D afterthought
weight 2 · round to Babylon.jsthree.jsnone0/10The evidence pack shows three.js is positioned and documented purely as a 3D graphics library (WebGL/WebGPU renderers, TSL shaders, GLTFLoader, OrbitControls) with no mention of sprites, tilemaps, or 2D physics as first-class citizens; 2D is at best an afterthought achievable via workarounds, consistent with community comments about needing workarounds for things it wasn't built for.
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
- [github] “The current builds only include WebGL and WebGPU renderers but SVG and CSS3D renderers are also available as addons.”
- [claimed-docs] “**Use WebGPURenderer** when you need: - Custom shaders/materials using TSL (Three.js Shading Language) - Compute shaders - Advanced node-bas…”
- [community] “Three.js is insane, in a good way. Great abstraction of WebGL, very user friendly, and surprisingly few things that it can't do, as long as …”
Babylon.js is documented primarily as a 3D/WebGL engine; only a single community comment notes 'sprite support and other 2d-graphics functionality' and the docs mention a 2D/3D GUI system, but there is no evidence of tilemap tooling or a dedicated 2D physics workflow — 2D appears as an add-on rather than a first-class pipeline. missing for 10: tilemap support, dedicated 2D physics engine/workflow, first-party docs treating 2D as a core (not secondary) workflow, independent corroboration of sprite tooling.
- [community] “Babylon.js is based on the Babylon Toolkit for Silverlight, and includes significantly more features than Three.js, including sprite support…”
- [claimed-docs] “GUI System: 2D and 3D user interfaces”
- [claimed-docs] “Physics: Havok, Cannon.js, Ammo.js integration”
Performance
game developerProfile and scale — a real profiler, plus data-oriented paths (ECS, jobs, instancing) when scenes get heavy
weight 2 · round to Babylon.jsthree.jsnone0/10No evidence of a built-in profiler, ECS, job system, or GPU/CPU instancing tooling in the pack — only renderer setup, TSL/WebGPU shading, loaders, and controls are documented. Three.js is a rendering library, not a full engine, so profiling and data-oriented scaling primitives fall to external tools (Chrome DevTools extension is mentioned but that's a generic browser profiler, not a real-time engine profiler), and no ECS/jobs/instancing capability is cited.
- [claimed-docs] “[devtools](https://chromewebstore.google.com/detail/threejs-devtools/jechbjkglifdaldbdbigibihfaclnkbo)”
Babylon.js clearly ships real profiling tools — the Inspector/Scene Inspector for runtime debugging and scene analysis, plus community confirmation of the Spector.js WebGL debugger — but there is no documented ECS, job/worker system, or GPU instancing API in the evidence pack for scaling heavy scenes. Community notes even flag historical GC/allocation pressure concerns around performance-sensitive code. missing for 10: explicit ECS architecture, job/worker-based parallelism, and documented instancing API/guidance for scaling heavy scenes.
- [claimed-docs] “Inspector: Visual debugging and scene editing”
- [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
- [community] “The impressive thing about Babylon.js is Spector, a fully functional WebGL debugger extension in Chrome which makes 3D development on the we…”
- [community] “It seems to be pretty heavy on object allocation, e.g. BABYLON.Vector3.prototype.add creates a new Vector3 each time, unlike gl-matrix's in-…”
- [community] “The next version (1.2) will remove the pressure on GC by using in-place operators and by reusing more entities.”
Physics
game developerBuilt-in physics — rigid bodies, collisions, raycasts — works out of the box
weight 2 · round to Babylon.jsthree.jsnone0/10three.js is a rendering library — no evidence of any built-in physics engine (rigid bodies, collisions, raycasts as physics) shipped out of the box; evidence only covers rendering (WebGL/WebGPU), loaders, and controls. Raycaster exists in three.js for picking but no physics/collision system is documented, and physics is a well-known gap requiring third-party libraries like Cannon.js or Ammo.js.
Babylon.jsdisputedcontradicted5/10Docs confirm built-in physics engine integration (Havok, Cannon.js, Ammo.js, Oimo.js) and community posts mention 'physics plug-ins and collisions' as part of the engine's game-engine-like feature set, but a detailed hands-on critique explicitly calls the physics implementation 'inexcusably my first game engine level of incompetence,' citing broken velocity/acceleration handling and frame-rate dependent world time, plus another comment noting it 'doesn't care for real-world physics scale.' This is a concrete first-hand contradiction of the 'works out of the box' claim, not mere skepticism. missing for 10: raycast-specific evidence, independent benchmark refuting or confirming the physics bug claims, resolution/fix documentation.
- [claimed-docs] “Physics: Havok, Cannon.js, Ammo.js integration”
- [claimed-docs] “Support for multiple physics engines (Cannon.js, Oimo.js, Ammo.js)”
- [community] “The 'Physics' in Babylon.js is at the inexcusably 'my first game engine' level of incompetence. Velocity and acceleration treated as if they…”
- [community] “I had high hopes for babylon.js... My gripes: no 'preferred navigation feel', doesn't care for real-world physics scale, setting up a defaul…”
- [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”
Rendering
game developerThe engine ships a modern production 3D renderer — PBR materials, global illumination or baked lighting, shadows, post-processing
weight 3 · round drawnEvidence confirms a modern rendering pipeline (WebGLRenderer/WebGPURenderer, antialiasing, and node-based 'MeshStandardNodeMaterial' implying PBR-style materials) but the pack contains no explicit documentation of shadow mapping, global illumination/baked lighting, or a post-processing pipeline — a community comment even asks uncertainly whether lightmaps are possible. missing for 10: explicit shadow-mapping docs, GI/lightmap baking evidence, post-processing/effects pipeline documentation, independent confirmation of PBR material fidelity.
- [claimed-docs] “When using TSL, use node-based materials: - MeshBasicNodeMaterial - MeshStandardNodeMaterial”
- [claimed-docs] “Use WebGPURenderer when you need: - Custom shaders/materials using TSL (Three.js Shading Language) - Compute shaders - Advanced node-based m…”
- [github] “const renderer = new THREE.WebGLRenderer( { antialias: true } ); renderer.setSize( width, height );”
- [community] “That is called aliasing. Three.js defaults to it, but you can turn antialiasing on by passing the option to the WebGLRenderer.”
- [community] “Can you actually generate lightmaps with three.js? I did a lot with it years ago. Really nice abstraction library.”
Evidence confirms Babylon.js is a real-time WebGL/WebGPU rendering engine with a Node Material Editor and native glTF PBR material import, implying baseline PBR support, but the pack contains no explicit documentation of shadow mapping, global illumination/baked lighting, or a post-processing pipeline. Community threads praise visual quality and demos but don't confirm these specific pipeline features either. Missing for 10: explicit shadow system docs, GI/lightmapping baked-lighting docs, post-process stack documentation, and independent corroboration of PBR material fidelity.
- [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
- [claimed-docs] “Node Material Editor”
- [claimed-docs] “WebGL and WebGPU rendering support”
- [claimed-docs] “WebGPU Support: Next-generation graphics API”
- [community] “This has so many more capabilities than Three.js and the gap seems to be growing.”
Editor tooling — the editor as a product — scene tools, extensibility, team workflowsEditor tooling
The editor as a product — scene tools, extensibility, team workflows
Collaboration
studio leadThe project format and tooling play well with version control and multi-person teams — mergeable scenes, diffable text formats, or built-in collaboration
weight 2 · round drawnthree.jsnone0/10three.js is a rendering library/API, not a scene-authoring tool with a project file format; evidence shows only a code-based API, an optional visual editor, and no mention of diffable scene formats, merge tooling, or multi-user collaboration features. This axis applies to engines/authoring tools generally, but nothing in the evidence indicates three.js ships mergeable/diffable project files or built-in collaboration.
- [claimed-docs] “three.js editor”
- [github] “This code creates a scene, a camera, and a geometric cube, and it adds the cube to the scene. It then creates a `WebGL` renderer for the sce…”
- [claimed-docs] “[docs](manual/#en/creating-a-scene) [examples](examples/#webgl_animation_keyframes)”
Editor
technical artistA full visual editor — viewport, inspector, prefabs/scene composition — is the primary way to build levels
weight 3 · round to Babylon.jsthree.js ships a browser-based editor (threejs.org/editor) and devtools/TransformControls, but evidence only names the editor's existence with no documentation of an inspector, prefab system, or scene-composition workflow, and the library's primary workflow is code-first (constructing scenes via API) rather than a visual editor. Missing for 10: documented inspector UI, prefab/asset composition workflow, evidence the editor is treated as the primary level-building tool rather than a supplementary demo tool.
- [claimed-docs] “three.js editor”
- [claimed-docs] “[OrbitControls](https://threejs.org/docs/#examples/en/controls/OrbitControls) - [TransformControls](https://threejs.org/docs/#examples/en/co…”
- [claimed-docs] “[devtools](https://chromewebstore.google.com/detail/threejs-devtools/jechbjkglifdaldbdbigibihfaclnkbo)”
Babylon.js ships an Inspector for runtime scene debugging/editing, a Node Material Editor, Playground, and Sandbox model viewer, but these are auxiliary tools layered on a code-first engine rather than a unified viewport+prefab+scene-composition editor that serves as the primary level-building workflow. Community commentary confirms it's approached as a programming API/game engine, not an artist-first editor. missing for 10: a full prefab/scene-composition system, an integrated single viewport combining inspector+asset placement+hierarchy editing as the primary workflow, and evidence of technical artists building levels without code.
- [claimed-docs] “Inspector: Visual debugging and scene editing”
- [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
- [claimed-docs] “Node Material Editor”
- [claimed-docs] “Playground: Interactive code editor and sharing”
- [claimed-docs] “Sandbox: Model viewer at sandbox.babylonjs.com”
- [community] “I switched from Three to Babylon two years ago... Babylon has a compact, active set of devs (I've made bug reports and seen the fix in the n…”
- [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”
Extensibility
game developerExtend and automate the editor itself — custom tools, editor scripts, plugins that manipulate scenes and assets programmatically
weight 3 · round drawnthree.jsnone0/10Evidence confirms three.js ships an editor (threejs.org/editor) and a devtools browser extension, but nothing in the pack describes any plugin API, scripting console, or extension mechanism for programmatically automating the editor itself — the docs excerpts focus on the library API (TSL, renderers, loaders, controls), not editor extensibility.
- [claimed-docs] “three.js editor”
- [claimed-docs] “[devtools](https://chromewebstore.google.com/detail/threejs-devtools/jechbjkglifdaldbdbigibihfaclnkbo)”
Babylon.jsnone0/10Evidence mentions an Inspector for visual scene debugging/editing and a Playground/Node Material Editor, but nothing documents an extensibility API, plugin system, or scripting interface for building custom editor tools or automating the editor itself. Missing for 10: editor plugin/extension API, documented editor scripting hooks, examples of third-party editor tools or automation scripts.
- [claimed-docs] “Inspector: Visual debugging and scene editing”
- [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
- [claimed-docs] “Playground: Interactive code editor and sharing”
- [claimed-docs] “Node Material Editor”
Headless automation — the engine without a human — CLI builds, CI test runs, dedicated serversHeadless automation
The engine without a human — CLI builds, CI test runs, dedicated servers
Ci
game developerBuild and export the project from the command line, headless, in CI — no human clicking an editor
weight 3 · round to Babylon.jsthree.jsnone0/10Evidence shows three.js is a code-first WebGL/WebGPU library installed via npm/git and used with standard `WebGLRenderer` setup, but nothing documents a CLI or automated pipeline for building/exporting a 'project' headlessly in CI (no headless rendering support, no export tooling, no CI recipes) — the only editor mentioned (threejs.org/editor) is a browser GUI requiring human interaction. missing for 10: any documented headless rendering approach (e.g. headless-gl/Node canvas), a CLI build/export command, and CI pipeline examples.
- [github] “const renderer = new THREE.WebGLRenderer( { antialias: true } ); renderer.setSize( width, height );”
- [github] “git clone --depth=1 https://github.com/mrdoob/three.js.git”
- [claimed-docs] “three.js editor”
- [github] “This code creates a scene, a camera, and a geometric cube, and it adds the cube to the scene. It then creates a `WebGL` renderer for the sce…”
Babylon.js is a library, not an editor-centric tool, so scenes are inherently built via code/npm (NullEngine for headless rendering, server-side support, NPM/ES6 modules) — this enables CLI/CI usage in principle. However, there is no documented official CLI, build/export pipeline, or CI/headless-testing example specific to game export workflows; the evidence only shows generic headless-engine primitives, not an end-to-end automated build/export toolchain. missing for 10: an official CLI or build tool for scene/asset export, documented CI pipeline examples, evidence of automated packaging/export without any editor interaction, independent confirmation of headless CI usage.
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “Scene Management: Multiple canvases, offscreen rendering, optimization”
- [claimed-docs] “NPM packages for all modules”
- [claimed-docs] “Modular design with tree-shakable ES6 modules”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
Server
game developerGame logic runs headless on servers — a dedicated-server or server-runtime build without rendering
weight 2 · round to Babylon.jsthree.jsnone0/10three.js is fundamentally a browser-based WebGL/WebGPU rendering library requiring a canvas/GPU context; the evidence pack shows no headless/server-runtime build, no dedicated-server mode, and no mention of running game logic without rendering on Node.js servers. missing for 10: any headless rendering context (e.g. node-canvas/gl bindings), a documented server-runtime build, or dedicated-server examples.
Babylon.js documents server-side usage and a NullEngine specifically designed for headless execution (no rendering context) on Node.js, which supports running game logic/physics without a GPU or DOM, per babylonjs-docs-2 and babylonjs-docs-3. However, this is a headless rendering-engine mode rather than a dedicated 'server-runtime build' product, and there's no independent/hands-on corroboration of production server deployments or performance at scale. missing for 10: independent verification of NullEngine in production server use, benchmarks/scale evidence, and any purpose-built 'server build' distinct from just importing core modules headlessly.
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “NPM packages for all modules”
Testing
game developerTests run headlessly — unit and integration tests of game code execute in CI against the real engine
weight 2 · round to Babylon.jsthree.jsnone0/10No evidence in the pack addresses headless testing, CI integration, or running WebGLRenderer/WebGPURenderer without a browser context (e.g. via node-canvas, jsdom, or headless GL). All evidence covers rendering setup, docs, and community sentiment, none of it about automated/headless test execution.
Babylon.js ships a documented NullEngine specifically for running the engine headlessly (no WebGL context) plus a dedicated server-side/Node.js support guide, which is the standard mechanism for executing engine logic in CI/unit tests. Missing for 10: independent/community corroboration of real CI pipelines using NullEngine, and no example test harness or CI config shown in the evidence.
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “NPM packages for all modules”
Licensing openness — the terms you build on — licenses, royalties, source access, pricing stabilityLicensing openness
The terms you build on — licenses, royalties, source access, pricing stability
Governance
studio leadThe project's governance and funding are transparent — a foundation, published finances, or a public roadmap I can plan against
weight 1 · round drawnthree.jsnone0/10No evidence of a foundation, published finances, or public roadmap; three.js governance appears to be maintainer-driven (mrdoob) via GitHub releases/migration guides with no financial transparency artifacts in the pack.
License
studio leadThe license is permissive with no royalties or per-install fees — I keep what my game earns
weight 3 · round to three.jsnpm registry confirms three.js is MIT licensed, a permissive license with no royalties or per-install fees, verified directly from the package registry. Missing for 10: no explicit first-party licensing FAQ or legal statement addressing commercial game royalties specifically, relying instead on the generic MIT registry classification.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
The runtime probe confirms Babylon.js core packages are published under Apache-2.0, a permissive license with no royalties or per-install fees, and this is corroborated by wide npm adoption figures. Missing for 10: no explicit first-party licensing page/FAQ evidence in the pack addressing commercial game revenue or royalty terms directly, and no independent legal/community discussion confirming this understanding.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
Source
game developerRead and modify the full engine source when I hit a wall
weight 2 · round to three.jsthree.js is open-source (MIT license per npm registry) with full source hosted on GitHub, clonable and directly modifiable, and community evidence confirms active engagement with the codebase (e.g., @ts-ignore workarounds, discussion of internals like antialiasing defaults). Missing for 10: no explicit first-party statement encouraging source modification as a supported workflow, and no case study of a game dev forking/patching the engine for a shipped title.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
- [github] “git clone --depth=1 https://github.com/mrdoob/three.js.git”
- [community] “there are some function signatures that don't match what's in the code using @types/three, and mrdoob does not want to maintain this. This g…”
- [community] “That is called aliasing. Three.js defaults to it, but you can turn antialiasing on by passing the option to the WebGLRenderer.”
Babylon.js is confirmed Apache-2.0 licensed and distributed as open npm packages (@babylonjs/core), and community reports describe developers filing GitHub bug reports and seeing fixes merged within nightly builds, indicating the source is open, forkable, and modifiable in practice. Missing for 10: explicit product docs on the contribution/build-from-source workflow and any direct developer account of forking the engine to patch internals.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
- [community] “three.js seems more well known/established than babylon... I went with babylon and I'm glad I did. Better performance and the object names a…”
- [community] “I switched from Three to Babylon two years ago... Babylon has a compact, active set of devs (I've made bug reports and seen the fix in the n…”
- [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”
Trust
studio leadThe pricing and license terms have a track record of stability — no retroactive changes that reprice games already shipped
weight 2 · round to Babylon.jsthree.js is MIT-licensed, verified from the npm registry, which is a free, permissive open-source license with no pricing terms to retroactively change — this structurally supports licensing stability. However, there is no explicit evidence pack documentation of license history, versioning of terms, or any studio commentary confirming a track record of stability over time. Missing for 10: explicit license-history documentation, third-party confirmation of no relicensing/repricing events, and studio-lead testimonials on licensing trust.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
Babylon.js is confirmed as Apache-2.0 licensed open-source software (babylonjs-probe-rt-1), a permissive license model that structurally cannot retroactively reprice shipped games — there is no paid-tier or revenue-share license to alter. No evidence in the pack shows any history of license or pricing changes, and community discussion focuses on technical quality, not licensing disputes. Missing for 10: an explicit historical narrative confirming multi-year license stability or any statement addressing past licensing changes (or lack thereof).
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to Babylon.jsthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Babylon.js is fundamentally a code-first library (NPM/ES6 modules, TypeScript, NullEngine for headless/server-side use) so most scene, mesh, material and physics functionality is exposed programmatically, and NullEngine explicitly supports server-side/headless scenarios without any UI [babylonjs-docs-2, babylonjs-docs-3, babylonjs-docs-24, babylonjs-docs-25]. However, the evidence never explicitly confirms that visual-only tools like the Node Material Editor, Inspector, or Playground have complete 1:1 API equivalents for every feature they expose, so full UI/API parity is inferred rather than documented. Missing for 10: explicit documentation stating NME/Inspector-generated configurations are always fully reproducible via API alone, and independent confirmation of this parity.
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “Node Material Editor”
- [claimed-docs] “Inspector: Visual debugging and scene editing”
- [claimed-docs] “Node Material Editor: Visual shader editor at nme.babylonjs.com”
- [claimed-docs] “NPM packages for all modules”
- [claimed-docs] “Modular design with tree-shakable ES6 modules”
ai-native userExport all of my data in open formats and leave
weight 3 · round to Babylon.jsthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Babylon.js is open-source (Apache-2.0) and supports open, standard 3D file formats like glTF, OBJ, and STL alongside its own .babylon format, so scene/asset data isn't locked into a single proprietary format and can be exported or moved elsewhere. However, there is no first-party or community evidence of a comprehensive 'export all my data and leave' workflow, no discussion of data portability/lock-in avoidance as a stated goal, and no independent confirmation that full round-trip export preserves all engine-specific features (physics, materials, animations). missing for 10: explicit data-export/migration documentation, independent verification of full-fidelity export to open formats, and any framing of this as an intentional anti-lock-in feature.
- [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”
- [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
ai-native userRead the product's source under an open license
weight 2 · round drawnthree.js source is hosted publicly on GitHub (mrdoob/three.js) and distributed via npm under the MIT license, verified directly from the npm registry; the repo is clonable and openly browsable. missing for 10: no explicit license file text quoted in the evidence pack, only registry-confirmed MIT license metadata.
- [github] “const renderer = new THREE.WebGLRenderer( { antialias: true } ); renderer.setSize( width, height );”
- [github] “git clone --depth=1 https://github.com/mrdoob/three.js.git”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
Babylon.js core is confirmed Apache-2.0 licensed and published on npm (v9.26.1), and the project is well known to be hosted openly on GitHub with full source visible; runtime probe corroborates the license and package registry data. Missing for 10: no explicit evidence pack citation of the GitHub repository page itself or contribution guidelines to fully corroborate open-source hosting beyond the npm license field.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
ai-native userSelf-host the core product
weight 3 · round to three.jsthree.js is an open-source (MIT) client-side library distributed via npm/GitHub that can be cloned, built, and self-hosted entirely without any vendor service, as shown by the git clone instructions and npm registry data. missing for 10: no explicit first-party 'self-hosting guide' doc beyond generic clone/build instructions, and no independent case study of a fully self-hosted deployment.
- [github] “git clone --depth=1 https://github.com/mrdoob/three.js.git”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
- [github] “The current builds only include WebGL and WebGPU renderers but SVG and CSS3D renderers are also available as addons.”
Babylon.js is an Apache-2.0 licensed npm package/library that runs entirely client-side or server-side (NullEngine, documented server-side support), so a user can self-host the core engine simply by installing it in their own infrastructure with no vendor cloud dependency; runtime probe confirms open license and active npm distribution. Missing for 10: no explicit self-hosting/deployment guide (e.g., Docker image, on-prem playground/inspector hosting instructions) and no independent report of someone self-hosting the full toolchain (playground, inspector, sandbox) rather than just the core engine.
- [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
- [claimed-docs] “NPM packages for all modules”
Platform export — shipping everywhere — desktop, mobile, console, browser payloadsPlatform export
Shipping everywhere — desktop, mobile, console, browser payloads
Targets
studio leadOne project exports to desktop, mobile, and (directly or via partners) consoles
weight 3 · round to Babylon.jsthree.jsnone0/10The evidence pack shows three.js is a browser-based WebGL/WebGPU rendering library with no documentation of a build/export pipeline to native desktop, mobile, or console targets — no mention of Electron/Cordova wrapping, console SDK partnerships, or platform-specific packaging tools. While the axis is fair to ask of any 3D technology a studio might adopt, there is no evidence three.js provides or facilitates such multi-platform export beyond running inside a web browser.
- [github] “const renderer = new THREE.WebGLRenderer( { antialias: true } ); renderer.setSize( width, height );”
- [github] “The current builds only include WebGL and WebGPU renderers but SVG and CSS3D renderers are also available as addons.”
- [probe] “PROBE llms.txt: HTTP 200 at https://threejs.org/llms.txt # Three.js > Three.js is a cross-browser JavaScript library for creating 3D graphi…”
Babylon.js supports web (WebGL/WebGPU) export and claims native cross-platform via Babylon Native, which could enable desktop/mobile builds, but the evidence pack contains no documentation of console export (PlayStation, Xbox, Switch) or partner pipelines, and no independent confirmation of Babylon Native's mobile/desktop deployment maturity. missing for 10: console export/partner program details, hands-on evidence of desktop/mobile builds via Babylon Native, independent corroboration of cross-platform deployment success.
- [claimed-docs] “Cross-Platform: Runs seamlessly on web browsers and natively with Babylon Native”
- [claimed-docs] “WebGL and WebGPU rendering support”
- [claimed-docs] “WebGPU Support: Next-generation graphics API”
Web
web developerMy game runs in the browser with a reasonable payload — WebGL today, and a credible WebGPU story
weight 2 · round to three.jsthree.js runs in-browser via WebGLRenderer (widely used, huge npm install base) and has a credible, actively developed WebGPU story through WebGPURenderer plus TSL shaders that target both WebGL and WebGPU backends, with SVG/CSS3D as lighter addons keeping core payload lean. Community confirms it's a solid abstraction over WebGL, though payload/performance specifics for WebGPU maturity aren't independently benchmarked in evidence. missing for 10: independent bundle-size/payload benchmarks, and hands-on confirmation of WebGPU production readiness beyond docs claims.
- [github] “const renderer = new THREE.WebGLRenderer( { antialias: true } ); renderer.setSize( width, height );”
- [github] “The current builds only include WebGL and WebGPU renderers but SVG and CSS3D renderers are also available as addons.”
- [claimed-docs] “**Use WebGPURenderer** when you need: - Custom shaders/materials using TSL (Three.js Shading Language) - Compute shaders - Advanced node-bas…”
- [claimed-docs] “TSL benefits: - Works with both WebGL and WebGPU backends - No string manipulation or onBeforeCompile hacks”
- [community] “Three.js is insane, in a good way. Great abstraction of WebGL, very user friendly, and surprisingly few things that it can't do, as long as …”
- [community] “THREE.js adds a nice layer of abstraction atop that metal [WebGL].”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
Docs confirm both WebGL and WebGPU rendering support plus tree-shakable ES6/NPM modules for payload optimization, but community evidence flags real payload concerns (Babylon is described as 3x the size of Three.js, and long load times/50MB scenes were reported), which Babylon's own reps acknowledge and only partially address via incremental loading. Missing for 10: independent verification of actual bundle sizes after tree-shaking, benchmarked WebGPU performance/adoption data, and confirmation that payload complaints have been resolved in recent versions.
- [claimed-docs] “WebGL and WebGPU rendering support”
- [claimed-docs] “WebGPU Support: Next-generation graphics API”
- [claimed-docs] “NPM packages for all modules”
- [claimed-docs] “Modular design with tree-shakable ES6 modules”
- [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
- [community] “demos look quite nice but wow they take a long time to load, took about 5 minutes to download 50mb for a short scene, makes me wonder if dow…”
- [community] “To avoid having too long loading time, we have support for incremental loading. But we definitely need to work on optimizing the size of our…”
web developerThe engine installs from a package registry into my existing toolchain — a library I import, bundle, and tree-shake like any dependency
weight 2 · round drawnthree.js is published on npm (12M+ weekly downloads, MIT license per registry probe) and is widely used as an ES module import (importmap pattern shown in docs), consistent with standard bundler/tree-shaking workflows; community feedback confirms TypeScript compatibility and typical dependency usage patterns. Missing for 10: no explicit first-party documentation or evidence specifically confirming tree-shaking behavior/bundle-size optimization guidance.
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view three version` → 0.186.0, and the public npm downloads API reports 12,206,532 weekly download…”
- [claimed-docs] “CORRECT - modern pattern (always use latest version): html <script type="importmap">”
- [community] “Btw three.js works flawlessly with Typescript too in case anyone is interested.”
- [community] “there are some function signatures that don't match what's in the code using @types/three, and mrdoob does not want to maintain this. This g…”
- [community] “THREE.js adds a nice layer of abstraction atop that metal [WebGL].”
Babylon.js ships as NPM packages (@babylonjs/core, confirmed live on npm registry with real version/downloads), documents ES6 module support, and explicitly advertises a modular, tree-shakable ES6 architecture for bundlers. TypeScript support with full IntelliSense further confirms standard toolchain integration. Missing for 10: independent third-party benchmark/case study of tree-shaking effectiveness in a real bundler beyond vendor docs.
- [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
- [claimed-docs] “NPM packages for all modules”
- [claimed-docs] “Modular design with tree-shakable ES6 modules”
- [claimed-docs] “TypeScript support with full IntelliSense”
- [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
Scripting — writing the game — languages, visual scripting, iteration speedScripting
Writing the game — languages, visual scripting, iteration speed
Iteration
game developerThe edit-run loop is fast — hot reload or near-instant preview after a script change
weight 2 · round to Babylon.jsthree.jsnone0/10three.js is a rendering library, not a game engine or dev environment with a build/watch pipeline; no evidence in the pack of any hot-reload, live-reload, or fast edit-run tooling shipped by the project itself (only unrelated docs, editor mentions, and API references).
Babylon.js offers a Playground for instant in-browser code iteration and NullEngine/headless testing, which supports fast preview cycles, but there is no evidence of actual hot-reload tooling (e.g., a dev server with HMR for local project scripts) or documentation describing an edit-run loop for typical game-dev workflows outside the Playground sandbox. missing for 10: dedicated hot-reload/watch tooling for local script changes, first-party dev-server integration, independent hands-on confirmation of near-instant reload during real project development.
- [claimed-docs] “Playground: Interactive code editor and sharing”
- [claimed-docs] “Playground: Interactive code editor at playground.babylonjs.com”
- [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
- [claimed-docs] “Inspector: Visual debugging and scene editing”
Language
game developerThe primary scripting language is productive and fully exposes the engine API, with a debugger behind it
weight 3 · round drawnThree.js is a plain JavaScript/TypeScript library, so the 'scripting language' is JS itself, giving full, direct access to the entire engine API with no separate scripting sandbox or restricted binding layer (threejs-gh-1, threejs-gh-4). Debugging is supported via standard browser devtools plus a dedicated official Chrome three.js DevTools extension (threejs-docs-8), and TypeScript works well though community reports note occasional @types/three signature mismatches requiring ts-ignore (threejs-comm-4, threejs-comm-5). Missing for 10: deeper first-party documentation of the debugger extension's capabilities and stronger independent corroboration of TypeScript API completeness.
- [github] “const renderer = new THREE.WebGLRenderer( { antialias: true } ); renderer.setSize( width, height );”
- [github] “This code creates a scene, a camera, and a geometric cube, and it adds the cube to the scene. It then creates a `WebGL` renderer for the sce…”
- [claimed-docs] “[devtools](https://chromewebstore.google.com/detail/threejs-devtools/jechbjkglifdaldbdbigibihfaclnkbo)”
- [community] “Btw three.js works flawlessly with Typescript too in case anyone is interested.”
- [community] “there are some function signatures that don't match what's in the code using @types/three, and mrdoob does not want to maintain this. This g…”
Babylon.js uses JavaScript/TypeScript as its scripting language, with full TypeScript IntelliSense exposing the entire engine API (babylonjs-docs-12), and ships the Inspector/Scene Inspector for runtime debugging plus community corroboration of the Spector WebGL debugger extension making development easier (babylonjs-docs-13, babylonjs-docs-20, babylonjs-comm-10). Community testimonials also confirm productive TS integration in real projects (babylonjs-comm-17). missing for 10: independent benchmarking of scripting productivity vs other engines, deeper evidence the debugger covers full script-level breakpoints/stepping (vs just WebGL call inspection), and first-party docs explicitly tying TypeScript API completeness to debugger workflow.
- [claimed-docs] “TypeScript support with full IntelliSense”
- [claimed-docs] “Inspector: Visual debugging and scene editing”
- [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
- [community] “The impressive thing about Babylon.js is Spector, a fully functional WebGL debugger extension in Chrome which makes 3D development on the we…”
- [community] “Babylon is awesome! I just started writing a game with it. The integration with TypeScript works well and there also are very fun things lik…”
Visual
technical artistBuild gameplay logic with visual scripting without writing code
weight 2 · round drawnthree.jsnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Babylon.jsnone0/10Evidence shows a Node Material Editor (visual shader/material editor) and a code-based Playground, but nothing about a visual scripting system for gameplay logic (e.g., a node-based behavior/flow graph) that would let a technical artist avoid writing code for game logic.
- [claimed-docs] “Node Material Editor”
- [claimed-docs] “Node Material Editor: Visual shader editor at nme.babylonjs.com”
- [claimed-docs] “Playground: Interactive code editor and sharing”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparablethree.jsn/athree.js is a 3D graphics library, not an agent or platform that consumes external tools via MCP; the evidence explicitly confirms no MCP server exists and coding agents just use the library directly through npm. This axis is a category error for a rendering library.
- [probe] “PROBE runtime (recorded 2026-09-15): threejs.org publishes llms.txt at the site root pointing to a docs llms.txt that carries a literal '## …”
Babylon.jsn/aBabylon.js is a 3D rendering/game engine library, not an AI agent or agent-orchestration platform; consuming MCP tool servers is not a fair axis for this kind of product. The negative probe confirms no MCP ecosystem exists, reinforcing this is out of category rather than a failed capability.
- [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · not comparablethree.jsn/athree.js is a client-side 3D rendering library with no API/service surface requiring credentials; scoped credential issuance is not a relevant axis for this kind of product.
ai-native userSubscribe to events via webhooks
weight 2 · not comparablethree.jsn/athree.js is a client-side rendering library with no service/event backend; webhooks are a wrong-axis capability for this kind of product, not something buyers of a graphics library would expect.
game developerRun ML models inside the game — an official inference runtime for on-device model execution
weight 1 · not comparablethree.jsn/athree.js is a WebGL/WebGPU 3D rendering library, not an ML inference runtime; no evidence exists of an on-device model execution engine, and this axis is a category error for a rendering library rather than an applicable-but-unmet capability.
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparablethree.jsn/athree.js is a 3D rendering library, not a workflow/automation platform; scheduling recurring jobs is outside its category and irrelevant to a graphics engine's API surface.
ai-native userChoose where my data is stored (region/residency)
weight 2 · not comparablethree.jsn/athree.js is a client-side rendering library with no data storage/hosting component, so data residency/region choice is not an applicable axis for this product category.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparablethree.jsn/athree.js is a client-side 3D rendering library, not a data-processing or AI service that trains models on user data; data-training opt-out is not an applicable axis for this product category.
ai-native userControl data retention and deletion
weight 2 · not comparablethree.jsn/athree.js is a client-side rendering library, not a data-processing service or platform that stores/retains user data; data retention/deletion controls are not an applicable axis for this kind of product.
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparablethree.jsn/athree.js is a client-side rendering library with no telemetry, network service, or usage-tracking component to opt out of; this privacy-posture axis applies to hosted services/SaaS tools, not a self-contained open-source graphics library.