Three.js проти Rust/WGPU для швидких AI-демо
Three.jsRustWGPU
Three.js швидше перетворює ідею на робочу сцену
Я б не ускладнював старт: для браузерного прототипу Three.js дає найкоротший шлях від ідеї до робочої сцени. В оригінальному обговоренні один учасник прямо зазначив, що Three.js впорався з демо, хоча набір асетів був обмеженим. Інший оцінив більш відполіровану версію на ігровому рушії у 8–10 годин і кілька ітерацій за наявності бібліотеки шейдерів.
Технічно це логічно. Документація Three.js для ShaderMaterial описує можливість підключати власні вершинні та фрагментні шейдери без потреби будувати навколо них увесь рендерер. Сцена, камера, матеріали й типова інфраструктура вже є, тому основний час можна витратити на світло, композицію, процедурні ефекти та поведінку камери.
Rust/WGPU пропонує протилежний обмін: більше контролю, більше роботи. Документація wgpu та її добірка прикладів показують явне керування GPU-ресурсами, пайплайнами, синхронізацією, compute-завданнями й HDR-поверхнями. Це сильна база для незвичного змішування, обчислювальної генерації геометрії або власної архітектури рендерингу, але асети, абстракції та правила рушія доведеться створювати окремо.
Unity та Unreal займають проміжну позицію: вони мають зрілі редактори й готовий виробничий конвеєр без необхідності писати рушій, але є важчими для легкого браузерного демо. Дату самого обговорення не вказано, тому його варто сприймати як інженерний розбір станом на 27 вересня 2026 року, а не як анонс нової технології.
Нестандартний вигляд починається не з вибору API
Головний висновок простий: Three.js економить час, а Rust/WGPU дає контроль ціною розробки інфраструктури. Для разового вебпрототипу другий шлях легко перетворюється на роботу над рушієм замість роботи над візуальною ідеєю.
Водночас сам WGPU не рятує від шаблонної картинки. Характер створюють структура шейдерів, освітлення, варіативність текстур, камера, постобробка та якість асетів. У показаному WebGL-демо обмеження вже проявилося саме на рівні асетів, а не в здатності Three.js вивести сцену.
Прямих порівняльних бенчмарків у доступних матеріалах немає, тому називати один стек швидшим за інший було б перебільшенням. Варто дивитися на момент, коли готові абстракції починають заважати потрібному ефекту. Саме цей поріг, а не назва API, визначає, чи вийде виразна графіка, чи ще одна акуратна заготовка.