Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
T-поза персонажа напомнила о забавном баге в игре "The Last of Us". В зимнем эпизоде (после Колорадского университета), в ходе боя с канибалами, Элли проходит через трубу и если замешкаться на выходе, то она впадает в Т-образное состояние и так продолжает перемещаться, пока игрок не подлетит к трубе обратно
3D-модель целиком состоит из взаимосвязанных треугольников
Мне, кстати, казалось, что треугольники считаются дурным тоном, что их стараются всячески избегать, предпочитая четырехугольники. Это не так?
На стадии моделирования 3Д художники стараются использовать квады, потому что с ними проще работать с геометрией, например, тесселлировать. Однако при экспорте из DCC tools (Maya, Max, Blender etc) в формат для игры вся геометрия конвертируется (опустим для простоты случай применения тесселляции в реальном времени на GPU) в треугольники: GPU для простоты умеет растеризовывать только их (ибо зачем усложнять hardware и создавать стопицот разных конвейеров для разных примитивов, если можно любой многоугольник разбить на треугольники).
Да, это правда. На этапе создания модели лучше работать с четырёхугольнкиами — с ними проще работать (делить, резать, выстраивать в линии...) и анимировать (меньше искажений чем с треугольниками). Но на этапе эскпорта в движок, все полигоны автоматически конвертируются в треугольники — на базовом уровне игровому движку и видеокарте проще всего визуализировать наименее сложные и однотипные плоскости.
ну, не совсем. Импорт в движок бывает разный и зависит от движка. В Юнити, например, можно импортировать модель оставив квады. А вот когда движок отправляет модель на рендер, туда уходит грубо говоря набор вершин, в треугольники они связаны лишь посредственно, только тем, что их индексы находятся в одном массиве. Но да, по сути видеокарта рисует именно треугольники.
Во времена Half-Life 1, когда начала использоваться эта технология, каждая вершина связывалась только с одной костью. В наши дни могут присоединяться даже к четырём костям, при этом каждой кости придаётся вес, от которого зависит степень влияния кости на вершину.
К сожалению, в РПГ играх по неизвестной мне причине части доспехов привязываются к нескольким костям сразу, из-за чего железный доспех крайне неестесственно растягивается или мнётся при каждом движении персонажа.
Потому что чтобы доспех не мнулся и не растягивался он должен иметь свой собственный жёсткий «скелет», но, увы, 3D-дизайнеры поступают проще не заморачиваясь с отдельным «скелетом» для латного доспеха, и в результате он мнётся и растягивается как обычная одежда.
Тут вопрос не в дизайне. Сделать скелет для доспеха не проблема, тем более, что (как уже замечено в комментарии выше) достаточно использовать оригинальный скелет, но прописать только по одной кости на треугольник. Проблема в другом: если он будет жестким — придётся очень тщательно следить за тем, чтобы ни в одной фазе тушка не вылезала сквозь доспех, что с учётом частично процедурной анимации вообще нереально. Разве что дополнительно следить за их коллизиями, что лишний гимор уже для движка.
Проблема в том что при привязке к одной кости, игнорируются анимации других костей. Если условно привязать нагрудный доспех только к «грудной» кости персонажа, то доспех при повороте персонажа будет пролезать сковзь персонажа в районе рук и пояса. Выход из этого есть — большее кол-во костей, в идеале отдельные кости под доспехи. Но чем больше костей — тем больше работы аниматорам и риггерам (это те кто привязывают модели к костям). А бюджеты у игр к сожалению не бесконечные. И даже в этом варианте доспех всё равно будет мнуться, просто не настолько сильно.
Чтобы сделать совсем реалистичное сочетание жёсткого доспеха и динаимического тела персонажа, нужна симуляция взаимодействия динамики и нединамики (условно говоря чтобы тело и мягкая одежда мнулась под воздействем жёстких пластин доспеха) — а это уже более затратный (в т.ч. для рендеринга) процесс.
Вообще процесс анимации и привязки к костям в играх это вечный геморой. Чем более свободна игра — тем больший геморой, т.к. надо предусматривать множество анимаций и множество персонажей (часто на одном скелете) и всё это делать ограниченными средствами. Это ещё более заметно в играх где можно менять одежду — привязывать разноразмерную одежду под одного персонажа это совсем невесело.
Чтобы сделать совсем реалистичное сочетание жёсткого доспеха и динаимического тела персонажа, нужна симуляция взаимодействия динамики и нединамики (условно говоря чтобы тело и мягкая одежда мнулась под воздействем жёстких пластин доспеха) — а это уже более затратный (в т.ч. для рендеринга) процесс.
Вообще процесс анимации и привязки к костям в играх это вечный геморой. Чем более свободна игра — тем больший геморой, т.к. надо предусматривать множество анимаций и множество персонажей (часто на одном скелете) и всё это делать ограниченными средствами. Это ещё более заметно в играх где можно менять одежду — привязывать разноразмерную одежду под одного персонажа это совсем невесело.
Есть еще куча всяких трюков для увеличения производительности, например использование билбордов (плейнов для деревьев, вместо сложной модели), использование импостеров (почти что спрайтов, то есть картинки вместе модели), так же разбитие пространства на сегменты при помощи деревьев (это кстати сразу напоминает ГТА) и куча куча всего, что можно на несколько больших статей расписать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О 3D-графике простыми словами