FAQ

Is Meep open source?

No. Meep is source-available - you receive and can read the full source of the engine, but usage is governed by a proprietary license. It was briefly open-source around 2018; the codebase has since returned to closed-source under commercial licensing.

If you’ve worked with Unreal Engine’s license model, the structure is similar: source available, commercial use under license.

How does Meep compare to Three.js?

Three.js is a rendering library. Meep is a full game engine - ECS, asset streaming, audio, input, save/load, UI, AI, physics, terrain, particles, scene management - and it renders through Shade, its own renderer, which ships in the same package under src/shade/. Three.js is not a dependency, a peer, or an optional extra: no module in the engine imports it.

That changes the comparison rather than ending it. Three.js is a WebGL-and-WebGPU library that draws what you tell it to draw, node by node. Shade is WebGPU-only and GPU-driven: geometry is meshlet-clustered and lives GPU-resident, culling runs on the GPU, and the rasterizer writes a visibility buffer and a G-buffer instead of shading as it draws. You get less say over individual draw calls and a great deal more scene for the same frame budget.

You’d reach for Three.js if you need to draw 3D geometry and that’s it, or if you need to run on WebGL. You’d reach for Meep if you’re building a game, you’d rather not write the surrounding 90% from scratch, and you can require WebGPU.

If you have a Meep 2.x project, see the migration guide.

Does Meep run without WebGPU?

No. Meep 3 is WebGPU-only. There is no WebGL path, no fallback renderer, no degraded quality tier - below the floor, startup fails cleanly rather than producing a worse picture.

The floor is specific. Shade requires the adapter features indirect-first-instance and float32-blendable, at least 10 storage buffers per shader stage, and 32 bytes of colour-attachment budget per sample. A missing navigator.gpu throws a plain Error; everything below the floor throws a ShadeDeviceFailure (src/shade/device/ShadeDeviceFailure.js) carrying a reason from ShadeDeviceFailureReason. Catch both. A device that is lost later is not recovered - graphics.on.contextLost fires, contextRestored never does, and the honest response is a message and a reload.

In practice the floor is higher than the WebGPU spec alone implies: Shade’s shaders use the WGSL immediate_address_space language extension, which shipped in Chrome 149/150. A browser below that acquires a device successfully and then fails to dispatch shaders. Verified: Chromium 148 fails, Chrome 151 runs.

WebGPU itself is not the narrow part: it has been Baseline since January 2026, shipping in Chrome and Edge 113+, Safari 26+ and Firefox 141+. The language extension is - it is a Chromium feature today. So the practical answer is Chrome, Edge and other Chromium browsers at 149 or newer. Firefox and Safari have WebGPU but not that extension, which is the same position Chromium 148 is in - a device, and then a shader that will not dispatch. We have measured that on Chromium 148 and not on the other two, so treat them as unsupported rather than as tested failures. Check caniuse.com/webgpu for the baseline, and test the extension itself with navigator.gpu.wgslLanguageFeatures.has("immediate_address_space").

How does Meep compare to Babylon.js or PlayCanvas?

The main differences are architectural rather than feature-by-feature:

• Meep is pure ECS; Babylon and PlayCanvas are scene-graph + OOP.
• Meep is code-first. It does ship an editor (editor/, see architecture), but it is something you attach to a running engine, not the way you’re expected to build a game. The alternatives are editor-first.
• Meep is WebGPU-only; both alternatives still run on WebGL.
• Meep prioritizes zero-allocation patterns and bundle size.

If you want an editor-centred workflow and a polished onboarding ramp, the alternatives are better choices. If you want full control of architecture, the smallest possible runtime, and a GPU-driven renderer, Meep is the closer fit.

Why JavaScript and not WebAssembly?

Two reasons, both structural.

Debuggability. JavaScript is the only debuggable language on the web. Every browser ships a real debugger for it - source maps, live values, the full DOM. WebAssembly debugging is still effectively binary inspection: no readable variables, no useful symbols, painful stepping. For an engine you’re going to stare at for years, that’s a non-starter.

Integration. WASM has no dynamic linking. You receive an already-compiled binary; you can’t include parts of it at the source level, you can’t recompile it together with your own code, you can’t extend it from the inside. And every interaction with the page - DOM, input, assets, audio, network - has to go through a JavaScript shim anyway, because that’s the only thing the browser exposes. Engines that ship as WASM are wrapping JS shims around a black box and asking you to live inside that arrangement. It’s a fundamentally flawed integration paradigm for the web, and many engines pay for it.

TypeScript has a milder version of the same asymmetry: TS can consume JavaScript happily, but JavaScript can’t directly consume TS without a compile step. JavaScript is the lowest common denominator on the web - the most universal way for a library to be usable by anyone on the platform, including TS users.

Meep is JavaScript because JavaScript is what the web is. Where WebAssembly earns its keep - narrowly-scoped number-crunching like a physics solver - you can call into it from Meep code without turning the whole engine into a black box.

Can I use TypeScript?

Yes. The engine source itself is JavaScript with JSDoc annotations, and TypeScript declarations are generated by the build (npm run generate-types) and picked up by any standard TS setup.

The reason the engine is JS-with-JSDoc rather than written in TypeScript is the asymmetry mentioned above: TS code can consume JS, but JS code can’t directly consume TS without compilation. Authoring in JS keeps the engine usable from both worlds with zero friction.

What platforms does Meep target?

Web first, on WebGPU. A rendering Meep 3 build needs a browser that meets the device floor described above - in practice Chromium 149 or newer. For desktop and mobile shipping, wrap with Electron, Tauri, Capacitor, or a similar shell, and check that the shell’s bundled engine is new enough; there are commercial Steam titles shipping using exactly that pattern.

The non-rendering half of the engine has no such requirement. ECS, physics, navigation, AI, generation, networking and serialization don’t import the graphics modules, so a headless simulation, a dedicated server, or a bot runs on Node (>= 24) with no GPU at all.

Is there a community / forum / Discord?

Not at the moment. Running a forum is a real time investment we’d rather spend on the engine. Email is the right channel for now - see /contact.

What if I need a feature that isn’t there?

Free and Indie tiers: work around it in your project code or fork what you need locally. Standard: same, plus you can raise it over email. Enterprise can purchase dedicated hours for specific feature work in writing.

I have a license question not covered here.

Email us. We read everything.