Country not specified
Unknown website Share

Apps4all

Страна: -
Город: -
Был онлайн: -
О себе:
 
08-07-2016, 10:59
Apps4all

Gameloft и Intel: сотрудничество для реализации высококачественной графики в Android на платформе x86

Автор: Стив Хьюз

Введение

Как правило, пользователи, в том числе и геймеры, разделяют используемые устройства на настольные и мобильные: от приложений на настольных компьютерах ожидают высококачественной графики, а на мобильных устройствах довольствуются относительно простыми графическими эффектами. При этом пользователи обычно осознают разницу в вычислительной мощности таких устройств и не жалуются на низкое качество графики. Тем не менее, начав изучать процессор Intel® Atom™ 4-го поколения (Bay Trail) в конце прошлого года, я понял, что его нельзя назвать маломощным. Более того, я увидел у этого процессора потенциал, достаточный для добавления «тяжеловесных» эффектов в подходящие игры. Если немного поработать, то можно создать очень красивое приложение для демонстрации всех доступных возможностей. Присмотревшись к возможным решениям, я решил поработать с компанией Gameloft над гоночной игрой GT Racing 2 (GTR2). Я уже знал команду разработчиков Gameloft, они никогда не жалели времени и сил, чтобы оптимизировать производительность и повысить качество своих игр.

В этой статье я описываю эффекты, реализованные разработчиками Gameloft в игре GTR2, и рассказываю о том, как нам удалось задействовать все эти эффекты, сохранив при этом кадровую скорость в установленных рамках (не менее 30 кадров в секунду). Кроме того, нужно было учитывать и довольно жесткие ограничения по времени: уже приближался конец 2013 года, а мы намеревались продемонстрировать готовую игру на конференции GDC в Сан-Франциско в 2014 году.

Эффекты

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

На рис. 1 и 2 показаны изображения игры до и после реализации эффектов. Ясно видно, что нам удалось значительно улучшить изображения за счет дополнительных ресурсов ЦП и ГП на устройстве x86.

55927593cfc4c7.48698023.jpg

Рисунок 1. Обычное изображение игры GTR2 на существующих устройствах архитектуры ARM. Великолепные модели, но слабовато проработано освещение

559275ddd1e746.61411391.jpg

Рисунок 2. GTR2 на планшетах с процессором Intel® Atom™ демонстрирует улучшенное изображение, эффекты расфокусировки и лучей света

Лучи света

Для отображения лучей света должным образом солнце отрисовывается на второй цели рендеринга, затем применяется радиальное размытие в направлении, противоположном положению солнца. Эта процедура осуществляется в несколько проходов на цели рендеринга низкого разрешения. Результат получается примерно такой.

559276241823f5.16354373.jpg

Рисунок 3. Первый рендеринг солнца на цели низкого разрешения. Здесь солнце заслоняется непрозрачными объектами сцены, поэтому получается такая форма

55927648e58bd4.42508807.jpg

Рисунок 4. В несколько проходов применяется радиальное размытие, получается изображение, показанное справа. Из первоначального частично заслоненного солнца мы получаем свечение, несколько напоминающее частицы в воздухе, освещенные прямым солнечным светом

5592767e06e281.32240442.jpg

Рисунок 5. Размытое изображение добавляется в исходный кадр, виден готовый эффект. Этот эффект применяется в реальном времени в ходе гонки

Свечение

Свечение — достаточно широко распространенный эффект, но при его применении нетрудно ошибиться. Цель этого эффекта — имитация внезапного яркого света, заполняющего изображение и окружающую сцену.

Свечение выполняется за три этапа.

1. Исходная сцена фильтруется с удалением всех темных пикселей. На сцене остаются только светлые пиксели. Это изображение записывается в другую цель рендеринга (рис. 6).

559276a3401331.93604759.jpg

Рисунок 6. Светлые пиксели извлекаются из исходного изображения

2. Затем новая цель рендеринга, содержащая светлые пиксели, размывается. Это делается для имитации распространения света из ярких пикселей в окружающие их темные пиксели (рис. 7).

559276c36730d8.38726671.jpg

Рисунок 7. Размытие изображения, содержащего светлые пиксели

3. И наконец, цель рендеринга с размытыми светлыми пикселями добавляется в исходную сцену, чтобы создать эффект свечения (рис. 8).

559276e41c9ad6.94892522.jpg

Рисунок 8. Изображение с размытыми светлыми пикселями добавляется в исходную сцену смасштабированием для получения готового засвеченного изображения

Глубина резкости

Для получения эффекта глубины резкости мы начинаем с игровой сцены и применяем гауссово размытие по горизонтали и по вертикали.

559277368760a0.43836558.jpg

Рисунок 9. Исходная сцена игры

Через два прохода все изображение становится размытым (рис. 10). Теперь у нас есть размытое изображение и исходное резкое изображение, а также буфер глубины, оставшийся после исходного прохода рендеринга. На следующем этапе нужно выбрать значение глубины, которое будет являться нашей точкой фокусировки, например центр автомобиля. Для каждого пикселя на экране мы смешиваем размытое изображение и резкое изображение, основываясь на разнице между глубиной текущего пикселя и глубиной точки фокусировки. Пиксели, расположенные на большей глубине, чем точка фокусировки, будут сильнее затронуты размытым изображением, а пиксели, глубина которых близка к точке фокусировки, будут сильнее затронуты резким изображением.

5592775b54d366.72737956.jpg

Рисунок 10. Размытая расфокусированная копия игровой сцены

559277779f86a0.81221370.jpg

Рисунок 11. Глубина резкости на устройстве с Bay Trail. Этот эффект мы оставили для меню и прочих неигровых экранов, поскольку в гонках очень важно точно видеть на расстоянии

Готовый результат (рис. 11) является достаточно точной имитацией изображений с глубиной резкости, какие можно получить с помощью камеры.

Марево

559277b8a554d3.21878560.jpg

Рисунок 12. Эффект марева оставили только для стартовой позиции для придания реалистичного вида нагретому воздуху перед началом гонки

Эффекты марева имитируют мерцание воздуха, поднимающегося от горячих объектов, на солнечном свете (рис. 12). Этот эффект достигается путем применения анимированного искажения к первоначальному цветовому буферу. Чтобы ограничить область этого эффекта местом в непосредственной близости от автомобиля, применяется маскировка с помощью изображения альфа-канала (рис. 13).

559277d28a0d47.00301236.jpg

Рисунок 13. Маска марева, созданная с ракурса камеры

Эффект применяется только на стартовой позиции, поскольку в гонках важно точно видеть на расстоянии.

Приступаем к оптимизации

Разработчики зачастую рассматривают оптимизацию игр как способ снизить количество возвратов. Основная часть работы обычно затрачивается, чтобы оптимизировать игру вплоть до достижения среднего времени рендеринга каждого кадра, равного 33 мс (при этом кадровая скорость составляет 30 кадров в секунду). Дальнейшая оптимизация, как правило, не имеет смысла, поскольку изначально планируется, что кадровая скорость должна составлять именно 30 кадров в секунду. Но на мобильных устройствах это не совсем так. Если бы мы добавляли эффекты, занимающие 12 мс в каждом кадре, то при этом время рендеринга каждого кадра возросло бы до 45 мс (кадровая скорость составит 22 кадра в секунду). Это означает, что придется ускорить каждый кадр уже оптимизированной игры на 12 мс, чтобы добиться нужной кадровой скорости с включенными эффектами.

В начале любого процесса оптимизации необходимо выяснить, от работы каких компонентов оборудования в первую очередь зависит игра (от ЦП или от ГП). Другими словами, нужно определить, работу какого кода следует ускорить (предназначенного для ЦП или для ГП).
С помощью Graphics Performance Analyzers (GPA), программы System Analyzer, мы получили данные для следующей диаграммы.

559278402d17d4.53445968.jpg

Рисунок 14. Использование ГП составляет 90–100 % в течение почти всей гонки, тогда как ЦП загружен всреднем на 25 %. Очевидно, что это приложение в первую очередь зависит от ГП, что вполне разумно для гоночной игры

Получить такую диаграмму очень просто. Добавьте нужные метрики в System Analyzer, затем нажмите кнопку CSV, чтобы сохранить эти метрики в CSV-файле. Затем можно открыть сохраненные данные в Excel или в других программах, поддерживающих создание диаграмм.

Многие разработчики не знают, что пакет GPA прекрасно работает на мобильных устройствах с процессорами x86. Это очень удобный набор инструментов, он по праву заслуживает внимания.

Подробный анализ кадра

С помощью System Analyzer мы записали ряд кадров из игры до добавления эффектов, затем открыли их в Frame Analyzer для обнаружения возможных узких мест. На рис. 15 показан кадр игры до добавления эффекта. Я использовал этот кадр на ранних этапах оптимизации.

5592787bcc7f91.75551319.jpg

Рисунок 15. Кадр разделен на две половины. Во второй половине наблюдаются события, образующие высокую нагрузку на ГП

Первые и самые очевидные — два вызова glClear() во второй половине кадра, на диаграмме они выделены фиолетовым цветом. Я часто наблюдаю эту проблему в игровых «движках»: цели рендеринга полностью очищают, хотя позже они все равно будут полностью перезаписаны. Удаление этих вызовов не составило труда и позволило выиграть около 5 мс, что уже неплохо.

Большая синяя полоса между двумя вызовами glClear() — очень интересное событие. Мы экспериментировали с разными размерами экрана в ранних версиях наборов разработки, полученных компанией Gameloft, и выяснили, что при очень высоком разрешении экрана (2560 х 1900) выгоднее отрисовать изображение на вторичном буфере пониженного разрешения, а затем увеличить разрешение до полного. Рассматриваемое событие — увеличение разрешения изображения: с разрешения вторичного буфера до полного разрешения экрана. Это очень ресурсоемкое событие, его потребовалось изучить подробнее. Я обнаружил, что большую часть времени модули выполнения ГП простаивали, ожидая получения данных от модуля обработки текстур. Это имело смысл, поскольку шейдер фрагментов был очень простым, а размер копируемой текстуры — огромным (свыше 8 МБ), поэтому, естественно, шейдер тратил много времени, дожидаясь данных, необходимых ему для выполнения своей работы. Я решил, что, возможно, имеет смысл сразу отрисовывать изображение с полным разрешением, избавившись от промежуточного этапа увеличения разрешения. В «сухом остатке» производительность почти не повысилась, поскольку все сэкономленное время было потрачено при рендеринге на более крупной цели. Но зато заметно возросло качество изображения.

Последнее, что следует отметить на этом кадре, — 4 крупных фрагмента A, B, C и D. Возможно, вы уже заметили, что я обычно изучаю все ресурсоемкие фрагменты и пытаюсь определить, как устранить их или ускорить их работу. Это наиболее эффективный способ использования Graphics Performance Analyzers. В таких случаях, как с этими четырьмя фрагментами, практически ничего невозможно сделать: здесь в кадре сразу четыре автомобиля. Это ведь гоночная игра, поэтому вполне закономерно, что рендерингу автомобилей уделяется много времени.

Исследование в Platform Analyzer.

​Одним из средств, использованных для анализа производительности, была программа Platform Analyzer — относительно новый инструмент в составе GPA. В Platform Analyzer можно проанализировать нагрузку на ЦП и ГП в целом, а также изучить управление очередями в ГП (рис. 16). Я обнаружил проблему драйвера, из-за которой падала производительность.

559278cf743112.49158769.jpg

Рисунок 16. Анализ в Platform Analyzer. По горизонтальной оси — время, а диаграмма со столбцами сверху показывает глубину очереди ГП

С первого взгляда кажется, что очереди ГП всегда полны и все в порядке. Но при более пристальном рассмотрении отмеченных мест мы заметили, что примерно через каждые 10 кадров возникало событие, которое останавливало весь процесс и очищало очередь, что приводило практически к полной остановке перед последующим возобновлением работы. Некоторое время мы пытались обнаружить периодический вызов рендеринга, который обладал бы какой-нибудь зависимостью, но было непросто понять, что искать.

Оказалось, что это проблема с графическим драйвером Intel. Как это часто бывает с оборудованием, находящимся на этапе предварительного выпуска, работа над драйверами еще не завершена. Эта проблема была известна разработчикам драйвера и даже была исправлена за несколько недель до начала нашей работы, но мы не обновляли драйвер, поскольку были вполне довольны (во всем остальном, кроме этой конкретной неполадки) уже имевшимся у нас драйвером. С точки зрения кадровой скорости фактическое улучшение может быть неочевидным, но, по крайней мере, после исправления драйвера повысилась плавность кадров.

Подробный анализ эффектов

На этом этапе мы ускорили обработку каждого кадра примерно на 5 мс и повысили качество изображения. Но нужно было добиться ускорения еще на 7 мс, поэтому мы решили заняться оптимизацией самих эффектов. При этом мы решили не жертвовать качеством изображения, но поскольку все эффекты были новыми, то, возможно, имело смысл попробовать поработать над ними.

5592790b20d0e7.91336240.jpg

Рисунок 17. Запись Frame Analyzer с добавленными эффектами расфокусирования и световых лучей. Обратите внимание, что больше нет вызовов glClear(), поэтому больше времени тратится на вторую половину кадра, где применяются все эффекты постобработки

При анализе этого кадра (рис. 17) наше внимание привлекли фрагменты В и С (это проходы размытия и освещения для эффекта свечения). Каждый из этих проходов занимал 3–4 мс, что, на наш взгляд, многовато. После анализа разработчики Gameloft внесли существенные изменения в эффект, что позволило значительно повысить производительность.

Во-первых, выяснилось, что этапы размытия применялись для текстуры полноэкранного разрешения. Вместо этого использовали текстуру разрешением в четверть разрешения экрана. В результате размытие стало выполняться настолько быстро, что его уже практически нельзя было разглядеть на диаграмме в Frame Analyzer.

Во-вторых, при создании яркого изображения цель рендеринга имела разрешение Full HD. Разработчики Gameloft обнаружили, что можно вполне безопасно уменьшить ее размер примерно до половины экрана без заметных изменений в качестве изображения. Производительность при этом также возросла.

После оптимизации целей рендеринга расфокусирования мы получили прирост производительности и решили более тщательно рассмотреть сам эффект расфокусирования.
Мы пришли к соглашению, что расфокусирование в целом выглядело бледновато (рис. 18). Убедившись в правильности настройки проходов размытия и яркости, мы решили изучить шейдеры.

Математика в шейдере свечения была излишне сложна, по сравнению с типовым шейдером свечения, как в этом фрагменте.

55927bec4168a8.96235153.jpg

В порядке эксперимента я использовал малоизвестную возможность GPA Frame Analyzer, где можно изменять шейдеры в записанном кадре и перекомпилировать их, чтобы оценить разницу во внешнем виде, производительности и т. п. Мне не потребовалось много времени, чтобы создать шейдер, дававший простой эффект свечения в пределах кадра (в GPA можно изменять исходный код, но нельзя изменять ввод и константы).

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

55927c05e11796.89148217.jpg

Рисунок 18. Слева — эффект свечения с «бледными» тенями и скалами

55927c24aee264.23799231.jpg

Рисунок 19. Новое свечение, которое по сравнению с прежним кажется гораздо удачнее

Выводы

Цель этого проекта состояла в том, чтобы взять игру, уже оптимизированную до 30 кадров в секунду, и дополнительно ее ускорить таким образом, чтобы высвободить около 12 мс для добавления эффектов. Нам удалось ускорить игру приблизительно на 7 мс в каждом кадре, а оставшиеся 5 мс мы получили путем оптимизации эффектов и исправления ошибок в драйвере. Нам удалось показать, что современные мобильные устройства, такие как

Bay Trail, вполне способны просчитывать графические эффекты, доступные ранее только для ГП консолей и настольных ПК. Полученные результаты не удалось бы достичь без GPA и без превосходно налаженного сотрудничества с Gameloft.

О компании Gameloft

Компания Gameloft®, ведущий глобальный поставщик цифровых и социальных игр, входит в число самых передовых разработчиков с 2000 года. Компания Gameloft создает игры для всех цифровых платформ, включая телефоны, смартфоны, планшеты, телеприставки и подключенные к Интернету телевизоры. Компания Gameloft публикует игры собственных франшиз, таких как Asphalt®, Real Football®, Modern Combat and Order & Chaos®, а также работает в партнерстве с крупными правообладателями, включая компании Marvel®, Hasbro®, FOX®, Mattel® и Disney®. Представительства компании Gameloft есть на всех континентах. Игры этой компании продаются более чем в 120 странах. Штат компании составляет 5200 разработчиков.

Дополнительные сведения см. по адресу http://www.gameloft.com

Об авторе

Стив — старший инженер по разработке приложений в корпорации Intel. Он занимается поддержкой разработчиков игр в области трехмерной графики и многопоточной обработки на ПК и мобильных устройствах. На счету Стива 14-летний опыт работы программистом компьютерных игр: он принял участие в создании 11 игр, прошел через два банкротства ивполне доволен своей карьерой. Стив — опытный геймер, он сочиняет и играет музыку, ноне занимается писательством!

 
Intel
разработка
разработчикам
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться