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Форма рішення

// One entry point for every browser message over the DataChannel
void UStreamBridge::OnDataChannelMessage(const FString& Json)
{
    FSceneCommand Cmd;
    if (!FJsonObjectConverter::JsonObjectStringToUStruct(Json, &Cmd))
        return;                              // ignore malformed input

    switch (Cmd.Type)
    {
    case ESceneCmd::LoadScene:   RequestPakMount(Cmd.SceneId);           break;
    case ESceneCmd::MoveCamera:  CameraDirector->Apply(Cmd.Camera);      break;
    case ESceneCmd::SetMaterial: Variants->Swap(Cmd.Actor, Cmd.Variant); break;
    case ESceneCmd::SaveState:   History->Snapshot(FDateTime::UtcNow());  break;
    default: break;
    }
}

The web UI owns the UX; the engine exposes a small, typed command surface.Інтерфейс володіє UX; движок надає малу типізовану поверхню команд.

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 03). New scene = new file on storage.
• Сцени — це cooked .pak файли, змонтовані в рантаймі. Застосунок не змінюється; контент їде самодостатніми .pak-рівнями з пайплайна (кейс 03). Нова сцена = новий файл на сховищі.
• 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.
• Детермінований teardown між сценами — розмонтування, чистка GC і скидання стану, щоб довгоживучий хмарний інстанс перемикав сцени годинами без витоків.

OutcomeРезультат

A single deployed Unreal application serves an entire catalog of client scenes; new content ships as files, with no engine-side code changes. Tagged stable v2.0, running in production. Один задеплоєний Unreal-застосунок обслуговує весь каталог клієнтських сцен; новий контент їде файлами, без змін у коді движка. Тег stable v2.0, працює в продакшні.

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

Gameplay Systems in C++ (GAS)Геймплейні системи на C++ (GAS)

ProblemЗадача

An in-development action game needed a combat and ability layer designers could tune without touching C++: stats and abilities as data, networked so they behave correctly in multiplayer, and responsive input driving animation. Hard-coding abilities and damage math would not scale as the game grew. Екшн-грі в розробці потрібен був шар бойовки і здібностей, який дизайнери можуть налаштовувати без C++: характеристики й здібності як дані, репліковані для коректної роботи в мультиплеєрі, і чутливий інпут, що керує анімацією. Хардкодити здібності й математику урону — не масштабується з ростом гри.

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

// Mitigate incoming damage by the target's defense, then apply to Health
void UTBOCHDamageExecution::Execute_Implementation(
    const FGameplayEffectCustomExecutionParameters& Exec,
    FGameplayEffectCustomExecutionOutput& Out) const
{
    float Damage  = GetCaptured(Exec, DamageDef);
    float Defense = GetCaptured(Exec, DefenseDef);

    const float Final = FMath::Max(Damage - Defense, 0.f);
    Out.AddOutputModifier({ HealthProperty, EGameplayModOp::Additive, -Final });
}

Abilities and effects are data assets; the C++ execution only owns the math and the network-safe application.Здібності й ефекти — data-ассети; C++-виконання володіє лише математикою і мережево-безпечним застосуванням.

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

• Gameplay Ability System as the backbone. Abilities, costs and cooldowns live as data; designers author and balance them without a rebuild. C++ provides the custom Ability System Component, abilities and tasks.
• Gameplay Ability System як хребет. Здібності, вартості й кулдауни — це дані; дизайнери створюють і балансять їх без перезбірки. C++ дає власні Ability System Component, здібності й таски.
• Replicated Attribute Set. Health, MaxHealth, AttackPower, DefensePower and a transient Damage meta-attribute, replicated with OnRep handlers — combat stays consistent across the network.
• Реплікований Attribute Set. Health, MaxHealth, AttackPower, DefensePower і тимчасовий мета-атрибут Damage, репліковані з OnRep-хендлерами — бойовка узгоджена по мережі.
• Damage as a GameplayEffect execution. Attack-vs-defense mitigation runs in a custom execution calculation, keeping the formula in one testable place.
• Урон як execution GameplayEffect. Пом’якшення атака-проти-захисту рахується в кастомному execution — формула в одному тестованому місці.
• Responsive input & animation. Enhanced Input maps actions to abilities; a custom play-montage-and-wait-for-event task syncs animation with ability windows, on a Full-Body IK character.
• Чутливий інпут і анімація. Enhanced Input мапить дії на здібності; кастомний таск play-montage-and-wait-for-event синхронізує анімацію з вікнами здібностей, на персонажі з Full-Body IK.
• Beyond combat: the systems around it. A dialogue system with per-line cutscene cameras (each NPC line cuts to its own framed shot), a quest system with objectives, HUD announcements and save/load, stealth detection with a material-driven on-screen meter, and the interaction layer — doors, pickups, ladders — with footstep FX and gamepad-first prompts.
• Не лише бойовка: системи навколо. Діалогова система з кат-сценними камерами на кожну репліку (кожна фраза NPC перемикається на свій кадр), квестова система з цілями, HUD-анонсами і сейвами, стелс-детекція з метром на матеріалах — і шар інтеракцій: двері, предмети, драбини, з ефектами кроків і підказками під геймпад.

OutcomeРезультат

The gameplay layer was built end to end and worked in multiplayer: the ability framework, replicated attributes, damage execution, and the character / input / animation glue — the same GAS architecture shipped games use, written by hand rather than assembled from a template. Around it, the dialogue, quest and stealth systems ran in-game with their full UI — playable content, not prototypes. Геймплейний шар збудовано від початку до кінця, з робочим мультиплеєром: фреймворк здібностей, репліковані атрибути, damage execution і зв’язка персонаж / інпут / анімація — та сама GAS-архітектура, що й у випущених іграх, написана руками, а не зібрана з шаблону. Навколо неї в грі працювали діалоги, квести і стелс із повним UI — граючий контент, не прототипи.

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Форма рішення

# One stage: dedupe meshes before Nanite so instancing survives
def dedupe_static_meshes(scene):
    seen = {}
    for actor in scene.static_mesh_actors():
        key = mesh_fingerprint(actor.mesh)   # verts + tris + material set
        if key in seen:
            actor.replace_mesh(seen[key])    # reuse the canonical asset
        else:
            seen[key] = actor.mesh
            center_pivot(actor.mesh)         # normalize for instancing
    return len(seen)                       # unique meshes kept

Thousands of duplicated exports collapse to a handful of instanced assets — smaller cook, stable memory.Тисячі дубльованих експортів згортаються в кілька інстансованих ассетів — менший cook, стабільна пам’ять.

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: a typical raw export carries 3,000-5,000 duplicated meshes with arbitrary pivots, which break instancing and inflate cook size; dedup collapses that down to a few hundred canonical assets.
• Дедуплікація мешів + нормалізація півотів перед Nanite: типовий сирий експорт несе 3000-5000 дубльованих мешів з довільними півотами — це ламає інстансинг і роздуває розмір білда; дедуплікація зводить це до кількох сотень канонічних ассетів.
• 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 могли працювати зі змістом сцени, не завантажуючи рівень.
• Nanite gating is a rule, not a toggle: a dedicated C++ optimizer decides per mesh, not per scene — a material blend-safety check excludes glass and translucents, then a sparsity-percentile rule disables Nanite on the sparsest remaining meshes by a triangles-per-bounds metric, unless enough material slots justify keeping it. A single Python script configures and triggers the whole pass headlessly.
• Гейтинг Nanite — правило, а не перемикач: виділений C++ оптимізатор вирішує на рівні кожного меша, а не сцени — перевірка безпечності блендингу матеріалу виключає скло й напівпрозорі, тоді правило за перцентилем розрідженості вимикає Nanite на найрозрідженіших з решти мешів за метрикою трикутники-на-межу, якщо кількість матеріальних слотів не виправдовує його збереження. Один Python-скрипт налаштовує і запускає весь прохід без нагляду.
• Lighting remapped to a target band, not left at import defaults: intensities, shadow bias and lightmap resolution are normalized to fixed ranges across every scene, so look-dev starts from a consistent baseline instead of fighting whatever the source file happened to have.
• Світло приводиться до цільового діапазону, а не лишається на дефолтах імпорту: інтенсивності, shadow bias і роздільність лайтмапи нормалізуються до фіксованих меж у кожній сцені, тож look-dev стартує з консистентної бази, а не бореться з тим, що випадково прийшло у вихідному файлі.
• 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 2-3 days of manual editor work to a largely unattended pipeline run under 30 minutes, with the packaged .pak typically shrinking to roughly half the raw export size after dedup and Nanite. Artists ship scenes without touching engine internals; engineering time goes to the platform, not per-scene fixes. Підготовка сцени скоротилася з 2-3 днів ручної роботи в редакторі до майже автономного прогону пайплайна менш ніж за 30 хвилин, а запакований .pak зазвичай стискається приблизно вдвічі відносно сирого експорту після дедуплікації й Nanite. Артисти здають сцени, не торкаючись движка; час інженерів іде на платформу, а не на разові фікси.

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

Custom HLSL Interior Mapping ShaderКастомний HLSL-шейдер Interior Mapping

ProblemЗадача

Several studio rejections named the same gap explicitly: commercial experience writing actual shader code (HLSL/GLSL, Custom Node internals at the engine level), not just building look-dev materials from stock nodes. The honest answer at the time would have been "touched it without a real need to." I wanted a real answer instead: a genuine technique, implemented, and provably compiling. Кілька відмов від студій прямо називали один і той самий геп: комерційний досвід написання саме шейдерного коду (HLSL/GLSL, внутрішня робота Custom Node на рівні рушія), а не лише збірка look-dev матеріалів зі стокових нод. Чесна відповідь на той момент була б "торкався, але справжньої потреби не було". Я хотів натомість справжню відповідь: реальну техніку, реалізовану і доведено робочу.

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

• A real shader library, not code stuffed into a node. A Custom Node's body gets inlined into an auto-generated function, so it can't hold reusable functions or structs. I registered a project shader directory instead and wrote an actual .ush file with real functions, callable from the node.
• Реальна шейдерна бібліотека, а не код, запханий у ноду. Тіло Custom Node інлайниться в автоматично згенеровану функцію, тож там не можна тримати перевикористовувані функції чи структури. Замість цього я зареєстрував проєктну шейдерну директорію і написав справжній .ush-файл з реальними функціями, які викликаються з ноди.
• Ray/box intersection in tangent space, with the ray direction normalized to room dimensions, so one function serves rooms of any proportions instead of one hard-coded box size.
• Перетин променя й коробки в тангентному просторі, з нормалізацією напрямку променя на розміри кімнати, тож одна функція обслуговує кімнати будь-яких пропорцій, а не один захардкоджений розмір.
• Three shading modes: a texture-free procedural mode for quick iteration, a single cubemap mode, and a baked texture-atlas mode with explicit SampleGrad to avoid mip artifacts at room-boundary UV seams.
• Три режими шейдингу: процедурний без текстур для швидкої ітерації, режим з однією кубмапою, і режим з запеченим атласом текстур з явним SampleGrad, щоб уникнути mip-артефактів на межах кімнат в UV.
• Verified, not assumed. A first pass under -NullRHI produced zero instructions, which proves nothing. A real-RHI headless compile (forcing the local shader compiler past a distributed-compile setup that doesn't exist on this machine) gave honest numbers straight from the engine's own statistics: 156 pixel-shader instructions, 0 samplers in procedural mode, 0 errors.
• Перевірено, а не припущено. Перший прогін під -NullRHI дав нуль інструкцій, що не доводить нічого. Реальна headless-компіляція (з примусом локального шейдер-компілятора замість розподіленої компіляції, якої на цій машині нема) дала чесні цифри прямо зі статистики рушія: 156 інструкцій пікселшейдера, 0 семплерів у процедурному режимі, 0 помилок.
• Scaled from one room to many: a scene-capture cube is baked per room variant into a static TextureCube, collected into a TextureCubeArray, and indexed per material instance by a hashed seed, so the same shader shows a different room behind every window.
• Масштабовано від однієї кімнати до багатьох: scene-capture куб запікається на кожен варіант кімнати в статичний TextureCube, збирається в TextureCubeArray і індексується на кожному інстансі матеріалу хешованим сідом, тож той самий шейдер показує різну кімнату за кожним вікном.
• Built headless and reproducible: the material graph is assembled by a Python script via MaterialEditingLibrary, not hand-wired in the GUI, so it's diffable in git instead of living only as an opaque binary asset.
• Зібрано headless і відтворювано: граф матеріалу збирається Python-скриптом через MaterialEditingLibrary, а не вручну в GUI, тож він diff-иться в git замість того, щоб жити лише як непрозорий бінарний ассет.

OutcomeРезультат

A real, verified custom-shader technique end to end: from researching the original technique to a working material that compiles with honest, engine-reported numbers. It closes the exact gap studios named, with a concrete example instead of a qualifier. Реальна, перевірена шейдерна техніка від початку до кінця: від дослідження оригінальної техніки до робочого матеріалу, що компілюється з чесними, зі статистики рушія, цифрами. Це закриває саме той геп, який називали студії, конкретним прикладом, а не застереженням.

Houdini VFX & Procedural R&DHoudini VFX і процедурний R&D

ProblemЗадача

Studios hiring for real-time VFX want simulation and procedural thinking, and an archviz career gives you neither by default: client work rewards clean stills, not solvers. These studies exist to close that gap deliberately — each one picks a technique with a clear production application and works it until it's understood, not just reproduced from a tutorial. Студії, що наймають під real-time VFX, хочуть симуляцію і процедурне мислення, а archviz-кар'єра сама по собі не дає ні того, ні іншого: клієнтська робота винагороджує чисті кадри, а не солвери. Ці дослідження існують, щоб свідомо закрити цей геп — кожне бере техніку з чітким продакшн-застосуванням і працює з нею, доки вона зрозуміла, а не просто відтворена з туторіалу.

The studiesДослідження

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

• VEX-first, not node soup. Geometry and patterns are authored in VEX wrangles — points, attributes and math I control directly — which is the same procedural thinking that scales into reusable HDAs.
• VEX-first, а не «суп із нод». Геометрія й патерни пишуться у VEX-ренглах — точки, атрибути й математика під моїм контролем — це те саме процедурне мислення, що масштабується у перевикористовувані HDA.
• Simulation with a budget. The pyro/dust explosion is tuned for controllable substeps, voxel resolution and cache size — sim work aimed at a real-time/VR budget, not an offline-only beauty render.
• Симуляція з бюджетом. Pyro/dust-вибух налаштований на керовані substeps, роздільність вокселів і розмір кешу — симуляція під real-time/VR-бюджет, а не суто офлайн-рендер заради краси.
• Generative pattern systems. Differential-line growth and shortest-path growth are two algorithmic approaches to the same goal — geometry that emerges from rules — the basis for procedural placement, wear and network layouts in production scenes.
• Генеративні системи патернів. Differential-line growth і shortest-path growth — два алгоритмічні підходи до однієї мети: геометрія, що виникає з правил — основа для процедурного розміщення, зносу й мережевих розкладок у продакшн-сценах.
• The bridge to Unreal. This practice isn't Houdini-for-its-own-sake — it's the upstream of real-time VFX: a custom cloth HDA I authored, live-cooked in the Unreal editor through Houdini Engine, and destruction/sim brought into the engine as Niagara systems — exactly what real-time VFX roles ask for.
• Міст до Unreal. Ця практика — не Houdini заради Houdini, а вихідна точка real-time VFX: власний HDA для тканини, live-cook якого йде прямо в редакторі Unreal через Houdini Engine, і внесення руйнувань/симуляцій у движок як Niagara-систем — саме те, що вимагають ролі real-time VFX.

OutcomeРезультат

A VFX and procedural capability alongside the engineering — the side that makes me useful on real-time VFX and tech-art teams, not only pipeline and runtime work. VFX- і процедурна компетенція поруч з інженерією — та сторона, що робить мене корисним у командах real-time VFX і tech-art, а не лише в пайплайні й рантаймі.

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). Архітектура описана з моєї власної імплементації.

Technical UI/UX & Runtime UX SystemsТехнічний UI/UX і runtime UX-системи

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: locomotion and interaction defaults tuned for first-time users (the approach is detailed in Case 09), plus day/night lighting scenarios that survive mobile rendering constraints.
• VR з пріоритетом комфорту: переміщення і взаємодія, налаштовані під новачків у VR (підхід детально в кейсі 09), плюс сценарії день/ніч, що виживають у межах мобільного рендера.

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). Архітектура описана з моєї власної імплементації.

Real-Time Product Configurator — Variant & Interaction SystemReal-time конфігуратор — система варіантів і взаємодій

ProblemЗадача

The hard part of a configurator isn't showing one pretty option — it's the combinatorics. Hundreds of material, geometry and device combinations have to stay photoreal and performant in a single scene, and in the commercial version the price and cart must always match what's on screen. A personal take on the pattern is published on Behance. Найважче в конфігураторі — не показати один гарний варіант, а комбінаторика. Сотні комбінацій матеріалів, геометрії і техніки мають лишатись фотореалістичними й продуктивними в одній сцені, а в комерційній версії ціна і кошик мусять завжди відповідати тому, що на екрані. Особисту версію патерна опубліковано на Behance.

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

• A variant system, not duplicated scenes. Materials and geometry are swappable options driven by data, so one scene expresses hundreds of combinations without re-authoring — and adding a new finish is a data change, not a new level.
• Система варіантів замість дубльованих сцен. Матеріали й геометрія — це змінні опції, керовані даними, тож одна сцена виражає сотні комбінацій без переробки, а нове оздоблення — це зміна даних, а не новий рівень.
• Interactive devices as reusable components: lights, TV and appliances toggle through a shared interaction interface; time-of-day switching re-lights the space live.
• Інтерактивні пристрої як перевикористовувані компоненти: світло, ТВ і техніка вмикаються через спільний інтерфейс взаємодії; перемикання часу доби переосвітлює простір наживо.
• Configuration state is the single source of truth — it feeds the 3D view, the live floor plan and (commercially) pricing and checkout, so the visual and the transaction never disagree.
• Стан конфігурації — єдине джерело правди — він живить 3D-в’ю, живий план і (комерційно) ціну та оплату, тож візуал і транзакція ніколи не розходяться.

OutcomeРезультат

A configurator pattern I've built both as a personal project and in production — the same variant/interaction/state architecture, scaled from a kitchen to a modular house with e-commerce on top. Патерн конфігуратора, який я будував і як особистий проєкт, і в продакшені — та сама архітектура варіантів/взаємодій/стану, масштабована від кухні до модульного будинку з e-commerce поверх.

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

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: the same optimization discipline as my client VR work (Case 07), applied here to keep a photoreal look within standalone-headset limits.
• Бюджет продуктивності класу Quest: та сама дисципліна оптимізації, що й у клієнтській VR-роботі (кейс 07), тут — щоб утримати фотореалістичний вигляд у межах автономного шолома.

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 on the headsets clients actually own. Опублікований VR-тур, незалежний від шолома, який показує повний цикл моєї VR-роботи: арт, дизайн взаємодій і оптимізацію, завдяки якій це працює на шоломах, які реально є в клієнтів.

Rendering Mobile Ad Creatives in UnrealРендеринг мобільних рекламних креативів в Unreal

ProblemЗадача

User-acquisition ads for mobile games live and die on the first two seconds, ship in high volume, and need many A/B variants fast. Pre-rendered CG is too slow to iterate. The answer: stage the "gameplay", render and iterate inside a real-time engine. UA-реклама мобільних ігор живе або вмирає в перші дві секунди, виходить великими обсягами і потребує швидких A/B-варіантів. Пре-рендер CG надто повільний для ітерацій. Рішення: ставити «геймплей», рендерити й ітерувати всередині real-time движка.

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

• Unreal as the ad-render pipeline: staged gameplay beats, Sequencer camera and event tracks, and fast in-engine capture — new creative variants in hours, not render-farm days.
• Unreal як пайплайн рендера реклами: поставлені геймплейні біти, камера й треки подій у Sequencer і швидке захоплення в движку — нові варіанти креативів за години, а не дні на рендер-фермі.
• Vertical-first framing (9:16) with on-screen guidance overlays tuned to the hook, plus simulation work (a Houdini bubble/particle sim) dropped in where a creative needs a "wow" beat.
• Вертикальний кадр (9:16) з екранними підказками під хук, плюс симуляція (Houdini-бульбашки/частинки) там, де креативу потрібен «вау»-момент.
• Motion-design finish in post — the CGI background I'd built for years now feeds a marketing funnel: the same craft, a different KPI (install rate instead of a beauty shot).
• Моушн-фініш у пості — CGI-бекграунд, який я напрацьовував роками, тепер живить маркетингову воронку: те саме ремесло, інший KPI (install rate замість красивого кадру).

OutcomeРезультат

A niche most UE developers don't cover: real-time engine skills applied to performance marketing. Client work, shown as craft — it widens where I'm useful, from product teams to growth teams. Ніша, яку більшість UE-розробників не закриває: навички real-time движка в performance-маркетингу. Клієнтська робота, показана як ремесло — вона розширює, де я корисний: від продуктових команд до команд росту.

Game titles and campaign details omitted (NDA). Workflow described from my own production work. Назви ігор і деталі кампаній прибрані (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-сторінки гайдів.
• The status monitor is also an MCP server, published to the official MCP Registry — any AI agent can ask "is OpenAI down?" and get a live answer, with zero setup and no API key.
• Монітор статусу — водночас MCP-сервер, опублікований в офіційному MCP Registry — будь-який AI-агент може спитати «чи лежить OpenAI?» і отримати живу відповідь без налаштувань і ключа.

OutcomeРезультат

Live at prismix.dev: 437 pages, 90 API routes and a status monitor for 77 services, running unattended on edge infrastructure for about $10 a year — built, tested, deployed and marketed by one person. Живе на prismix.dev: 437 сторінок, 90 API-роутів і монітор статусу 77 сервісів, працює без нагляду на edge-інфраструктурі за ~$10 на рік — збудовано, протестовано, задеплоєно й просунуто однією людиною.

Time-Room: A Self-Hosted Multi-Agent AI PlatformTime-Room: власна мульти-агентна AI-платформа

ProblemЗадача

Running specialized AI agents reliably isn't a prompt-engineering problem, it's a systems one: cost-tiered routing between models of different size and skill, session lifecycle, persistent memory, and safe tool access. I wanted to prove I could own that stack end to end, on my own hardware, not just consume someone else's hosted one. Надійно запускати спеціалізованих AI-агентів — це не задача промпт-інженерії, а системна: маршрутизація за вартістю між моделями різних розмірів і спеціалізацій, життєвий цикл сесій, постійна пам'ять і безпечний доступ до інструментів. Я хотів довести, що можу вести цей стек end-to-end, на власному залізі, а не просто споживати чийсь хостинговий.

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

• Tiered model serving, role-specialized: a router model triages every request; a large reasoning model handles hard tasks; a vision model reads images; a coder model writes code — each behind its own llama.cpp CUDA server in Docker Compose, with health checks and GPU scheduling.
• Ярусна подача моделей, спеціалізована за роллю: router-модель сортує кожен запит; велика reasoning-модель бере складні задачі; vision-модель читає зображення; coder-модель пише код — кожна за власним llama.cpp CUDA-сервером у Docker Compose, з health checks і плануванням GPU.
• Agent orchestration: 15 role-specialized agent definitions (coder, researcher, planner, and more) and 17 shared skills behind a dispatch layer that spawns and manages sub-agent sessions, each validated against a versioned spec before it can run.
• Оркестрація агентів: 15 спеціалізованих за роллю визначень агентів (coder, researcher, planner і інші) і 17 спільних навичок за диспетчерським шаром, що породжує й веде сесії суб-агентів, кожна звірена з версійованою специфікацією перед запуском.
• The bridge to my primary engine: one of those agents drives Unreal Engine itself. I forked an open-source UE↔MCP plugin and extended it with a generic Python bridge plus a connector into Epic's own internal AI tool registry (~900 tools), then fixed real bugs the fork shipped with — a save/GC race that could crash the editor, dead node-name resolution, hardcoded asset paths — verified with a 5-pass functional audit (actors, blueprints, graph wiring, all green).
• Міст до мого основного движка: один з цих агентів керує самим Unreal Engine. Я форкнув opensource UE↔MCP плагін і розширив його загальним Python-мостом і конектором у внутрішній реєстр AI-інструментів Epic (~900 штук), потім виправив реальні баги форку — гонку при save/GC, що могла завалити редактор, мертвий резолв імен вузлів, захардкоджені шляхи асетів — перевірено 5-прохідним функціональним аудитом (актори, блупринти, з'єднання графа — усе зелене).
• A gateway, not just a client: a custom MCP server groups ~200 third-party tools into toggleable capability sets (memory, dev tools, browser, agent coordination) so each agent sees only what its role needs, not the whole surface.
• Шлюз, а не просто клієнт: власний MCP-сервер групує ~200 сторонніх інструментів у вмикні набори можливостей (памʼять, dev-tools, браузер, координація агентів), тож кожен агент бачить лише те, що потрібно його ролі, а не всю поверхню.
• Memory and tools: a Qdrant vector store with dynamic backup and workspace archiving, plus MCP tool integrations (including web search) so agents act, not just answer.
• Памʼять та інструменти: Qdrant векторне сховище з динамічним бекапом і архівуванням робочих просторів, плюс MCP-інтеграції інструментів (включно з веб-пошуком), щоб агенти діяли, а не лише відповідали.
• Production concerns solved, not hand-waved: session auto-prune and cleanup, context-overflow mitigation, heartbeat-contention reduction, dispatch-parameter correctness — the unglamorous reliability work that separates a demo from something you actually run day to day.
• Продакшн-питання вирішені, а не замовчані: авто-очищення сесій, пом'якшення переповнення контексту, зниження heartbeat-конкуренції, коректність параметрів диспетчеризації — непоказна робота з надійності, що відрізняє демо від того, чим реально користуєшся щодня.

OutcomeРезультат

A working, self-hosted alternative to a rented multi-agent platform, running on my own GPU. The same instinct I bring to automating a client's pipeline, pointed at my own infrastructure. Personal project; source private. Робоча власна альтернатива орендованій мульти-агентній платформі, на моєму власному GPU. Той самий інстинкт, що я приношу в автоматизацію клієнтського пайплайна, спрямований на власну інфраструктуру. Особистий проєкт, джерело приватне.

From a Template to a Typed C++ PlatformВід шаблону до типізованої C++ платформи

ProblemЗадача

The archviz platform started the way real products often do: on a marketplace ArchViz template with a thin reflection bridge to the web — fast to ship, fragile to grow. It then had to become a maintainable, typed C++ system serving hundreds of scenes without collapsing under its own weight. Платформа archviz почалась так, як часто починаються реальні продукти: з маркетплейс-шаблону ArchViz з тонким reflection-мостом до вебу — швидко для запуску, крихко для росту. Далі вона мала стати підтримуваною типізованою C++ системою на сотні сцен, не завалившись під власною вагою.

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

• Ship first on a template, then earn the rewrite. The first iteration proved the product on a stock base; only once the shape was clear did it get a typed C++ framework — the legacy version kept in the repo as reference, not deleted in a risky big-bang.
• Спочатку релізимо на шаблоні, потім заслуговуємо переписування. Перша ітерація довела продукт на стоковій базі; лише коли форма стала зрозумілою, з’явився типізований C++ фреймворк — легасі-версія лишилась у репо як довідка, а не видалена ризикованим big-bang.
• Reflection bridge → typed contract. The fragile stringly-typed FE↔UE bridge became a typed command protocol — one change that removed a whole class of runtime errors.
• Reflection-міст → типізований контракт. Крихкий stringly-typed міст FE↔UE став типізованим протоколом команд — одна зміна, що прибрала цілий клас помилок рантайму.
• World Partition to break the scale ceiling — the move from monolithic levels to streamed cells (the mechanics live in Case 01) is what raised the platform from a handful of scenes to hundreds.
• World Partition, щоб зняти стелю масштабу — перехід від монолітних рівнів до стрімлених комірок (механіка описана в кейсі 01) підняв платформу з кількох сцен до сотень.
• Readiness over timers. The loading curtain used to lift on a fixed delay, which either flashed unfinished geometry or made users wait longer than needed. It now polls the real signal every frame — streaming layers activated, world settled, textures actually resident — and only lifts once that holds for several consecutive frames, with a timeout as a failsafe. Deterministic either way, never a guess.
• Готовність замість таймера. Раніше завіса завантаження піднімалась через фіксовану затримку, яка або показувала недовантажену геометрію, або змушувала чекати довше, ніж треба. Тепер вона щокадру звіряє реальний сигнал — шари стрімінгу активовані, світ усівся, текстури дійсно резидентні — і піднімається лише коли це тримається кілька кадрів поспіль, із таймаутом як запобіжником. Детерміновано в обох випадках, ніколи навмання.
• One core, two front ends. The same C++ framework now also drives a second client project completely offline — no PixelStreaming, no browser — through a native UMG interface built on the identical subsystem and data assets. Swapping only the presentation layer and keeping the whole state machine is the proof the architecture is actually separated, not just labeled that way.
• Одне ядро, два фронтенди. Той самий C++ фреймворк тепер керує ще й другим клієнтським проєктом повністю офлайн — без PixelStreaming, без браузера — через нативний UMG-інтерфейс на тій самій підсистемі й дата-асетах. Заміна лише шару подачі зі збереженням усієї машини станів — доказ, що архітектура справді розділена, а не просто так названа.

OutcomeРезультат

The part of engineering that's hard to fake: not just building a system, but evolving a live one without breaking it. I've carried a product from a template to a typed platform — and I know which refactors are worth the risk and which aren't. Та частина інженерії, яку важко зімітувати: не просто збудувати систему, а розвивати живу, не зламавши її. Я провів продукт від шаблону до типізованої платформи — і знаю, які рефактори варті ризику, а які ні.

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, so it can run unattended on a build machine — the same principle behind the content pipeline in Case 03.
• Headless за замовчуванням: кожен мій інструмент має режим без UI, тож може працювати без нагляду на білд-машині — той самий принцип, що й у пайплайні контенту з кейсу 03.

OutcomeРезультат

One person operating with a studio's reproducibility: versioned binaries, rebuildable engine, automated pipelines. Joining an existing team's infrastructure is a downhill move, not a learning curve. Одна людина працює з відтворюваністю студії: версійовані бінарники, движок, який можна перезібрати, автоматизовані пайплайни. Вхід в інфраструктуру наявної команди для мене спуск, а не крива навчання.