Что такое мягкие частицы в играх
Что такое мягкие частицы в играх
Это вторая часть нашего гайда. Первая, где собраны основные настройки вроде разрешения, качества текстур и теней, вы можете прочитать по ссылке.
Качество освещения (Lightning Quality)
То, насколько правдоподобно симулируется освещение в игре. Если это единственный подобный параметр в игре, то именно в эту настройку заложили уйму других, будь-то и объемный свет, и рассеивание лучей, и отражения, а иногда даже глобальное затенение. Освещение — это, пожалуй, вообще едва ли не самое основное из всего, что влияет на красоту картинки: оно делает ее объемной, натуралистичной, правдоподобной. Но и ресурсов все это дело «кушает» тоже немало. Именно поэтому, например, Nvidia так расхваливает свои новые RTX-видеокарты — они изначально разработаны под Ray Tracing — метод рендеринга, предполагающий правдоподобную симуляцию каждого луча.
Влияние на производительность
Зависит от движка, но почти во всех современных играх — очень сильное. Симулировать свет — это очень непросто, так что врубайте «ультра» только если у вас действительно мощная видеокарта.
Качество эффектов (Effects Quality)
Влияние на производительность
Тоже зависит от игры, чаще всего не особенно высокое. Но чем выше этот параметр, тем сильнее будет нагружаться ваша видеокарта в загруженных сценах, например, при масштабных перестрелках. Так что если игра начинает «подлагивать» в особо динамичные моменты, можно попробовать поиграться с этим ползунком, прежде чем снижать, например.
…Качество шейдеров (Shader Quality)
Шейдеры — это специальные программы для вашей видеокарты, исполняемые ее процессором. Грубо говоря, это такие «инструкции» от игры вашей GPU, по которым та понимает, как именно нужно отрисовывать тот или иной эффект. Чаще всего шейдеры используются для улучшения освещения, затенения, создания эффектов преломления лучей в воде (помните, как взрывала мозг та самая «шейдерная водичка из Half-Life 2: Lost Coast?), отражений, рассеиваний и так далее. Так что да, эта опция работает в тандеме с другими параметрами: качеством освещения и качеством теней. Существует три вида шейдеров: вершинные, геометрические и пиксельные, но игры, где можно отрегулировать качество каждого из них отдельно, встречаются невероятно редко.
Соответственно, чем выше качество шейдеров, тем лучше описанные выше эффекты, красивее тени и свет, реалистичнее геометрия — и тем сильнее нагрузка на видеокарту. Именно на видеокарту — потому что шейдеры считаются только GPU.
Влияние на производительность
Чаще всего — высокое. Например, в GTA V это один из самых «тяжелых» параметров в игре — снизив качество шейдеров с «Ультра» на средниее значение, вы получите прирост больше, чем в 15 FPS. Но бывает и так, что снижение этого параметра почти ничего не дает, как, например, в Mass Effect Anromeda.
Мягкие частицы в WebGL и OpenGL ES
Системы частиц это одни из самых простых способов сделать 3D сцену визуально богаче. В одном из наших Android приложений 3D Buddha Live Wallpaper достаточно простая сцена, которой было бы неплохо добавить чуть больше деталей. И когда мы думали как добавить разнообразия изображению то самым очевидным решением заполнить пустое пространство вокруг статуи Будды стало добавление клубов дыма или тумана. Благодаря использованию мягких частиц мы достигли довольно хорошего результата. В этой статье мы детально опишем реализацию мягких частиц на чистом WebGL / OpenGL ES без использования сторонних библиотек и готовых 3D-движков.
Разница между старым и обновленным приложением даже превзошла наши ожидания. Простенькие частицы дыма существенно улучшили сцену, сделали ее богаче и полнее. Клубы дыма это и дополнительные детали за которые “цепляется глаз”, а также способ сделать переход между основными объектами и фоном более плавным:
Мягкие частицы
Так что такое эти мягкие частицы? Вы можете помнить что во многих старых играх (времен Quake 3 и CS 1.6) эффекты дыма и взрывов имели очень четкие плоские границы на пересечении частиц с другой геометрией. Все современные игры уже не имеют подобных артефактов благодаря использованию мягких частиц — то есть частиц с размытыми, “мягкими” краями вокруг прилегающих объектов.
Рендеринг
Что требуется для того чтобы сделать частицы мягкими? Во-первых, нужна информация о глубине сцены для того чтобы определить места пересечения частиц с другими объектами и смягчить их. Затем нам нужно определить места пересечения геометрий сцены и частицы путем сравнения глубины сцены и частицы во фрагментном шейдере — пересечения там, где глубины одинаковые. Далее мы рассмотрим процесс рендеринга пошагово. Обе реализации сцены под Android OpenGL ES и WebGL одинаковы, основное отличие только в загрузке ресурсов. Реализация на WebGL имеет открытый исходный код и вы можете взять его тут — https://github.com/keaukraine/webgl-buddha.
Рендеринг карты глубины
Для рендеринга карты глубины сцены, сперва нам потребуется создать текстуры для карты глубины и цвета и назначить их определенному FBO. Это делается в методе initOffscreen() в файле BuddhaRenderer.js.
Сам рендеринг Actual объектов сцены в карту глубины выполняется в методе drawDepthObjects(), который отрисовывает статую Будды и плоскость пола. Однако, тут есть одна хитрость для улучшения производительности. Поскольку на данном этапе рендеринга нам не нужна информация о цвете, а лишь глубина, рендеринг в цветовой буфер отключается вызовом gl.colorMask(false, false, false, false), а затем включается снова вызовом gl.colorMask(true, true, true, true). Функция glcolorMask() может выключать и выключать запись красного, зеленого синего и альфа компонента по отдельности, так что для того чтобы полностью отключить запись в буфер цвета мы ставим всем компонентам флажок false, а затем включаем их для рендеринга на экран, выставляя их все в true. Результат рендеринга в текстуру глубины можно увидеть, раскомментировав вызов drawTestDepth() в методе drawScene(). Поскольку текстура карты глубины имеет только один канал, она воспринимается как только красная, синий и зеленый каналы равно нулю. Визуализация карты глубины нашей сцены выглядит так:
Рендеринг частиц
Код шейдера, который используется для отрисовки частиц находится в файле SoftDiffuseColoredShader.js. Давайте разберемся как он устроен.
Основная идея поиска пересечения геометрий частицы и сцены состоит в сравнении значения текущей глубины фрагмента с сохраненным значением из карты глубины.
Первый шаг в сравнении глубин это линеаризация значений глубин, поскольку оригинальные значения экспоненциальные. Это делается с помощью функции calc_depth(). Эта техника хорошо описана здесь — https://community.khronos.org/t/soft-blending-do-it-yourself-solved/58190. Для линеаризации значений нам понадобится юниформ-переменная vec2 uCameraRange, компоненты x и y которой содержат значения ближней и дальней плоскостей отсечения камеры. Затем шейдер вычисляет линейную разницу между глубиной частицы и сцены — это значение сохраняется в переменной a. Однако, если мы будем применять это значение к цвету фрагмента, мы получим слишком прозрачные частицы — цвет будет затухать линейно от любой геометрии позади частицы, и затухать довольно быстро. Вот как выглядит визуализация линейной разницы глубины (Вы можете раскомментировать соответствующую строчку кода в шейдере и увидеть ее):
Чтобы частицы были более прозрачными только возле границы пересечения (в районе a=0) мы применим функцию GLSL smoothstep() к значению переменной a со значением перехода от 0 до коэффициента, заданного в юниформе uTransitionSize, который определяет ширину прозрачного перехода. Если Вы желаете узнать больше о работе функции smoothstep() и увидеть пару интересных примеров ее использования, рекомендуем прочитать эту статью — http://www.fundza.com/rman_shaders/smoothstep/. Финальный коэффициент сохраняется в переменной b. Для режима миешивания цветов, используемого в нашей сцене, достаточно просто перемножить цвет частицы взятый из текстуры на этот коэффициент; в других реализациях частиц Вам может понадобиться изменение например только альфа канала. Если в шейдере раскомментировать строчку кода для визуализации этого коэффициента то результат будет выглядеть так:
Оптимизация отрисовки спрайтов
В этой сцене мелкие пылинки отрисовываются как точечные спрайты (примитивы типа GL_POINTS). Этот режим удобен тем что он автоматически создает готовую квадратную геометрию частицы с текстурными координатами. Однако, они имеют и недостатки, которые делают их использование неуместным для крупных частиц клубов тумана. Прежде всего, они отсекаются плоскостями отсечения матрицы камеры по координатам центра спрайта. Это приводит к тому что они резко исчезают из вида на краях экрана. Также, квадратная форма спрайта не очень оптимальна для фрагментного шейдера так как он вызывается и в тех местах где текстура частиц пустая, что вызывает заметную излишнюю перерисовку. Мы используем оптимизированную форму частицы — с обрезанными краями в тех местах где текстура полностью прозрачна:
Такие модели для частиц обычно называются billboard. Конечно, они не могут быть отрисованы как примитивы GL_POINTS, поэтому каждая частица рисуется отдельно. Это создает не очень много вызовов drawElements, во всей сцене всего 18 частиц тумана. Они должны быть размещены в произвольных координатах, масштабированы но повернуты таким образом, чтобы всегда быть перпендикулярными к камере независимо от ее положения. Это достигается модификацией матрицы, описанной в этом ответе на StackOverflow. В файле BuddhaRenderer.js есть метод calculateMVPMatrixForSprite() который создает MVP-матрицы для billboard моделей. Он выполняет все обычные трансформации перемещения и масштабирования а затем использует resetMatrixRotations() для сброса компонента вращения матрицы model-view перед тем как она перемножается на матрицу проекции. Результирующая матрица выполняет трансформацию в результате которой модель всегда направлена ровно на камеру.
Результат
Финальный результат можно посмотреть вживую здесь.
Можете изучать и переиспользовать для своих проектов исходный код с Github.
Мотор! или Что такое игровая физика
Разработчикам при создании игры приходится искать баланс не только в механиках, но и в физике. Реализм или аркада? В общем-то, кому что нравится. Главное — фан и удовольствие. Нужно создать фундаментальные законы своего мира, и объяснить, что возможность ходить по потолку — механика, а не баг.
Насколько сложной должна быть игровая физика, какие виды бывают и на какие хитрости идут разработчики при ее реализации — в переводе под катом.
Физика в видеоиграх часто воспринимается как должное. Если персонаж прыгает, он обязан приземлиться, а не улететь в космос (хотя при достаточно долгой игре в Skyrim, подобное все равно может случиться). Мы ждем, что объекты в игре будут вести себе как в жизни (баги в расчет не берем).
Программирование физики может сводиться к одному-двум методам с парой строчек кода. А может и к сложной системе с отдельным физическим движком (например, Havok или PhysX) с миллионами строк кода. Независимо от сложности игровая физика делится на две категории: физика твердого тела и физика мягкого тела.
Физика твердого тела необходима в большинстве 2D- и 3D-игр. Физика мягкого тела описывает действие сил на объект, который принимает различные формы (например, флаг). Отобразить мягкое тело намного сложнее, поэтому такой подход используют гораздо реже.
Важная роль игровой физики
Игровая физика служит разным целям, но самые главные — интуитивность и веселье. Если объект ведет себя непредсказуемо, будет сложно понять правила игры.
Если бы мяч в FIFA 20 каждый раз отскакивал в случайном направлении, было бы невозможно забить гол. Разработчики стараются воссоздать отскок мяча в зависимости от его траектории, скорости и других факторов, действующих в реальном мире. Чтобы игрок интуитивно понимал, как обращаться с мячом или другими объектами. К слову, у FIFA 20 куча плохих отзывов именно потому, что ее физика работает не так, как того ожидали фанаты.
При этом игры не обязаны строго соблюдать естественные законы природы. Главное — игра должна приносить удовольствие, а реализация реальных физических законов может уничтожить весь экспириенс. Представьте Grand Theft Auto V с суровой земной физикой (но если очень хочется, то можно поставить специальный мод). Даже легкая авария на высокой скорости закончилось бы фатально, убило бы темп и атмосферу. Не очень-то весело.
Разработчик должен найти нужный баланс между веселой игрой и игрой с реалистичной физикой. И он часто зависит от целевой аудитории. Хороший пример — гонки.
Многим нравятся аркадные гонки (Need For Speed), в которых касание отбойника или резкий поворот слабо сказываются на управлении машиной. Другие предпочитают реалистичные гоночные симуляторы (Gran Turismo).
Но даже создавая симуляторы, разработчики пытаются привлечь новую аудиторию — Gran Turismo делала ставку на фотореализм (и в какой-то мере это сработало). Но в итоге Polyphony Digital добавила аркадный режим, чтобы захватить рынок побольше.
Физика твердого тела
Говоря об игровой физике, мы обычно имеем в виду физику твердого тела (rigid body physics, RBP). Она описывает и воспроизводит физические законы, применимые к твердым массам вещества. Мяч в FIFA 20 — твердое тело, которым управляет физика игры.
Неважно рассматриваем мы 2D-тайтлы типа Pong или 3D типа Skyrim — в большинстве игр есть линейная физика твердого тела.
Физика 2D-игр
Возьмем Pong в качестве примера. Два твердых тела (мяч и ракетка) снова и снова сталкиваются друг другом. Звучит не слишком воодушевляюще. У дедушки видеоигр не было реалистичной физики.
Во-первых, программисты проигнорировали гравитацию, трение и инерцию. Был просто мяч, перемещающийся туда-сюда с постоянной скоростью.
Во-вторых, угол отскока мяча от ракетки был рассчитан неточно. Мяч полностью игнорирует закон отражения: если не учитывать вращение и прочие факторы, угол падения мяча на поверхность равен углу его отскока от нее. В Pong угол отражения определялся тем, насколько близко мяч был к центру ракетки в момент соприкосновения. Изначальная траектория не имела значения. Игроки могли полностью изменить инерцию мяча, несмотря на вектор его движения.
Траекторию мяча стали больше учитывать в поздних версиях и в других подобных играх. Например, в Breakout. Но даже там нет реализма, иначе веселая игра превращается в скучную и сложную.
Игры с артиллерией первыми стали учитывать гравитацию и сопротивление в своих механиках. Пользователи по очереди стреляли пушечными ядрами, стрелами и ракетами, чтобы уничтожить базу противника. Такие игры учитывали полуреалистичную баллистику, то есть — угол запуска, гравитацию, сопротивление ветра и изначальную скорость. Но опять-таки дизайнеры не стремились сделать все как в реальном мире. Их целевой аудиторией были обычные люди, а не баллистические эксперты.
Поведение твердых тел (в первую очередь снарядов) зависело от нескольких сил. В соответствии с ними менялись анимации. Стрелы и ракеты — отличный пример анимации твердых тел в подобных играх. Плоскость снаряда могла измениться во время полета, а стрела так и оставалась прямой. Две точки на объекте в системе твердых тел всегда будут на одинаковом расстоянии друг от друга.
Игры типа Donkey Kong и Mario Bros. сильно повлияли на физику 3D-проектов. Марио подружился с основными физическими законами — гравитацией, импульсом и инерцией. Прыжок стал основной механикой и остался в игровой индустрии навсегда.
Подпрыгнувший объект должен упасть обратно. Вопрос только в том, насколько высоко он поднимется и насколько быстро упадет? И насколько реалистичной должна быть гравитация в игре?
Если бы Марио подчинялся реальным законам физики, он бы никогда не прошел первый уровень. Баланс пришлось менять в угоду веселого геймплея и ожиданий игроков.
Дальнейшие игры серии расширили эти границы — появился двойной прыжок. В этой франшизе его впервые добавили в Super Mario 64, но ранее его уже использовали в Dragon Buster в 1984 году.
Двойной прыжок стали активно использовать в платформерах (иногда даже слишком). И он до сих пор есть во многих современных проектах, включая 3D. Например, Devil May Cry и Unreal Tournament.
Физика 3D-игр
Физика в 3D-играх не сильно отличается от физики в 2D-проектах. Вычисления усложняются за счет третьего измерения (оси Z) и того, что объекты состоят из нескольких твердых тел.
В большинстве 2D-игр разработчикам нужно единовременно обрабатывать данные всего нескольких столкновений твердых тел. Например: Марио прыгает на Купу. Марио может дотронуться до любой части Купы. В зависимости от точки соприкосновения либо Купа прячется в панцирь, либо Марио теряет жизнь. В любом случае речь идет о единственном касании.
В 3D-играх одновременно сталкиваются сразу несколько твердых объектов. В Uncharted, когда Дрейк взбирается по скале, программа следит как минимум за его руками и ногами — отдельными твердыми телами. Он может подпрыгнуть и схватиться за лестницу одной рукой или двумя, и анимация будет разной.
В 3D-играх (и некоторых 2D) конечности персонажей разбиты на несколько твердых тел, которые соединены суставами. То есть модель человеческой руки состоит из предплечья и кисти, которые соединены запястьем и крепятся к плечу локтевым суставом. Это описывает рэгдолл-физика (от англ. ragdoll — тряпичная кукла).
Изображение: University of California, Riverside
Соединения твердых тел (суставы) создаются в системе скелетной анимации игрового движка. Каждое твердое тело должно двигаться по определенным правилам, чтобы выглядеть реалистично. Для просчета движений программисты используют различные техники. Самая известная — алгоритм Физерстоуна, ограничительный подход, который не дает конечностям болтаться как попало.
Есть и другие подходы к работе с рэгдоллом: интегрирование Верле (Hitman: Codename 47), инверсная кинематика (Halo: Combat Evolved и Half-Life), смешанный рэгдолл (Uncharted: Drakes Fortune и многие другие) и процедурная анимация (серия Medal of Honor).
Все эти техники направлены на то, чтобы тело не обмякло слишком быстро и не падало на землю, как тряпичная кукла. Движение твердых тел, объединенных в модель, ограничено, поэтому они ведут себя предсказуемо.
Напомню, всегда нужно искать баланс между реализмом и весельем. Даже если игра будет немного «читерить».
Возьмем серию Sniper Elite. В реальном мире стрелок должен принимать в расчет кучу переменных: скорость ветра, направление ветра, диапазон, перемещение цели, мираж, источник света, температура, давление и эффект Кориолиса.
Если бы Rebellion создавала аутентичный снайперский симулятор с учетом всех переменных, игра стала бы очень сложной. Их игнорирование обусловлено не только возможностями современных процессоров. Среднестатистический пользователь не просто не хочет просчитывать все эти факторы во время игры, он не хочет даже знать о них. Выгоднее позволить игроку использовать прицел и показывать полет пули в слоу-мо.
В Call of Duty: Modern Warfare есть уровень, где нужно поразить цель с дальнего расстояния. Игрок должен учесть эффект Кориолиса, а также скорость и направление ветра. Некоторым нравится такой челлендж, но я ее забросил.
Гонки — еще один жанр, в котором требуется много вычислений по твердым телам и действующим на них силам. Колеса контактируют с дорожным покрытием, подвеска соприкасается с колесами, машины сталкиваются друг с другом. Еще другие объекты прямо или косвенно участвуют в столкновениях.
Физические силы, действующие на машины при повороте, обычно упрощены. Дрифтинг в них простой, но при этом достаточно сложный — игроки должны чувствовать удовлетворение.
В симуляторах Gran Turismo и Assetto Corsa действуют более реалистичные силы. Например, Assetto Corsa Competizione (версия 1.0.7) использует пятиточечную модель шин. Она включает две точки на передней кромке шины, две на задней и одну посередине — все вместе действуют как объединенное твердое тело. Точки могут двигаться и изгибаться в трех измерениях, независимо реагируя на внешние силы и контакт с поверхностью. Дополнительные точки значительно увеличивают количество вычислений, которые выполняет движок.
Физические модели в 3D-тайтлах намного сложнее, чем в 2D. Приходится отслеживать больше переменных и точек соприкосновения. Но большинство вычислений линейные, поэтому такие модели гораздо проще, чем модели мягкого тела.
Физика мягкого тела
Физика мягкого тела (soft body physics, SBP) описывает деформируемые объекты. Она используется реже и сильно урезана в видеоиграх из-за огромного количества вычислений.
Мягкие тела — это одежда, волосы, скопления частиц типа дыма или тумана. Точки твердого тела всегда остаются на одном и том же расстоянии друг от друга. А мягкое тело может деформироваться и двигаться так, что расстояние между его точками будет меняться.
Деформируемые твердые тела
Движение мягкого тела может быть ограничено. Все точки флага всегда будут оставаться на флаге, они не могут отделиться. Диапазон отклонения точек друг от друга зависит от расстояния между ними на разглаженном флаге.
Смежные точки всегда остаются смежными. Удаленные точки могут приближаться, но при этом не могут удалиться друг от друга дальше расстояния, на котором они зафиксированы на расправленном флаге.
Количество вычислений для мягкого тела превосходят возможности CPU и GPU. Поэтому разработчики упрощают и хитрят. Например, используют зацикленную анимацию. Но такая картинка покажется неестественной через какое-то время. Лучше к такому лайфхаку не прибегать, если объект находится в центре внимания.
У одежды почти такие же свойства мягкого тела, как и у флага, но ее физика еще сложнее. Во-первых, потому что игрок точно обратит на нее внимание. Во-вторых, потому что она зачастую более динамична: игрок оказывает на нее собственное влияние. Отличный пример — плащ Бэтмена в серии Arkham.
Дизайнеры не могут использовать зацикленную анимацию на плаще, потому что его движение зависит от действий игрока. Если игрок направит персонажа влево, плащ должен сместиться вправо, чтобы реалистично отобразить инерцию и сопротивление воздуха.
Тут в дело вступают физические движки. В Batman: Arkham Knight студия Rocksteady использовала APEX Cloth PhysX. Этот инструмент позволяет создавать маску для тел, отображающих одежду, и настраивать параметры их движения. В зависимости от конфигурации можно отобразить все от шелка до мешковины.
Для улучшения производительности можно ограничить воздействие естественных сил на ткань. Например, Wind Method (Отображение ветра) можно установить на Accurate (Точное) или Legacy (Частичное). Частичное отображение игнорирует мелкие колебания, производится меньше вычислений.
Не все точки на ткани нужно учитывать — они могут действовать группами. Это сокращает количество вершин, данные о которых нужно обрабатывать. При этом не все эти группы взаимодействуют друг с другом как в реальном мягком теле. Они в основном влияют только на ближайшие точки, поэтому число математических вычислений сводится к приемлемому уровню.
Системы частиц мягкого тела
Отобразить дым или облака еще сложнее. Точки таких объектов могут перемещаться нелинейно относительно друг друга. Какие-то точки могут перемещаться за пределы образной границы объекта и даже формировать другие мягкие тела.
Физические движки значительно улучшили системы частиц за последние годы. Посмотрите на приветственный экран из Skyrim и насколько там реалистично выглядит дым.
У каждой частицы в системе мягкого тела статическая продолжительность жизни. Это период с момента ее возникновения до момента ее исчезновения (через какое-то время источник частиц создаст ее снова). В течение этого периода точка перемещается с учетом заданных параметров.
Рассмотрим дым от костра в качестве примера. Каждая частица перемещается вверх от источника: нелинейно, кружась и случайным образом меняя свое положение в пространстве. Так и поднимаются, пока не закончится их продолжительность жизни, а затем удаляются.
Продолжительность жизни влияет на то, насколько естественно выглядит система частиц. При долгой продолжительности можно создать довольно реалистичный дым от костра, но это сильно нагрузит процессор. Короткая — сокращает количество вычислений, но частицы успеют лишь слегка подняться до исчезновения.
Дым в заставке Skyrim выглядит круто, просто потому что на экране больше ничего не происходит. Всю мощность процессора и видеокарты можно направить на симуляцию частиц дыма с очень длинной продолжительностью жизни.
В самой игре дым от огня выглядит уже не так реалистично. Он все еще довольно убедителен, но стал проще: разработчики сократили время отображения частиц в симуляции. Есть и другие уловки. Например, наложение нескольких статических слоев дыма
Физику мягкого тела очень аккуратно добавляют в игры. Во-первых, нет необходимости полной симуляции физики мягкого тела — как правило, она нужна только для эстетики. Во-вторых, точное воспроизведение системы мягкого тела требует слишком большого количества вычислений.
Подытожим
Физика видеоигр — сложная область, в которой разработчики ищут баланс между реализмом и ограничениями вычислительных мощностей. Хитрости, упрощения и физические движки позволяют быстро создать довольно реалистичную физику, чтобы главное внимание уделить более важным аспектам игры.
Игра должна быть интересной. Реализм не так важен по сравнению с захватывающим геймплеем. Игровая физика по-прежнему важна — нужны интуитивно понятные правила. При этом их можно менять, чтобы обогатить геймплей (вспоминаем двойной прыжок).
Если хотите лучше разобраться в физике видеоигр, то посмотрите соответствующие разделы в руководстве Unity или руководстве Lumberyard.