Oleksandr Vlasiuk
149 lines
14 KiB
Markdown
149 lines
14 KiB
Markdown
# Розширений hit-feedback на крейтах: спарки, HP-бар, числа урону (2026-08-12)
|
||
|
||
Користувач показав референс-скріншоти з іншої гри (damage-numbers, HP-бар,
|
||
іскри в точці контакту) і сказав, що зараз у нас із фідбеку на хіт **лише
|
||
невеликий нахил** — флеш кольору, який мав бути з Day 6, візуально не
|
||
працює. Плейл поступово (по одному ефекту, з перевіркою між кроками).
|
||
|
||
## ⚠️ Знайдений і виправлений баг: флеш кольору був тихим no-op з самого Day 6
|
||
`playHitFeedback` лерпив `material.color` від `baseColor` до `FLASH_COLOR`
|
||
(білий) — але залогувавши реальний матеріал crate-мешів (`MeshBasicMaterial`,
|
||
`color: #ffffff`, без `emissive` — це не Standard/Phong), виявилось, що
|
||
**`baseColor` вже й був чистим білим**. Текстура дає весь реальний колір,
|
||
тінт-колір лишався на дефолтному білому — лерп "білий -> білий" не змінює
|
||
візуально НІЧОГО, tween виконувався справно (перевірено таймингом), просто
|
||
результат був непомітний. `MeshBasicMaterial` — unlit, `color` множиться на
|
||
текстуру, тож "яскравіше за білий" через цей канал взагалі неможливо.
|
||
|
||
**Виправлення**: замість лерпу `.color` — `StageVisual.flashMesh`, клон тієї
|
||
самої mesh-геометрії (`mesh.clone()`), покладений зверху з власним
|
||
`MeshBasicMaterial({ color: FLASH_COLOR, transparent: true, opacity: 0,
|
||
blending: AdditiveBlending, depthWrite: false })`. Флеш тепер анімує
|
||
`flashMesh.material.opacity` (0→1→0) замість кольору базового меша —
|
||
працює незалежно від того, який в оригінала колір/текстура, бо це
|
||
адитивний шар зверху, а не множник. **Побічний ефект**: `flashMesh` — це
|
||
ще один mesh під `map`, тож `TestSceneC`'s `ThreeC.setShadowsStateForChildren
|
||
(map, true, true)` (виконується ПІСЛЯ `BreakablePropC.init()`) увімкнув би
|
||
йому shadows теж — додано `BreakablePropC.disableFlashShadows()`, викликаний
|
||
з `TestSceneC` одразу після цього рядка, щоб вимкнути назад (даремний
|
||
shadow-caster на майже завжди прозорому оверлеї).
|
||
|
||
Перевірено (Playwright, серія скріншотів кожні 80мс під час бою): крейт у
|
||
кадрі точно на позначці очікуваного хіта помітно біліший/яскравіший, ніж у
|
||
кадрах до/після — флеш реально видно, на відміну від попередньої версії.
|
||
|
||
**Урок**: тінт-колір (`material.color`) на unlit-текстурованому меші не дає
|
||
"флешу", якщо колір вже білий (звичайний дефолт) — для видимого
|
||
hit-flash-у на такому матеріалі потрібен окремий адитивний оверлей-шар, а
|
||
не лерп самого кольору. Якщо десь ще знадобиться подібний ефект на
|
||
текстурованому unlit-меші — той самий підхід (clone + additive overlay).
|
||
|
||
## Іскри в точці контакту — v1 hand-rolled, замінено (2026-08-12)
|
||
Перша версія — новий `SparkFxC.ts`, ручно зібраний `ParticleSystem` (білі
|
||
квадратні частинки, `SphereEmitter(radius:0.05)`, звичайний `BillBoard`).
|
||
Технічно працював (Playwright підтвердив спалах у момент хіта), але
|
||
користувач подивився і сказав: **"Іскри не підходять, це мають бути як
|
||
промені. Саме такі як на скріні"** — потрібні тонкі промені-стріки, не
|
||
блоб з крапок. Перебудував рендер на `RenderMode.StretchedBillBoard`
|
||
(розтягує квад уздовж власної швидкості частинки — це і дає "промінь", а
|
||
не крапку) + `speedFactor`, `ColorOverLife`+`Gradient` для згасання альфи.
|
||
Це вже виглядало краще, але тут користувач відкрив `temp/VFX_Lootable_Destroy.json`
|
||
у редакторі й запитав, що в цих файлах — і виявилось, що це змінює все.
|
||
|
||
## ⚠️ Знахідка: в `temp/` лежали готові дизайнерські VFX-префаби, повністю невикористані
|
||
`temp/VFX_Lootable_Hit.json`, `temp/VFX_Lootable_Destroy.json` (+
|
||
`PassionOne-Black.otf` — шрифт, ще не використаний, ймовірно для майбутніх
|
||
чисел урону/HUD) — це **справжні експорти з редактора quarks.art**
|
||
(`Object3D.toJSON()` на `Group` з `ParticleEmitter`-дітьми, кожен зі своїм
|
||
готовим, підібраним дизайнером `ps` — shape/speed/color/behaviors, і
|
||
реальними текстурами, вбудованими як base64: `cfxr stretch smoke arc
|
||
dissolve.webp`, `novalines.webp` — назва "novalines" **буквально "лінії
|
||
нової" = промені-риски**, це саме те, що користувач мав на увазі скріном).
|
||
`VFX_Lootable_Hit` = 2 емітери ("StretchSmoke" + "SharpImpact" — це і є
|
||
ray-burst). `VFX_Lootable_Destroy` = 4 емітери (дим, уламки-Pieces,
|
||
Ground_Dirt як реальна 3D-mesh геометрія (`renderMode: Mesh`), пилова хмара).
|
||
**Жодного SDK/іншого коду проєкту ці файли не використовували взагалі** —
|
||
чисто сирі ассети, що чекали на підключення. Замінив увесь ручний
|
||
`SparkFxC` на завантаження цих реальних префабів — жодна власноруч
|
||
підібрана крива/швидкість не заміняє справжній дизайнерський ассет.
|
||
|
||
**Що таке VFX**: "visual effects" — тут конкретно означає one-shot
|
||
частинкові ефекти (спалахи/дим/уламки), авторовані окремо в
|
||
редакторі quarks.art і експортовані як самодостатній JSON (геометрія +
|
||
матеріали + текстури-base64 + вже налаштовані `ParticleSystem` параметри
|
||
для кожного емітера) — не код, чистий даних-ассет, який рушій (`three.quarks`)
|
||
вміє розпарсити назад у робочі `Object3D`.
|
||
|
||
## `PropVfxC.ts` — новий контролер, замінив `SparkFxC.ts`
|
||
Завантажує обидва префаби ОДИН РАЗ при `init()` через сирий
|
||
`QuarksLoader` (`three.quarks`) + `Template3d.manager` (`@hitplay/playable_template`),
|
||
**НЕ** через SDK-хелпер `quarksLoader()`/`ConvertToBase64WhenRelease`
|
||
(паттерн `meshes.ts`/`images.ts`) — свідомо, з причини:
|
||
|
||
**⚠️ Чому не той самий паттерн, що і images/meshes**: `quarksLoader(base64String)`
|
||
жорстко очікує рядок формату `data:...;base64,XXXX` (робить
|
||
`base64String.split(",")[1]` потім `atob(...)`). Це працює лише ПІСЛЯ
|
||
build-time AST-трансформації (`convertToBase64InAST`, підключена в
|
||
`vite.config.js`), яка й замінює виклик `ConvertToBase64WhenRelease()` на
|
||
реальний base64 рядок. У **звичайному `vite dev`** (як я весь час тестую
|
||
через Playwright!) сам хелпер — лише прохідний passthrough, що повертає
|
||
ГОЛИЙ ШЛЯХ (`"resources/vfx/....json"`) без коми — `.split(",")[1]` дав би
|
||
`undefined`, і `atob(undefined)` зламав би завантаження саме в dev-режимі,
|
||
хоча в build/export він працював би. Замість цього ризику — звичайний
|
||
Vite JSON-імпорт (`import json from "../resources/vfx/VFX_Lootable_Hit.json"`),
|
||
який Vite вміє інлайнити нативно в БУДЬ-ЯКОМУ режимі (dev/build/export)
|
||
без жодного fetch — і сирий `new QuarksLoader(Template3d.manager).parse(json)`
|
||
(синхронний, повертає `Object3D` напряму, `onLoad` callback не потрібен,
|
||
бо всі текстури вже base64 в самому JSON, немає мережевого чекання).
|
||
Додав `"resolveJsonModule": true` в `tsconfig.json` (був відсутній) — без
|
||
цього `tsc` (не сам vite/esbuild — ті й так все розуміють) скаржився б на
|
||
JSON-імпорт типами.
|
||
|
||
`PropVfxC.spawnHit(point)`/`spawnDestroy(point)` — клонують відповідний
|
||
завантажений шаблон (`.clone()` на `Group`), виставляють `position`,
|
||
форсують `QuarksUtil.setAutoDestroy(instance, true)` (в оригінальних
|
||
префабах `autoDestroy: false` — дизайнер, ймовірно, керував завершенням
|
||
вручну в своєму інструменті; нам потрібен чистий "one-shot і забути"),
|
||
`QuarksUtil.addToBatchRenderer(instance, renderer)` (реєструє КОЖЕН
|
||
`ParticleEmitter` в дереві з рендерером — без цього нічого не малюється),
|
||
`QuarksUtil.play(instance)`. Кожен `ParticleSystem` з `autoDestroy`
|
||
прибирає СЕБЕ (свій `ParticleEmitter`-нод) з дерева, коли його частинки
|
||
померли — але порожній корінь-`Group`, який я додав в сцену, сам не
|
||
видаляється (нема кому), тож прибираю його окремим `setTimeout`
|
||
(`CLEANUP_DELAY_MS=1500`, з запасом під найдовший `duration+life` в обох
|
||
префабах).
|
||
|
||
`BreakablePropC.playHitFeedback` кличе `PropVfxC.spawnHit(contactPoint)` на
|
||
кожному хіті (як і раніше з `SparkFxC`); `BreakablePropC.destroy()`
|
||
додатково кличе `PropVfxC.spawnDestroy(...)` в позиції крейта — цього не
|
||
було в hand-rolled версії взагалі (не було Destroy-ефекту), додав одразу,
|
||
бо це буквально друга половина того самого знайденого ассета.
|
||
|
||
## ⚠️ Знахідка (потребує рішення користувача, ще не виправлено): "StretchSmoke"-шар вилітає далеко від крейта і виглядає як артефакт
|
||
Перевірено в браузері (Playwright): "SharpImpact" (промені/nova-спалах,
|
||
`novalines.webp`) рендериться коректно ПРЯМО на крейті в момент хіта —
|
||
саме той ефект, що відповідає скріну користувача. Але другий емітер того
|
||
самого префаба, "StretchSmoke" (`startSpeed:14`, `worldSpace:true`, життя
|
||
0.2-0.3с — тобто до ~4 world units прольоту по прямій!), у нашій сцені
|
||
летить ДАЛЕКО від крейта (видно на скріні як сірувата паличка десь у
|
||
верхній частині екрана, повністю відірвана від точки удару) — швидше за
|
||
все, дизайнер тюнив цей ассет під інший масштаб сцени/камери. Це
|
||
відтворюється на КОЖНОМУ хіті (не витік/застигла частинка — просто кожен
|
||
новий хіт заново вилітає в приблизно те саме "неправильне" місце).
|
||
**Ще не виправлено** — варіанти: (а) лишити як є (автентичний ассет), (б)
|
||
притлумити цей конкретний емітер (зменшити `startSpeed`/життя клоном
|
||
префаба перед грою), (в) прибрати "StretchSmoke" зовсім і лишити тільки
|
||
"SharpImpact". Потребує візуальної перевірки користувачем — не вирішував
|
||
сам, це пряма зміна дизайнерського ассета.
|
||
|
||
Destroy VFX (`VFX_Lootable_Destroy`, 4 емітери включно з mesh-based
|
||
"Ground_Dirt") підключений і не кидає помилок в консолі, але **ще не
|
||
підтверджений візуально** — не вдалось надійно спричинити повне
|
||
знищення крейта в тестовому прогоні за відведений час.
|
||
|
||
## Наступні кроки (ще не реалізовано, чекає на пріоритети користувача)
|
||
HP-бар (потребує рішення: дискретні стейджі vs. реальний HP-пул?) і числа
|
||
урону (DOM чи sprite в 3D-просторі? теж потребує реального numeric HP,
|
||
якого зараз нема) — ще не почато. `PassionOne-Black.otf` (в `temp/`,
|
||
ще не імпортований) — ймовірно призначений саме для цього.
|