Three.js vs Babylon.js vs PixiJS: что выбрать для браузерной игры

Неправильно выбранный рендер-стек вбрасывает месяцы разработки в мусор и сжигает FPS на мобильных. Это заметно именно сейчас: игроки уходят при первом фризе, WebGPU стучится в прод, а бюджеты на UA режут на уровне одной неудачной недели.

Короткий ответ: PixiJS — для 2D и «быстрых» казуалок с плотной UI; Three.js — гибкая основа под кастомный 3D и R&D; Babylon.js — когда нужен из коробки серьёзный 3D (PBR, инструменты, WebXR/WebGPU) и быстрая поставка контента. Далее — глубокие технические нюансы, где выбор реально решает.

Когда что брать: быстрый маппинг по задачам

• Вы делаете 2D-экшен, карточную, idler, матч-3, визуально насыщенную UI-игру, нужна тесселяция тайлов, инвентарей, спрайтовые эффекты и плавные шейдерные фильтры — берите PixiJS. Он прост, предсказуем и отлично работает с атласами, Spine/DragonBones и фильтрами.
• Интерактивная 3D-визуализация, казуальная 3D-игра, нестандартные шейдеры/материалы, tight-интеграция с React/Vue, обилие плагинов и туториалов — Three.js. Это «конструктор» 3D-графики: много свободы, но именно вы склеиваете постпроц, лоадеры и GUI.
• Полноценная 3D-игра с PBR, тенями, узлами материалов, нужны инструменты в духе «игрового движка» (инспектор, узловые материалы, GUI, физика, WebXR), возможен ранний заход на WebGPU — Babylon.js ускорит time-to-fun и даст ровный DevEx.

В реальных проектах мы часто начинаем с прототипа на PixiJS (2D) или Three.js (3D), а при подтверждении фичсета и контент-пайплайна переключаемся на Babylon.js, если нужна «движковая» зрелость и прод-инструменты. И наоборот: если 3D — это 2–3 меша и немного теней, держим Three.js и не усложняем. Как говорится, сложность любит размножаться — и ей не стоит помогать (если хотите углубиться, почитайте про минимизацию сложности: Out of the Tar Pit).

Рендер и материалы: качество картинки против контроля

WebGL2 и WebGPU

• PixiJS — фокус на WebGL2 (с достойным фоллбеком), стройный пайплайн под 2D, батчинг и фильтры.
• Three.js — зрелый WebGL2, экспериментальный WebGPU-рендерер существует, но в проде его используют точечно.
• Babylon.js — зрелая поддержка WebGL2 и продовый путь к WebGPU (с фоллбеком), включая материалки и постпроц.

Если целевая аудитория — десктопы и свежие мобильные, Babylon может дать прирост от WebGPU (более прогнозируемая компиляция шейдеров, меньше драйверных сюрпризов), но планируйте фоллбек на WebGL2.

Материалы, PBR и постпроцессинг

• PixiJS: материалы минималистичны (спрайтовая модель), зато фильтры — быстрые и удобные. Отлично для 2D-эффектов.
• Three.js: Physically Correct Lights, MeshStandardMaterial, MeshPhysicalMaterial, glTF 2.0 PBR, богатая экосистема шейдеров и EffectComposer.
• Babylon.js: сильный PBR (PBRMaterial), нодовая система материалов, HDRI/IBL, бокс из постпроцессинга, готовая интеграция с Shadow DOM? (в смысле — GUI-оверлеи через BJS GUI).

Если нужен «консольный» блеск (в рамках браузера), Babylon.js позволит быстрее довести картинку. Если нужен полный контроль шейдеров, Three.js — привычнее и гибче. PixiJS — король спрайтов и 2D эффектиков без боли.

Референсная архитектура браузерной игры

Типовой прод-стек, который мы видим как «безопасную» основу:

• Бандлинг: Vite или Rollup, TypeScript, динамический импорт сцен/уровней.
• Рендер-движок: PixiJS для 2D, Three.js/Babylon.js для 3D.
• ECS: bitecs или ecsy для отделения логики от сцены (не путать движок рендера с геймплейной архитектурой).
• Физика: 2D — Matter.js/Planck.js; 3D — cannon-es, Ammo.js или Rapier (WASM) для производительности.
• Сети/мультиплеер: WebSocket (Colyseus/Socket.IO), репликация состояния с лаг-компенсацией; для P2P мини-игр — WebRTC DataChannel.
• Ассеты: glTF 2.0 (Draco), текстуры KTX2/BasisU, для 2D — атласы (TexturePacker), Spine.
• Аналитика/крэш-репортинг: Sentry, PostHog; логирование — Logtail/ELK; метрики — Grafana + Prometheus (через бекенд).
• CDN и декомпрессия: Cloudflare/Akamai, brotli/gzip, HTTP/2/3, кеш-версирование.

Поток данных:

• На загрузке — детект GPU-уровня (по расширениям/бенчмарку) и конфиг качества: разрешение, тени, SSAO/блум.
• Ассеты подгружаются чанками; текстуры — в KTX2, меши — Draco; UI и туториалы — отдельным бандлом, чтобы не держать хардкор-ассеты в первом скрине.
• Игровая логика — ECS-такт каждые ~16.6 мс; рендер — синхронизируется через requestAnimationFrame; сетевые апдейты — тик каждые 50–100 мс с интерполяцией на клиенте.

GPU любит порядок, как бухгалтер — лишние draw calls и разномастные стейты портят настроение и кадры.

Производительность: бюджет кадра, текстуры, анимации

Бюджет кадра

• 60 FPS = 16.6 мс на кадр; 30 FPS = 33.3 мс. Из них часть съедает логика, GC и сетевой слой; рендер нужно держать < 10–12 мс для 60 FPS на среднем устройстве.
• Мобильные: тратьте меньше 6–8 мс на GPU-сторону, иначе дропы попадут на глаза.

Практика:

• Бейтесь за снижение draw calls через батчинг (Pixi), инстансинг (Three/Babylon), мердж мешей.
• Предгружайте и «разогревайте» шейдеры (Babylon: SceneLoader, Material prewarm; Three: прогрев через рендер невидимой сцены). Избегайте компиляции в момент‑нажатия кнопки.
• Текстуры: конвертируйте в KTX2/BasisU, используйте mipmaps, следите за анизотропной фильтрацией.
• Анимация: ограничивайте количество костей и одновременно проигрываемых анимаций; для толп — GPU instancing + простые вертексные деформации.

Инструменты:

• Spector.js для инспекции WebGL команд.
• Chrome DevTools Performance + WebGL Insights; профайлинг с таймлайном рендера.
• На проде — фрейм-метрики и «динамический даунскейл» (понижаем DPR и/или эффекты по телеметрии).

Форматы ассетов и пайплайн

• glTF 2.0 с PBR, анимацией; сжатие геометрии Draco, текстур — BasisU/KTX2. Тени — atlas разумного размера.
• Для 2D: атласы TexturePacker или Spine атласы; спрайтлист — лучше несколько тематических атласов, чем один гигант.

WebGPU зрелость

• Babylon.js — практичный путь с фоллбеком. Имеет смысл для high-end графики и предсказуемости в драйверах.
• Three.js — экспериментально, используйте, если осознаёте, что придётся допиливать и держать два пайплайна.
• PixiJS — крепкий WebGL2 сегодня; WebGPU — перспектива, но не якорь для принятия решений в 2D сейчас.

Физика, анимации, GUI и интеграции

Физика

• PixiJS: 2D — Matter.js (простая, быстрая), Planck.js (Box2D-подобная, точнее). Простые коллизии — хитбоксы без физики.
• Three.js: cannon-es (JS), Ammo.js (Bullet через wasm), Rapier (rust->wasm, быстро и приятно). Для сетевых — детерминированность важнее «фотореализма столкновений».
• Babylon.js: интеграции с Cannon/Ammo/Oimo, есть удобные обёртки, коллизии/пикинг.

Анимации

• glTF скелетная анимация — поддерживается Three и Babylon. Оптимизируйте количество клипов и ключей, используйте baked anim там, где можно.
• 2D: Spine/DragonBones — просто летят в Pixi; в Three/Babylon — только через пользовательские слои/плагины или как плоские меши/шейдеры.

GUI/оверлеи и UX

• PixiJS: всё — это сцена, UI — родной «игровой» слой. Рендер UI дёшев.
• Three.js: UI — обычно HTML/CSS поверх канваса (React, Vue) или сторонние решения; world-space UI — кастомные плоскости/шейдеры.
• Babylon.js: GUI 2D/3D — встроенный модуль @babylonjs/gui, быстрый путь к менюшкам и HUD.

Экосистема и DevEx

• PixiJS: минимальная «магия», короткий цикл от идеи до экрана. React-Pixi для интеграции с React.
• Three.js: гигантская экосистема (react-three-fiber, drei, loaders, постпроц), «игровой движок» собираете сами.
• Babylon.js: Playground, Inspector, ноды материалов, готовые постпроц-пайплайны, WebXR. Меньше кода-клея.

Сравнительная таблица: компромиссы и упакованные решения

Минимальные шаблоны: старт за 60 секунд

Three.js: сцена, камера, инстансинг

import * as THREE from 'three';

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(60, innerWidth/innerHeight, 0.1, 100);
camera.position.set(0, 1.5, 4);

const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(innerWidth, innerHeight);
document.body.appendChild(renderer.domElement);

const light = new THREE.DirectionalLight(0xffffff, 1);
light.position.set(3, 5, 2);
scene.add(light);

// Инстансинг для производительности
const geometry = new THREE.BoxGeometry(0.2, 0.2, 0.2);
const material = new THREE.MeshStandardMaterial({ color: 0x66ccff });
const mesh = new THREE.InstancedMesh(geometry, material, 1000);
const dummy = new THREE.Object3D();
for (let i = 0; i < 1000; i++) {
  dummy.position.set((Math.random()-0.5)*10, (Math.random())*2, (Math.random()-0.5)*10);
  dummy.updateMatrix();
  mesh.setMatrixAt(i, dummy.matrix);
}
scene.add(mesh);

function onResize() {
  camera.aspect = innerWidth/innerHeight;
  camera.updateProjectionMatrix();
  renderer.setSize(innerWidth, innerHeight);
}
window.addEventListener('resize', onResize);

renderer.setAnimationLoop(() => {
  mesh.rotation.y += 0.01;
  renderer.render(scene, camera);
});

Babylon.js: PBR, шадоумапы и GUI

import { Engine, Scene, ArcRotateCamera, Vector3, HemisphericLight, MeshBuilder, PBRMaterial, Color3 } from '@babylonjs/core';
import '@babylonjs/loaders';
import '@babylonjs/gui';

const canvas = document.createElement('canvas');
document.body.appendChild(canvas);
const engine = new Engine(canvas, true);
const scene = new Scene(engine);

const camera = new ArcRotateCamera('cam', Math.PI/4, Math.PI/3, 6, Vector3.Zero(), scene);
camera.attachControl(canvas, true);

new HemisphericLight('hemi', new Vector3(0, 1, 0), scene);

const box = MeshBuilder.CreateBox('box', {}, scene);
const pbr = new PBRMaterial('pbr', scene);
pbr.albedoColor = new Color3(0.2, 0.7, 1.0);
pbr.metallic = 0.2; pbr.roughness = 0.4;
box.material = pbr;

engine.runRenderLoop(() => scene.render());
window.addEventListener('resize', () => engine.resize());

PixiJS: спрайты, фильтры и батчинг

import { Application, Sprite, Assets, ColorMatrixFilter } from 'pixi.js';

const app = new Application({ resizeTo: window, antialias: true, backgroundColor: 0x0d0d0d });
document.body.appendChild(app.view as HTMLCanvasElement);

await Assets.load('player.png');
const player = Sprite.from('player.png');
player.anchor.set(0.5); player.x = innerWidth/2; player.y = innerHeight/2;

const filter = new ColorMatrixFilter();
filter.desaturate();
player.filters = [filter];

app.stage.addChild(player);
app.ticker.add((dt) => { player.rotation += 0.02 * dt; });

Что ломается в продакшене

• Драйверные странности и Safari iOS: WebGL2 не везде одинаков, расширения отличаются. Планируйте фич-флаги и фоллбеки (теням понижаем качество, убираем SSAO на слабых).
• Потеря контекста (WEBGL_lose_context): держите обработчик и лёгкую перезагрузку рендера и ресурсов.
• Компиляция шейдеров в горячий момент: фризы при первом появлении эффекта. Прогревайте материалы при загрузке сцены.
• Память: утечки текстур и геометрий при частых переходах сцен — освобождайте буферы/текстуры явно (dispose()), используйте renderer.info (Three) и scene.getEngine().getFps()/инструменты (Babylon) для наблюдения.
• Мобильное аудио и взаимодействие: автоплей запрещён, запускайте звук после первого пользовательского ввода.
• DPI/ретина: масштабируйте DPR динамически, не рендерьте в 3×, если устройство еле держит 30 FPS.
• Сетевые лаги: интерполяция/экстраполяция обязательны; снепшоты состояния — пачками, с компрессией.

Сколько стоит и когда окупается

Цены и сроки сильно зависят от контента и геймдизайна, но практичные вилки для планирования бюджета:

• 2D-казуалка на PixiJS (прототип → софтлонч): 1–2 разработчика, 4–10 недель. Арт-пайплайн (атласы, анимации) — x0.5–x1 от времени кода. Плюс аналитика/AB.
• 3D-казуалка на Three.js (простая геометрия, базовые тени, минимальная физика): 2–3 разработчика, 8–16 недель. Бэк для прогресса/ивентов — ещё 2–4 недели.
• 3D midcore на Babylon.js (PBR, постпроц, физика, GUI, несколько биомов): 3–5 разработчиков, 3–6 месяцев. Здесь окупается встроенный инструментарий Babylon.

Основные драйверы стоимости:

• Ассеты и пайплайн (KTX2, LOD, LQA на устройствах) — дорогие, но экономят FPS и CDN.
• Сетевой слой (мультиплеер) — архитектурное решение upfront. Дешевле спроектировать правильно, чем переписывать.
• Инфраструктура доставки (CDN, кэш), аналитика и краш-репортинг — «незаметные» расходы, но окупаются снижением откатов и ускорением итераций.

Где можно сэкономить опасно:

• Отказ от компрессии текстур — сожжёте память и FPS.
• «Сделаем UI в 3D-мире, потому что красиво» — часто дороже и тяжелее, чем HTML/CSS или Pixi-слой.
• «Сразу WebGPU-only» — отрежете устройства и поймаете несовместимости. Держите фоллбек.

ROI складывается из ретенции и воронки до платежа/показа рекламы. Если игра фризит — метрики рушатся вне зависимости от маркетинга. Техническая дисциплина — это P&L, а не «перфекционизм инженеров».

Как мы выбираем стек под задачу (разбор по критериям)

1. Тип игры и визуальная цель:

• 2D/спрайты/UI — PixiJS.
• 3D-обзорки, кастомные шейдеры — Three.js.
• 3D с PBR/GUI/WebXR — Babylon.js.

1. Сроки и команда:

• Меньше опыта в 3D — Babylon снизит код-клей.
• Сильный шейдерщик — Three даст максимум свободы.

1. Девайсы и рынки:

• Mид/лоу-энд Android — Pixi или облегчённый Three, минимум постпроц.
• Десктоп/флагманы — Babylon с WebGPU фоллбеком и PBR.

1. Инфра и операционка:

• Нужно быстро инспектировать и править материалы «на лету» — Babylon Inspector удобен для геймдизайнера.
• Нужен tight React — react-three-fiber или react-pixi покрывают много сценариев.

FAQ

Можно ли сделать 3D-игру на PixiJS?

Да, как псевдо‑3D (изометрия, фейковые перспективы, бэк‑буферные трюки). Но для настоящего 3D с PBR и тенями — берите Three.js или Babylon.js.

Что выбрать для WebXR (VR/AR) в браузере?

Babylon.js даёт наиболее ровный DevEx для WebXR: быстрый старт и инструменты. Three.js тоже поддерживает WebXR, но больше сборки руками.

Какие движки лучше для мультиплеера?

Ни один из трёх не «сетевой» движок. Сетевой стек — Colyseus/Socket.IO/WebRTC, симуляция — ваша/физика, рендер — любой. Выбор движка рендера не решает неткод.

Что с размером бандла и загрузкой?

Все три движка поддерживают ESM и tree-shaking. Динамический импорт сцен/ассетов обязателен. Компрессия (brotli), сприт-атласы/KTX2 и CDN с кэшированием — базовый чеклист.

Есть ли смысл сразу ставить WebGPU?

Ставьте как опцию с фоллбеком. Сегодня он полезен в high-end 3D (Babylon), но без отсечения WebGL2 вы потеряете аудиторию.

Какая физика быстрее: cannon-es, Ammo.js или Rapier?

Rapier (wasm) обычно быстрее JS-альтернатив, но требует wasm-интеграции и аккуратной памяти. Ammo.js стабильно, но тяжелее по размеру. cannon-es проще, но слабее по точности.

Key takeaways

• PixiJS — лучший выбор для 2D/UI-heavy игр: дешёвый рендер, быстрый цикл, сильные фильтры и атласы.
• Three.js — гибкая база для 3D: богатая экосистема, контроль шейдеров/постпроц, но больше «клея» и решений на вас.
• Babylon.js — «движковая» скорость вывода 3D в прод: PBR, GUI, инспектор, WebXR/WebGPU c фоллбеком.
• Производительность — это пайплайн ассетов (KTX2/Draco), батчинг/инстансинг и прогрев шейдеров; без этого FPS упадёт независимо от движка.
• Планируйте фоллбеки по качеству и WebGPU, профилируйте Spector.js/DevTools, следите за памятью и контекстом WebGL.

Если вы строите браузерную игру и хотите трезво оценить стек и риски, MTBYTE может помочь с архитектурой, пайплайном ассетов и прод-оптимизацией. Напишите пару строк о проекте на /contact — вернёмся с планом без воды.