Створення анімацій взаємодії з предметами в іграх

Створення анімацій взаємодії з предметами в іграх

Персонаж тягнеться до дверей, рукоятка знаходиться ровно там, де повинна бути — але рука проходить крізь неї, тому що двері розташовані на 15 сантиметрів ліворуч, ніж в оригінальному анімаційному файлі. Або персонаж піднімає предмет — і той телепортується в руку замість плавного захоплення. Це не баг риг, це архітектурна проблема: анімації взаємодії вимагають узгодження позицій об'єкту та персонажа в реальному часі, і реалізувати це без IK та правильної attachment системи не отримається.

Чому hardcoded interaction анімації не працюють в реальних проектах

Запекти повну взаємодію в один FBX-клип — спокусливо просто. Аніматор у Maya створює рендер персонажа з кружкою, експортує, імпортує в Unity. У сцені це виглядає правильно ровно один раз: коли персонаж стоїть ровно в тій же позиції, що й в вихідному файлі.

У грі персонаж може підійти до предмету з будь-якої сторони, об'єкт може лежати на різній висоті, можуть бути physics-симульовані предмети, які не знаходяться в передбачуваній позиції. Повна запечена анімація ламається негайно.

Рішення — розділити анімацію на дві частини. Base animation задає загальний arc руху тіла, anticipation позу та follow-through. IK layer підтягує кінцівку до реальної позиції об'єкту в runtime. Unity Animation Rigging package надає Chain IK Constraint та Two Bone IK Constraint з Tip та Target transform'ами, які керуються скриптом, що отримує позицію інтерактивного об'єкту.

Вага IK constraint не повинна бути постійною 1.0. Правильна схема: на початку анімації (approach фаза) weight = 0, тіло рухається по base clip. По мірі наближення руки до об'єкту weight інтерполюється к 1.0 через AnimationCurve, яку контролер оновлює через constraint.weight = ikWeightCurve.Evaluate(normalizedAnimationTime). Це створює ощущение того, що персонаж «нащупує» предмет, а не стрибає до нього по прямій.

Attachment та parent constraints

Коли персонаж берет предмет в руку, об'єкт повинен стати дочірнім для bone або для спеціального attach point. У Unity найнадійніший спосіб — GameObject з Transform, прикріплений до кості руки (grip_r / grip_l), до якого об'єкт Attach'ится через transform.SetParent() в момент Animation Event.

Animation Event ставиться на конкретний кадр анімації — той момент, коли хват вже закрився. Якщо поставити раніше, предмет прострибне в руку до закриття хвату. Якщо пізніше — буде кадр, коли рука вже закрита, а предмет ще лежить на землі.

Для точності хвату використовується Attachment Offset: предмет має пустий GameObject з іменем типу grip_socket, і при attachment його локальний transform вирівнюється по grip_r attach point'у персонажа через targetObject.transform.position = gripPoint.position + offset. Offset вичисляється заранее в Editor та зберігається в ScriptableObject для кожного типу предметів.

Варіативність через Constraint blending

Якщо в грі кілька типів однієї взаємодії (поднять легкий предмет, поднять важкий ящик, поднять раненого союзника) — не потрібно робити повністю окремі анімації. Достатньо зробити базову анімацію + additive шар для важкого об'єкту (пригинання корпусу, напруження рук). Additive weight при цьому керується через ItemWeight параметр, який Animator Controller отримує з ItemData ScriptableObject.

Override Animator Controller з AnimatorOverrideController — корисний, коли різні предмети вимагають різні клипи для однієї і тієї ж state. Наприклад: Interact_UseItem state в базовому контролері може бути перевантажено для конкретного предмету через override без зміни всієї Animator Controller логіки.

Процес створення

Початок — референс-відео або покадровий breakdown взаємодії. Для pick-up анімацій це особливо важливо: реальна людина ніколи не бере предмет прямолінійним рухом — є arc, є anticipation пальців, є зміщення ваги.

Виробництво: блокинг base animation без IK → розстановка attach/detach Animation Events → настройка IK constraints в Unity → тест з реальною геометрією сцени → фінальний polish вторинних рухів.

Вартість розраховується індивідуально. Для точної оцінки потрібні: список типів взаємодій, скриншоти або відео геймплею, опис існуючої систем IK та Animator Controller структури.