babylonjs/editor

Purpose and entry points

Babylon.js Editor 5 is a cross-platform Electron desktop editor for authoring Babylon.js 3D scenes, assets, scripts, rendering settings, and exports. Its primary application entry surfaces are the Electron/editor bootstrap and React UI: editor/src/index.ts, editor/src/electron/events/editor.ts, and editor/src/editor/main.tsx. Root build orchestration is build.mjs; the repository uses Yarn Classic and TypeScript.

Desktop process boundary

The editor separates Electron main-process responsibilities—window lifecycle, native dialogs, shell integration, export IPC, OAuth, custom protocols, and model-conversion workers—from renderer-side authoring UI. Core boundary paths are editor/src/electron/events/window.ts, editor/src/electron/events/export.ts, and editor/src/electron/protocol.ts. Renderer code uses IPC-facing utilities rather than directly owning native capabilities; native dependencies including node-pty and Assimp support require platform-native builds.

Scene authoring and interactive UI

The renderer is a large React/TypeScript workspace organized around a persistent editor layout, Babylon scene preview, hierarchy/graph, inspector, asset browser, animation/cinematic tools, navmesh, and ragdoll workflows. Primary composition paths are editor/src/editor/layout.tsx, editor/src/editor/layout/preview.tsx, and editor/src/editor/layout/inspector.tsx. Commands and inspector controls mutate the in-memory Babylon scene; common operations are centralized under editor/src/project/add/ and editor/src/tools/.

Project persistence, import, and export pipeline

Projects are stored as editor scene/assets structures and reconstructed through staged loading plugins. Load flow prepares a scene, loads its configuration/resources, then installs typed plugins for cameras, meshes, materials, animation, particles, skeletons, and related entities: editor/src/project/load/load.tsx, editor/src/project/load/scene.ts, and editor/src/project/load/plugins/meshes.ts. Save/export serializes the scene and assets, including textures, materials, physics, LODs, scripts, and KTX/KTX2 options: editor/src/project/save/scene.ts, editor/src/project/export/export.tsx, and editor/src/project/export/assets.ts.

Runtime library and generated applications

tools/ is the reusable runtime-facing Babylon.js support library used by exported projects: decorators/scripts, scene loading, asset/database/container loading, rendering pipelines, physics, and cinematic playback. Its public entry and key stages are tools/src/index.ts, tools/src/loading/loader.ts, and tools/src/cinematic/cinematic.ts. Templates package editor-authored assets with starter applications for Electron, Next.js, Nuxt, Solid, and vanilla JS; representative paths are templates/electron/src/electron/main.mts, templates/nextjs/src/app/page.tsx, and templates/vanillajs/src/main.ts.

CLI, automation, and integrations

The CLI performs headless project packaging/export work, gathering scene resources and processing assets/textures, including KTX/KTX2, with optional S3 integration: cli/bin/babylonjs-editor-cli.js, cli/src/pack/pack.mts, and cli/src/s3/s3.mts. MCP is a separate Node-side tool server that translates agent tool requests into editor actions; the transport/tool contract spans mcp/src/index.mts, mcp/src/request.mts, and editor-side editor/src/mcp/mcp.ts. Marketplace integrations target AmbientCG, Poly Haven, Sketchfab, plus optional FAB and Quixel plugins: editor/src/tools/marketplaces/registrations.ts, plugins/fab/src/index.tsx, and plugins/quixel/src/index.ts.

Website and distribution

website/ is a separate Next.js marketing, documentation, download, and experiment/conversion application, not the editor runtime. Its key entry/API boundaries are website/src/app/page.tsx, website/src/app/api/converter/route.ts, and website/src/app/renderer.tsx. Download URLs point to DigitalOcean Spaces; website conversion endpoints invoke Assimp/Blender-oriented conversion code. Platform packaging produces signed or unsigned Electron artifacts and must run on compatible OS environments because of native modules.