Войти
АртФорумОбщее

(Анимация) Взаимодействие между персонажами

Страницы: 1 2 3 Следующая »
#0
19:51, 11 мар. 2013

Допустим, мне надо сделать анимацию, где персонаж игрока напрямую взаимодействует с монстром, ну, например, протыкает его мечом и поднимает в воздух.
Есть какие-то особые приемы, чтобы адекватно это реализовать для игры? Слышал, что есть такой прием: в момент начала такой анимации скрываем модель монстра и включаем меш монстра, который зашит в файл с моделью игрока. Насколько это разумно? А если у меня три десятка монстров, то такой файл станет неподъемным.

Спасибо за любые советы :)


#1
12:26, 12 мар. 2013

arte_de_mort
> Допустим, мне надо сделать анимацию, где персонаж игрока напрямую
> взаимодействует с монстром, ну, например, протыкает его мечом и поднимает в
> воздух.
Арте, парные анимки можно синхронизировать в движке.
Т.е. делаем отдельные анимации на хероя и на монстра одинаковой длительности и скриптом их одновременно проигрываем.
Вся фишка в том, как их синхронзировать в пространстве.
Если в реализации предусмотрены пустые корневые кости (под ногами, а не в тазу), а в двиге объекты мира имеют иерархию то ситуация упрощается.
Тогда в пакете корневую кость монстра цепляшь на на конренвую персонажа и рисуешь.
А в двиге в начале приема суешь монстра в иерархию персонажа и запускаешь на обоих их анимку.
Можно и не в одной точке их располагать, но тогда сеч удаленность.
Минусы:
- Возможен артефакт в момент начале анимки - если персы перед анимкой оказались с иной удаленностью и вращением, чем планировалось. Будет соскок монстра к позиции для анимки, но его можно предусмотреть и устранить.
- В момент проведения приема общее твердое тело монстра не будет реагировать на физику. Но если ставить твердые тела по костям, это вообще не праблы.
Есть другой способ - просто проигрывать анимки без манипуляций с иерархией. Тогда если персы оказались на другой дистанции их проще скриптом в первые кадры подстроить друг к другу. Но это черевато, т.к. други события могут крутить корневую кость персонажа и десинхронизировать всю анимку. У биоварей в последних творениях можно увидеть такой косяк.
А описанный тобой подход не имеет смысла, т.к. он просто менее гибок. Вероятно, он применяется из-за ряда ограничений в движке.

#2
14:21, 12 мар. 2013

Можно двигать одного персонажа синхронно с определенной костью другого без ковыряния иерархии или подгона анимации.
Также можно миксовать, скажем, нижнюю часть "наездника" в позе езды с верхней частью, выполняющей другие анимации (удары, и т.п.).
Если речь идет о том, чтобы один персонаж лазил по другому, то все это надо готовить предварительно.
Например, можно обвесить скелет "лошадки" вспомогательными объектами, которые будут использоваться "наездником" в качестве точек опоры, по которым он будет перемещаться.
Соответствующие анимации можно врубать, опять же, либо по свойствам конкретной точки, либо в совокупности с действиями "лошадки", и т.д...

Интересный пример в этом плане- Shadow of the Colossus...

#3
14:59, 12 мар. 2013

KaZuaL
> Можно двигать одного персонажа синхронно с определенной костью другого без
> ковыряния иерархии или подгона анимации.
Черевато косяками.
Потом всяка другая херь добавиться, будет некорневые кости лапать.

#4
15:16, 12 мар. 2013

DanielSky
> Т.е. делаем отдельные анимации на хероя и на монстра одинаковой длительности и
> скриптом их одновременно проигрываем.
> Вся фишка в том, как их синхронзировать в пространстве.
Да я сначала думал сделать в одном файле две анимации, потом анимацию монстра экспортнуть отдельно, и в движке их одновременно проигрывать, но как раз проблема ориентации персонажей в пространстве относительно друг друга меня смутила.

> Если в реализации предусмотрены пустые корневые кости (под ногами, а не в
> тазу), а в двиге объекты мира имеют иерархию то ситуация упрощается.
> Тогда в пакете корневую кость монстра цепляшь на на конренвую персонажа и
> рисуешь.
> А в двиге в начале приема суешь монстра в иерархию персонажа и запускаешь на
> обоих их анимку.
> Можно и не в одной точке их располагать, но тогда сеч удаленность.
Не очень понимаю, зачем скелеты пихать в одну иерархию?
Вот как я представляю порядок действий исходя из твоего объяснения: изначально заботимся о том, чтобы персонажи не могли подходить друг к другу ближе, чем на Х метров, и не могли атаковать с расстояния больше Х+1 метров. Когда персонаж игрока проводит свой фаталити, то предполагается, что враг находится на расстоянии между Х и Х+1 метров от рута персонажа. Персонаж делает замах, в это время у нас есть доли секунды, чтобы повернуть врага лицом к нам и подвинуть (если он смотрит в другую сторону и находится чуток не там, где надо), после чего происходит уже тесное взаимодействие анимаций.
Правильно я понимаю? А, кажется я понял, зачем запихнуть врага в иерархию персонажа. Это даст нам возможность избежать других воздействий на рут врага, например, не дать ему начать  поворачиваться во время анимации фаталити. Но не проще ли врагу сделать state, в котором любое воздействие, кроме анимации фаталити, к руту запрещено?

KaZuaL
> Например, можно обвесить скелет "лошадки" вспомогательными объектами, которые
> будут использоваться "наездником" в качестве точек опоры, по которым он будет
> перемещаться.
> Соответствующие анимации можно врубать, опять же, либо по свойствам конкретной
> точки, либо в совокупности с действиями "лошадки", и т.д...
Интересная мысль. Спасибо.

#5
15:31, 12 мар. 2013

DanielSky
Во многих играх таким способом цепляют оружие юнитам, например.
имхо, по сути это не многим отличается от работы иерархии того же скелета.

#6
15:36, 12 мар. 2013

KaZuaL
С оружием всё просто - тупо присобачил его к кости или локатору, находящемуся в нужном месте (в руке), snap пивоты друг к другу, и радуешься :) Меня напрягает именно ориентация в пространстве двух персонажей, чтобы они в нужное время были в нужном месте.

#7
15:41, 12 мар. 2013

arte_de_mort
> А, кажется я понял, зачем запихнуть врага в иерархию персонажа. Это даст нам
> возможность избежать других воздействий на рут врага, например, не дать ему
> начать поворачиваться во время анимации фаталити. Но не проще ли врагу сделать
> state, в котором любое воздействие, кроме анимации фаталити, к руту запрещено?
Не. Это даст возможность не закрывать доступ к руту хероя и не синхронизировать с ним врага в каждом кадре.

#8
15:44, 12 мар. 2013

DanielSky
> Не. Это даст возможность не закрывать доступ к руту хероя и не синхронизировать
> с ним врага в каждом кадре.
То есть чтобы даже если игрок повернётся, насаженный на меч враг поворачивался вместе с ним? Так ведь я не хочу, чтобы во время фаталити игрок поворачивался и ходил, я хочу, чтобы он стоял на месте и крутил анимацию. То есть опять возвращаемся к тому, чтобы поставить его на время анимации в state, запрещающий операции над рутом.

#9
15:45, 12 мар. 2013

А в остальном, правильно я понял порядок действий?

#10
15:45, 12 мар. 2013

KaZuaL
> Во многих играх таким способом цепляют оружие юнитам, например.
> имхо, по сути это не многим отличается от работы иерархии того же скелета.
Да. На низком уровне вообще никаких отличий. Но, ИМХО, если есть иерархия объектов, что красивее жесткие взаимосвязи делать через нее.

#11
15:53, 12 мар. 2013

arte_de_mort
> То есть чтобы даже если игрок повернётся, насаженный на меч враг поворачивался
> вместе с ним? Так ведь я не хочу, чтобы во время фаталити игрок поворачивался и
> ходил, я хочу, чтобы он стоял на месте и крутил анимацию. То есть опять
> возвращаемся к тому, чтобы поставить его на время анимации в state, запрещающий
> операции над рутом.
Да он не должен ходить, но может быть масса других эффектов, которые могут создать неразрешимые проблемы.
Он может стаять на едущей платформе, а гоблин за ней. Его могут атаковать другие враги, и его надо подвинуть для другой анимки. Может надо будет его толкнуть, чтоб мимо пролез другой герой итп.
Стейт на героя может создать в будущем неразрешимые праблы.
arte_de_mort
> А в остальном, правильно я понял порядок действий?
Ну да. Но не надейся, что расстояние меж персами всегда будет ожидаемым, найдется паскуда, что его сместит и всех их не предусмотришь.

#12
15:58, 12 мар. 2013

arte_de_mort
> Меня напрягает именно ориентация в пространстве двух персонажей, чтобы они в нужное время были в нужном месте.
Ну, когда они уже сцепились, это ничем от оружия не отличается- тот, что прицепился, апает свою позицию относительно (кости, или чего-то там еще) "лошадки".
Если у лошадки есть зависимость поведения от наличия/поведения ноши, то она их отрабатывает.
И все.
Обновление позиции героя от положения кости другого персонажа ничем не напряжнее, чем обновление позиции героя при любом другом движении, имхо.

DanielSky
> ...Это даст возможность не закрывать доступ к руту хероя
А почему должен закрываться доступ к руту героя, если его не пихать чужую в иерархию?

> Да. На низком уровне вообще никаких отличий. Но, ИМХО, если есть иерархия объектов, что красивее жесткие взаимосвязи делать через нее.
Ну, это уже вкусовщина.)
Имхо, изменять иерархию- это ненужное телодвижение, когда можно просто апать координаты при наличии сцепления.

ЗЫ
> Ну да. Но не надейся, что расстояние меж персами всегда будет ожидаемым...
Для этого есть резкая смена ракурса камеры, прыжок, или просто скольжение...)

#13
16:51, 12 мар. 2013

KaZuaL
> А почему должен закрываться доступ к руту героя, если его не пихать чужую в
> иерархию?
Предполагается, что каждый кадр монстра к герою не шпилим.

KaZuaL
> Имхо, изменять иерархию- это ненужное телодвижение, когда можно просто апать
> координаты при наличии сцепления.
Рассмотрим Юнити. Иерархию ковырнуть придется один раз и в методе перса. А апать координаты надо в функции обновления экрана. А в ней гадить не хочется, там итак куча всякого собирается.
Понятно, что изменение глобальных координат монтстра в иерархии персонажа будет вычилсяься каждый кадр. Но это зашито в двиге и я предполагаю (предполагаю!) что это быстрее, т.к. оптимизировано на низком уровне.
А если брать С4, то изменение иерархии выглядит более естественным в логике движка, а ее не хочется портить :)

KaZuaL
> Для этого есть резкая смена ракурса камеры, прыжок, или просто скольжение...)
Кабы я заранее знал, где их подкладывать :)

#14
17:20, 12 мар. 2013

DanielSky
> ...оптимизировано на низком уровне...
Ну, если так, то да.)

Страницы: 1 2 3 Следующая »
АртФорумОбщее

Тема в архиве.