Case StudiesКейси

Cloud Pixel-Streaming Runtime for ArchvizХмарний Pixel-Streaming рантайм для archviz

ProblemЗадача

Real-estate clients need photoreal, interactive 3D scenes in the browser — no installs, no gaming hardware. One Unreal application has to serve many different architectural scenes, and new scenes arrive weekly from the art team. Rebuilding and redeploying the app for every scene would not scale. Клієнтам з нерухомості потрібні фотореалістичні інтерактивні 3D-сцени в браузері — без інсталяцій і ігрового заліза. Один Unreal-застосунок має обслуговувати багато різних сцен, і нові сцени приходять від артистів щотижня. Перезбирати і передеплоювати апку під кожну сцену — не масштабується.

Solution shapeФорма рішення

Key engineering decisionsКлючові інженерні рішення

• Scenes as cooked .pak files, mounted at runtime. The app never changes; content ships as self-contained .pak levels produced by the pipeline (Case 02). New scene = new file on storage.
• Сцени — це cooked .pak файли, змонтовані в рантаймі. Застосунок не змінюється; контент їде самодостатніми .pak-рівнями з пайплайна (кейс 02). Нова сцена = новий файл на сховищі.
• Ranged downloads (64 MB chunks). Whole-file downloads of large scenes caused out-of-memory failures; chunked HTTP range requests fixed peak memory and enabled accurate progress reporting.
• Завантаження діапазонами (по 64 МБ). Завантаження великих сцен одним запитом призводило до нестачі пам’яті; range-запити зняли піки пам'яті й дали точний прогрес-бар.
• HTTP caching: If-Modified-Since + LRU eviction. A returning session re-validates instead of re-downloading; the local cache evicts least-recently-used scenes under a disk budget.
• HTTP-кешування: If-Modified-Since + LRU-евікшн. Повторна сесія ревалідовує замість перекачування; локальний кеш витісняє найдавніше використані сцени в межах дискового бюджету.
• A JSON command protocol over the DataChannel: camera moves, sun/fog control, actor selection and transforms, material variants, scene-state save/undo with UTC timestamps, backbuffer photo capture, and diagnostics toggles (greyscale, Nanite visualization). The web UI owns the UX; the engine exposes capabilities.
• JSON-протокол команд через DataChannel: рухи камери, сонце/туман, вибір і трансформації акторів, варіанти матеріалів, збереження/undo стану сцени з UTC-мітками, фото з бекбуфера і діагностичні перемикачі (greyscale, візуалізація Nanite). Інтерфейс живе у вебі; движок надає можливості.
• An application framework on top of the runtime. Beyond streaming, the plugin ships the product systems: a POI framework, orbit and first-person camera pawns, an ambient crowd system and spline-based traffic, and a lighting manager — organized as typed C++ modules with data-driven configuration (Data Assets), so a new deployment is configured, not re-coded.
• Прикладний фреймворк поверх рантайму. Крім стрімінгу, плагін містить продуктові системи: фреймворк точок інтересу (POI), орбітальну камеру та камеру від першої особи, фонову crowd-систему і трафік по сплайнах, менеджер освітлення — це типізовані C++ модулі з data-driven конфігурацією (Data Assets), тож новий деплой конфігурується, а не переписується.
• World Partition for large residential scenes — hundreds of cells stream around the camera, keeping memory flat while whole districts stay explorable.
• World Partition для великих житлових сцен — сотні комірок стрімляться навколо камери: пам’ять лишається стабільною, а цілі квартали — доступними для огляду.
• Deterministic teardown between scenes — unmount, GC-flush and state reset so a long-lived cloud instance can switch scenes for hours without leaks; plus a reload broadcast to all co-viewers of a session.
• Детермінований teardown між сценами — розмонтування, чистка GC і скидання стану, щоб довгоживучий хмарний інстанс перемикав сцени годинами без витоків; плюс reload-бродкаст усім співглядачам сесії.

OutcomeРезультат

A single deployed Unreal application serves an entire catalog of client scenes; content updates require zero engineering involvement. Tagged stable v2.0, running in production. Один задеплоєний Unreal-застосунок обслуговує весь каталог клієнтських сцен; оновлення контенту не потребує інженерів взагалі. Тег stable v2.0, працює в продакшні.

Product branding omitted (NDA). Architecture described from my own implementation. Назви продукту прибрані (NDA). Архітектура описана з моєї власної імплементації.

One-Click Datasmith → .pak Content PipelineDatasmith → .pak пайплайн в один клік

ProblemЗадача

Artists model in 3ds Max. Turning a raw archviz scene into a shippable, optimized Unreal level used to take days of manual work per scene: import, fix pivots, dedupe meshes, rebuild materials, set up rendering, cook, package. At a weekly scene cadence this was the bottleneck of the whole platform. Артисти моделюють у 3ds Max. Перетворення сирої archviz-сцени на готовий оптимізований Unreal-рівень займало дні ручної роботи: імпорт, півоти, дедуплікація, перезбірка матеріалів, налаштування рендера, cook, пакування. За тижневого темпу сцен це було вузьким місцем усієї платформи.

Solution shapeФорма рішення

Key engineering decisionsКлючові інженерні рішення

• Two tools, one contract. The Max-side exporter guarantees clean input (geometry cleanup, baked materials, named cameras) so the UE-side plugin can run fully unattended. The exporter is modular — separate pipeline stages for cleanup, baking, camera export — with both a PySide GUI for artists and a headless runner for the render farm.
• Два інструменти, один контракт. Експортер на боці Max гарантує чистий вхід (очищена геометрія, запечені матеріали, іменовані камери), тож UE-плагін працює повністю без нагляду. Експортер модульний — окремі стадії очищення, запікання, експорту камер — з PySide GUI для артистів і headless-запуском для ферми.
• Mesh deduplication + pivot normalization before Nanite: raw exports carry thousands of duplicated meshes with arbitrary pivots, which break instancing and inflate cook size.
• Дедуплікація мешів + нормалізація півотів перед Nanite: сирі експорти несуть тисячі дубльованих мешів з довільними півотами — це ламає інстансинг і роздуває розмір білда.
• Master-material instancing: imported materials are replaced with instances of a small master set, collapsing shader permutations and enabling global look-dev changes after delivery.
• Майстер-матеріали: імпортовані матеріали замінюються інстансами невеликого майстер-набору — менше шейдерних перестановок і можливість глобального look-dev після здачі.
• Scene description extracted into Data Assets (meshes, lights, cameras, variants) so both the runtime and the web UI can reason about scene contents without loading the level.
• Опис сцени виноситься в Data Assets (меші, світло, камери, варіанти), щоб рантайм і веб-UI могли працювати зі змістом сцени, не завантажуючи рівень.
• Optimization as tooling, not heroics: a suite of 30+ Python editor scripts runs "optimization waves" over finished scenes — trimming Nanite settings where they hurt, batch-optimizing textures to budget, disabling Nanite on glass, and reporting GC/memory — so scene weight is managed by repeatable passes with measurable results instead of hand-tuning.
• Оптимізація як інструмент, а не героїзм: набір з 30+ Python-скриптів редактора проганяє «хвилі оптимізації» по готових сценах — підрізає налаштування Nanite там, де вони шкодять, пакетно зводить текстури до бюджету, вимикає Nanite на склі та звітує по GC і пам’яті. Вага сцени контролюється повторюваними прогонами з вимірюваним результатом, а не ручним тюнінгом.
• Headless everything: plugin runs from an editor startup script; packaging goes through RunUAT; the entire path can execute on a build machine. An IoStore migration was prototyped, measured, and rolled back — a deliberate stability-over-novelty call.
• Headless усе: плагін стартує зі скрипта редактора; пакування — через RunUAT; весь шлях виконується на білд-машині. Міграцію на IoStore прототипували, заміряли і відкотили — свідомий вибір стабільності замість новизни.

OutcomeРезультат

Scene preparation went from days of manual editor work to a largely unattended pipeline run. Artists ship scenes without touching engine internals; engineering time goes to the platform, not per-scene fixes. Підготовка сцени скоротилася з днів ручної роботи в редакторі до майже автономного прогону пайплайна. Артисти здають сцени, не торкаючись движка; час інженерів іде на платформу, а не на разові фікси.

Product branding omitted (NDA). Architecture described from my own implementation. Назви продукту прибрані (NDA). Архітектура описана з моєї власної імплементації.

Web ↔ Engine: Driving Unreal from the BrowserWeb ↔ Engine: керування Unreal з браузера

ProblemЗадача

The pixel stream delivers pixels — but a sales tool needs real product UX on top: browsing units with filters, saving looks, sharing a session with a colleague, switching interior styles. That UX must live in the web app, while the source of visual truth stays in the engine. Pixel stream доставляє пікселі — але інструменту продажів потрібен справжній продуктовий UX: перегляд квартир з фільтрами, збереження виглядів, спільна сесія з колегою, перемикання стилів інтер'єру. Цей UX має жити у веб-застосунку, а джерело візуальної правди — в движку.

Key engineering decisionsКлючові інженерні рішення

• The engine exposes capabilities; the web owns the UX. All UI is HTML/React — crisp text, accessibility, instant iteration — talking to UE via the JSON DataChannel protocol from Case 01. Web teams iterate on the funnel without ever opening Unreal.
• Движок віддає можливості; веб володіє UX. Увесь UI — HTML/React: чіткий текст, доступність, миттєва ітерація — спілкується з UE через JSON-протокол з кейсу 01. Веб-команда ітерує воронку, не відкриваючи Unreal.
• Scene-state saves as first-class objects: a saved "look" (camera + lighting + variants) is data the web app lists, previews and restores; timestamps normalized to UTC to behave across timezones.
• Збереження стану сцени як повноцінні об'єкти: збережений "вигляд" (камера + світло + варіанти) — це дані, які веб показує, прев'юїть і відновлює; мітки часу в UTC, щоб працювало між часовими поясами.
• Real-time co-viewing: several users watch the same stream; presence and control passing are handled at the web layer (Liveblocks), and an engine-side reload broadcast keeps all viewers consistent.
• Спільний перегляд у реальному часі: кілька користувачів дивляться один стрім; присутність і передача контролю — на веб-рівні (Liveblocks), а reload-бродкаст з движка тримає всіх глядачів консистентними.
• Frontend and engine plugin live in one repository (React + Vite next to the UE plugin): both sides of the JSON protocol change in the same commit, so the contract never drifts — and the same PR review covers UI and engine behavior.
• Фронтенд і плагін движка живуть в одному репозиторії (React + Vite поруч з UE-плагіном): обидві сторони JSON-протоколу змінюються одним комітом, тож контракт не розходиться, а один PR-рев’ю покриває і інтерфейс, і поведінку движка.
• An apartment-finder SPA for a residential development: filtering by availability/area/ bedrooms, per-unit highlighting on the towers, a booking flow, interior style switching, Pannellum-based 360° tours, and a media pipeline (ffmpeg/webp) with tiered asset warming for fast first paint.
• SPA-пошук квартир для житлового комплексу: фільтри доступності/площі/кімнат, підсвічування юнітів на вежах, букінг, перемикання стилів інтер'єру, 360°-тури на Pannellum і медіа-пайплайн (ffmpeg/webp) з поетапним прогрівом ассетів для швидкого першого кадру.

OutcomeРезультат

Non-technical buyers use a photoreal UE scene like a normal website. The pattern — capabilities in the engine, product UX in the web — decoupled the two teams and their release cycles. Нетехнічні покупці користуються фотореалістичною UE-сценою як звичайним сайтом. Підхід "можливості в движку, продуктовий UX у вебі" розділив роботу команд і їхні релізні цикли.

Product branding omitted (NDA). Architecture described from my own implementation. Назви продукту прибрані (NDA). Архітектура описана з моєї власної імплементації.

Runtime UX Systems & VR OptimizationRuntime UX-системи та VR-оптимізація

ProblemЗадача

The same archviz content had to work in radically different contexts: a sales manager's touchscreen at an exhibition, a client's browser, and a standalone Meta Quest headset. Each context needs its own input model, UI scale and — hardest — its own performance envelope. Той самий archviz-контент мав працювати в радикально різних контекстах: тачскрін менеджера на виставці, браузер клієнта і автономний шолом Meta Quest. Кожен контекст — своя модель вводу, масштаб UI і, що найважче, свій бюджет продуктивності.

Key engineering decisionsКлючові інженерні рішення

• One widget system, per-context adaptation. UMG interfaces built as reusable components with input-agnostic interaction logic — pointer, touch and VR laser share the same underlying actions; layouts and hit-target sizes adapt per device profile.
• Одна віджет-система, адаптація під контекст. UMG-інтерфейси зібрані з перевикористовуваних компонентів з input-агностичною логікою — миша, тач і VR-лазер працюють через одні й ті самі дії; розкладки і розміри хіт-таргетів адаптуються профілем пристрою.
• Photo mode as a runtime camera/post-process rig: FOV, DOF and focal controls plus post-process parameters (film grain, chromatic aberration, vignette, white balance, gamma) and LUT presets — all driven from UMG at runtime, with backbuffer capture for print-quality client screenshots.
• Фото-режим як runtime-риг камери/пост-процесу: FOV, DOF і фокус плюс параметри пост-процесу (зерно, хроматика, віньєтка, баланс білого, гамма) та LUT-пресети — усе з UMG у рантаймі, із захопленням бекбуфера для клієнтських скріншотів друкованої якості.
• Quest optimization as a budget discipline: draw-call reduction through instancing and mesh merging, texture and lighting budgets per scene, simplified material paths for mobile GPU — profiled iteratively until stable FPS on standalone hardware, with physics interactions kept intact.
• Оптимізація під Quest як дисципліна бюджетів: скорочення draw calls інстансингом і злиттям мешів, бюджети текстур і світла на сцену, спрощені матеріальні шляхи під мобільний GPU — ітеративне профілювання до стабільного FPS на автономному залізі, зі збереженою фізикою взаємодій.
• Comfort-first VR: smooth locomotion tuned against motion sickness, physics-based prop interaction for presence, and day/night lighting scenarios that survive mobile rendering constraints.
• VR з пріоритетом комфорту: плавне переміщення, налаштоване проти захитування, фізична взаємодія з предметами для presence, і сценарії день/ніч, що виживають у межах мобільного рендера.

OutcomeРезультат

20+ interactive scenes delivered across desktop, web-stream, touch and VR from one content base — including VR-ready builds (APK) delivered to clients. 20+ інтерактивних сцен здано на десктоп, веб-стрім, тач і VR з однієї контентної бази — включно з VR-ready білдами (APK) для клієнтів.

Product branding omitted (NDA). Architecture described from my own implementation. Назви продукту прибрані (NDA). Архітектура описана з моєї власної імплементації.

Prismix: Shipping an AI Product Solo with an Agent WorkflowPrismix: соло-запуск AI-продукту з агентним воркфлоу

ProblemЗадача

Developers using several AI providers juggle a dozen status pages, news feeds and MCP-server lists. I wanted one hub — and, as importantly, a testbed for how far a single engineer can go with an AI-agent development workflow. Live at prismix.dev. Розробники, що працюють з кількома AI-провайдерами, мусять тримати відкритими десяток status-сторінок, стрічок новин і списків MCP-серверів. Я хотів один хаб — і, що не менш важливо, полігон: як далеко може зайти один інженер з AI-агентним воркфлоу розробки. Працює на prismix.dev.

Key engineering decisionsКлючові інженерні рішення

• Edge-first architecture at near-zero cost: Astro 5 SSR + Preact islands on Cloudflare Pages/Workers, with KV as the datastore using a single-writer pattern for snapshots. 437 pages, 90 API routes, a public API, 9 RSS feeds and dynamic OG images — for ~$10/year (domain).
• Edge-first архітектура майже без витрат: Astro 5 SSR + Preact islands на Cloudflare Pages/Workers, KV як сховище з single-writer патерном для снапшотів. 437 сторінок, 90 API-роутів, публічний API, 9 RSS-стрічок і динамічні OG-зображення — за ~$10/рік (домен).
• Status monitoring for 77 AI services through two paths — Statuspage API where available, HTTP checks elsewhere — plus alerting (email/webhooks), weekly digests and an embeddable status badge.
• Моніторинг статусу 77 AI-сервісів двома шляхами — Statuspage API де є, HTTP-перевірки де немає — плюс алерти (email/вебхуки), тижневі дайджести і вбудовуваний статус-бейдж.
• A TikTok-style affinity ranker for the news feed: implicit per-user scores from likes/dismisses with capping, blended with explicit subscriptions.
• Affinity-ранкер у стилі TikTok для стрічки новин: неявні per-user ваги з лайків/дисмісів із капінгом, змішані з явними підписками.
• Self-rolled auth — email codes + GitHub OAuth, KV sessions, constant-time comparisons, Turnstile and token-bucket rate limiting — and Ko-fi-webhook-driven Pro subscriptions.
• Власна автентифікація — email-коди + GitHub OAuth, KV-сесії, constant-time порівняння, Turnstile і token-bucket рейт-ліміти — та Pro-підписки через Ko-fi вебхуки.
• Tests as the safety net for agent-written code: ~1,100 Vitest unit tests with an in-memory KV mock and coverage thresholds gating CI — the discipline that makes a heavy AI-agent workflow (Claude Code) reliable. 673 commits in ~10 weeks.
• Тести як страховка для коду, писаного агентами: ~1100 юніт-тестів Vitest з in-memory KV-моком і порогами покриття в CI — дисципліна, що робить інтенсивний AI-агентний воркфлоу (Claude Code) надійним. 673 коміти за ~10 тижнів.
• Automated distribution: a Python + Bluesky AT Protocol content engine (daily queue posting + engagement automation) and 382 programmatic SEO guide pages.
• Автоматизована дистрибуція: контент-двигун на Python + Bluesky AT Protocol (щоденний постинг з черги + автоматизація engagement) і 382 програмні SEO-сторінки гайдів.

OutcomeРезультат

A production web product built, tested, deployed and marketed by one person — proof that I can own systems end-to-end and that my AI-assisted workflow scales beyond toy projects. Продакшн веб-продукт, збудований, протестований, задеплоєний і просунутий на ринок однією людиною — доказ, що я веду системи end-to-end і що мій AI-воркфлоу масштабується за межі іграшкових проєктів.

Immersive VR Interior Tour — Any HeadsetІмерсивний VR-тур інтер'єром — під будь-який шолом

ProblemЗадача

Architects and developers want clients to feel a space before it's built. A video doesn't do that — presence does. The tour had to run on any VR headset, including standalone Meta Quest, and stay comfortable for people who have never worn VR before. This is a personal project, published openly on Behance. Архітектори й забудовники хочуть, щоб клієнт відчув простір до того, як його збудують. Відео цього не дає — дає presence. Тур мав працювати на будь-якому VR-шоломі, включно з автономним Meta Quest, і лишатися комфортним для людей, які вперше вдягли VR. Це особистий проєкт, опублікований відкрито на Behance.

Key engineering decisionsКлючові інженерні рішення

• OpenXR instead of vendor SDKs — one build path for Quest, PC VR and future headsets; no per-platform interaction code.
• OpenXR замість вендорських SDK — один шлях збірки для Quest, PC VR і майбутніх шоломів; без окремого коду взаємодій під кожну платформу.
• Interaction as the core of presence: physics-based prop grabbing, switchable lights and devices, time-of-day and weather control — the visitor changes the space, not just looks at it.
• Взаємодія як основа presence: фізичне хапання предметів, вимикачі світла і техніки, керування часом доби й погодою — відвідувач змінює простір, а не лише дивиться на нього.
• Comfort-first locomotion: smooth movement tuned against motion sickness, with conservative acceleration and rotation defaults for first-time VR users.
• Комфортне переміщення: плавний рух, налаштований проти захитування, з обережними прискореннями й поворотами за замовчуванням — для людей, що вперше у VR.
• A Quest-class performance budget: draw-call reduction, texture and lighting budgets, and simplified material paths — photoreal look within standalone-headset limits.
• Бюджет продуктивності класу Quest: скорочення draw calls, бюджети текстур і світла, спрощені матеріальні шляхи — фотореалістичний вигляд у межах автономного шолома.

OutcomeРезультат

A published, headset-agnostic VR tour that demonstrates the full loop I bring to VR work: art, interaction design, and the optimization that makes it run where clients actually are. Опублікований VR-тур, незалежний від шолома, який показує повний цикл моєї VR-роботи: арт, дизайн взаємодій і оптимізацію, завдяки якій це працює там, де реально є клієнти.

Studio-Grade Infrastructure for Solo UE DevelopmentІнфраструктура студійного рівня для соло UE-розробки

ProblemЗадача

Unreal projects are heavy: tens of gigabytes of binary content that Git handles poorly, engine behavior you sometimes need to change at the source level, and repetitive export/cook/package work that eats evenings. Working solo is not a reason to work without infrastructure — it's a reason to automate it. Unreal-проєкти важкі: десятки гігабайтів бінарного контенту, з яким Git справляється погано; поведінка движка, яку іноді треба міняти на рівні сирців; повторювана робота з експорту/куку/пакування, що з'їдає вечори. Працювати соло — не привід працювати без інфраструктури, це привід її автоматизувати.

Key engineering decisionsКлючові інженерні рішення

• Self-hosted Perforce with streams for all UE work — personal projects live under the same versioning discipline as studio ones: atomic submits of binary content, streams per project, full history.
• Власний Perforce-сервер зі стрімами для всієї UE-роботи — особисті проєкти живуть під тією ж дисципліною версіювання, що й студійні: атомарні субміти бінарного контенту, стріми на проєкт, повна історія.
• Custom engine builds from UE source — when a problem sits inside the engine, I build the engine: source-level debugging and patches instead of workarounds.
• Власні збірки движка з сирців UE — коли проблема сидить усередині движка, я збираю движок: дебаг і патчі на рівні сирців замість милиць.
• Headless by default: every tool I write has a no-UI mode — the 3ds Max exporter runs on a render farm, the UE pipeline runs from an editor startup script, packaging goes through RunUAT on a build machine.
• Headless за замовчуванням: кожен мій інструмент має режим без UI — експортер для 3ds Max працює на рендер-фермі, UE-пайплайн стартує зі скрипта редактора, пакування йде через RunUAT на білд-машині.
• AI agents inside the toolchain: Claude Code + MCP for day-to-day engineering, plus a local LLM stack for offline experiments — treated as infrastructure, with tests and checks around it, not as a toy.
• AI-агенти всередині тулчейна: Claude Code + MCP для щоденної інженерії, плюс локальний LLM-стек для офлайн-експериментів — це інфраструктура з тестами й перевірками довкола, а не іграшка.

OutcomeРезультат

One person operating with a studio's reproducibility: versioned binaries, rebuildable engine, automated pipelines. This is the discipline I bring to a team from day one. Одна людина працює з відтворюваністю студії: версійовані бінарники, движок, який можна перезібрати, автоматизовані пайплайни. Саме цю дисципліну я приношу в команду з першого дня.