Здравствуйте, меня зовут Калле Хямяляйнен, я старший технический художник работающий над графикой в Oceanhorn 2: Knights of the Lost Realm . В этом сообщении блога я собираюсь пролить свет на то, как нам удалось создать нашу игру. который был разработан для всех поддерживаемых Apple Arcade устройств, от iPhone 6s до последнего MacBook Pro, и перенесен на Nintendo Switch.
Мы ставили перед собой следующие цели:- Поддержать максимально возможный уровень качества.- Обеспечить стабильную частоту кадров.- Добиться собственного разрешения (1080p в режиме стыковки и 720p в портативном режиме).- Использовать суперсэмплированное сглаживание посредством динамического разрешения вместо MSAA (используется в iOS) или временного AA (используется на Mac).- Использовать мобильный рендерер вместо рендерера ПК, поскольку мы хотели отдать приоритет разрешению над функциями рендеринга.Над портом Switch мы работали в сотрудничестве со студией Engine Software. В целом, наш список пожеланий был сложным для оборудования Switch, которое имеет три ядра процессора с относительно низкими тактовыми частотами.
Первая итерацияНаша первая итерация Switch работала только со скоростью 13 кадров в секунду. На iOS наша цель при разработке - 30 кадров в секунду. Когда впервые была анонсирована Apple Arcade, было неясно, какое устройство будет самым старым (в итоге это был iPhone 6s). Ориентация на 30 кадров в секунду позволила нам сохранить высокое разрешение и, самое главное, стабильное время автономной работы. РешенияДля рендеринга одного кадра со скоростью 30 кадров в секунду доступно 33,3 миллисекунды, и наши предварительные результаты, к сожалению, были ближе к 80 м / с на кадр. Мы были озадачены: игра уже была оптимизирована для мобильных устройств. Что мы упустили? Оказывается, довольно много. Современные мобильные устройства Apple имеют более мощный процессор, чем Switch, что позволило нам упустить из виду многие случаи, когда ресурсы использовались неэффективно. Я начал профилировать игру и искать ответы.Разница между игрой на консоли и игрой, запущенной на мобильных устройствах, заключается в том, что на мобильных устройствах производительность зависит от фоновых приложений, времени автономной работы и температуры устройства. На консолях, когда вы получаете стабильную производительность, вы знаете, что можете постоянно на нее рассчитывать.Я начал оптимизацию с поиска медленных Blueprints и перенес их на C ++. За два дня мне удалось сократить первоначальные результаты на 20 м / с. Эти быстрые результаты заставили меня подумать, что есть еще какие-то низко висящие плоды, которые мы еще не собрали. Одно стало очевидным довольно быстро: на некоторых уровнях было более 5000 Актеров - число, которое намного превышает рекомендуемое количество. В то время как устройства iOS могут справиться с этим без особых проблем, Switch не может без существенных изменений.Я посмотрел, сколько из этих актеров тикают в каждом кадре, и их число было более 1000. Вдобавок к этому было также почти 1500 тикающих компонентов. Это была наша проблема. Первое, что нам нужно было сделать, это уменьшить количество тактов на кадр. Вот что мы обнаружили и как сэкономили миллисекунды:Актеры, которые обновляются без особых усилий. Для них мы либо полностью отключили тиканье, либо значительно сократили тиковый интервал.Некоторые актеры запрашивали перекрытия вручную. Их можно было бы отрефакторировать, чтобы вместо этого использовать события Overlap и включить отметку только мгновенно после событий.Актеры, которые делают что-то чисто визуальное, но не видны игроку. Чтобы решить эту проблему, мы использовали усеченную пирамиду, дистанцию, динамическое и статическое отсечение окклюзии, а затем обновили только видимых актеров. Актеры, которые что-то делают, технически заметны, но находятся слишком далеко, чтобы их можно было заметить. Например, в Белом городе в любой момент времени у нас в общей сложности более 300 персонажей, но только десять или около того обычно находятся в пределах досягаемости игрока - это единственные, которые нужно обновить.Unreal Engine предлагает несколько способов оптимизации этих случаев; однако ответственность за принятие разумных решений лежит на команде; некоторые требуют согласия или специального кода. Для этого конкретного порта мы добавили и удалили некоторый код, но также использовали встроенную оптимизацию; например, мы использовали тикрейт анимации.
Еще одно замедление произошло из-за системы ландшафтных трав. Это система, которая динамически создает миллионы ячеек травы и листвы поверх ландшафта. Оказалось, что это использовалось до 2,5 м / с на кадр. Мы заметили, что наш способ использования разных видов листвы для каждого слоя ландшафта порождает много пустых участков. Это можно легко исправить, добавив ранний выход, если компонент имеет нулевой вес для каждого конкретного типа листвы. Система также обновляла все компоненты из ландшафта. Чтобы исправить это, мы сначала посмотрели, каково максимальное расстояние до любого типа листвы, а затем обновили только те компоненты, которые находятся в этом диапазоне. Мы снизили количество компонентов ландшафта с 4000 до 10 (рядом с игроком), в результате чего время рендеринга снизилось до 0,1 м / с.здесь и здесь ( требуется логин ).И последнее , но не в последнюю очередь, Engine Software реализовала технологию , называемую Actor Tick Дозирование, который был использован на море Воров . Пакетная обработка тиков актора сокращает пропуски инструкций в кэше и открывает другие возможности оптимизации, такие как удаление дублированной работы или оптимизация скорости тиков на основе расстояния между актерами.
Все эти усилия способствуют созданию высокооптимизированного порта Oceanhorn 2: Knights of the Lost Realm , который выйдет на Nintendo Switch осенью 2020 года. Спасибо за чтение!
Мы ставили перед собой следующие цели:- Поддержать максимально возможный уровень качества.- Обеспечить стабильную частоту кадров.- Добиться собственного разрешения (1080p в режиме стыковки и 720p в портативном режиме).- Использовать суперсэмплированное сглаживание посредством динамического разрешения вместо MSAA (используется в iOS) или временного AA (используется на Mac).- Использовать мобильный рендерер вместо рендерера ПК, поскольку мы хотели отдать приоритет разрешению над функциями рендеринга.Над портом Switch мы работали в сотрудничестве со студией Engine Software. В целом, наш список пожеланий был сложным для оборудования Switch, которое имеет три ядра процессора с относительно низкими тактовыми частотами.
Первая итерацияНаша первая итерация Switch работала только со скоростью 13 кадров в секунду. На iOS наша цель при разработке - 30 кадров в секунду. Когда впервые была анонсирована Apple Arcade, было неясно, какое устройство будет самым старым (в итоге это был iPhone 6s). Ориентация на 30 кадров в секунду позволила нам сохранить высокое разрешение и, самое главное, стабильное время автономной работы. РешенияДля рендеринга одного кадра со скоростью 30 кадров в секунду доступно 33,3 миллисекунды, и наши предварительные результаты, к сожалению, были ближе к 80 м / с на кадр. Мы были озадачены: игра уже была оптимизирована для мобильных устройств. Что мы упустили? Оказывается, довольно много. Современные мобильные устройства Apple имеют более мощный процессор, чем Switch, что позволило нам упустить из виду многие случаи, когда ресурсы использовались неэффективно. Я начал профилировать игру и искать ответы.Разница между игрой на консоли и игрой, запущенной на мобильных устройствах, заключается в том, что на мобильных устройствах производительность зависит от фоновых приложений, времени автономной работы и температуры устройства. На консолях, когда вы получаете стабильную производительность, вы знаете, что можете постоянно на нее рассчитывать.Я начал оптимизацию с поиска медленных Blueprints и перенес их на C ++. За два дня мне удалось сократить первоначальные результаты на 20 м / с. Эти быстрые результаты заставили меня подумать, что есть еще какие-то низко висящие плоды, которые мы еще не собрали. Одно стало очевидным довольно быстро: на некоторых уровнях было более 5000 Актеров - число, которое намного превышает рекомендуемое количество. В то время как устройства iOS могут справиться с этим без особых проблем, Switch не может без существенных изменений.Я посмотрел, сколько из этих актеров тикают в каждом кадре, и их число было более 1000. Вдобавок к этому было также почти 1500 тикающих компонентов. Это была наша проблема. Первое, что нам нужно было сделать, это уменьшить количество тактов на кадр. Вот что мы обнаружили и как сэкономили миллисекунды:Актеры, которые обновляются без особых усилий. Для них мы либо полностью отключили тиканье, либо значительно сократили тиковый интервал.Некоторые актеры запрашивали перекрытия вручную. Их можно было бы отрефакторировать, чтобы вместо этого использовать события Overlap и включить отметку только мгновенно после событий.Актеры, которые делают что-то чисто визуальное, но не видны игроку. Чтобы решить эту проблему, мы использовали усеченную пирамиду, дистанцию, динамическое и статическое отсечение окклюзии, а затем обновили только видимых актеров. Актеры, которые что-то делают, технически заметны, но находятся слишком далеко, чтобы их можно было заметить. Например, в Белом городе в любой момент времени у нас в общей сложности более 300 персонажей, но только десять или около того обычно находятся в пределах досягаемости игрока - это единственные, которые нужно обновить.Unreal Engine предлагает несколько способов оптимизации этих случаев; однако ответственность за принятие разумных решений лежит на команде; некоторые требуют согласия или специального кода. Для этого конкретного порта мы добавили и удалили некоторый код, но также использовали встроенную оптимизацию; например, мы использовали тикрейт анимации.
Еще одно замедление произошло из-за системы ландшафтных трав. Это система, которая динамически создает миллионы ячеек травы и листвы поверх ландшафта. Оказалось, что это использовалось до 2,5 м / с на кадр. Мы заметили, что наш способ использования разных видов листвы для каждого слоя ландшафта порождает много пустых участков. Это можно легко исправить, добавив ранний выход, если компонент имеет нулевой вес для каждого конкретного типа листвы. Система также обновляла все компоненты из ландшафта. Чтобы исправить это, мы сначала посмотрели, каково максимальное расстояние до любого типа листвы, а затем обновили только те компоненты, которые находятся в этом диапазоне. Мы снизили количество компонентов ландшафта с 4000 до 10 (рядом с игроком), в результате чего время рендеринга снизилось до 0,1 м / с.здесь и здесь ( требуется логин ).И последнее , но не в последнюю очередь, Engine Software реализовала технологию , называемую Actor Tick Дозирование, который был использован на море Воров . Пакетная обработка тиков актора сокращает пропуски инструкций в кэше и открывает другие возможности оптимизации, такие как удаление дублированной работы или оптимизация скорости тиков на основе расстояния между актерами.
Все эти усилия способствуют созданию высокооптимизированного порта Oceanhorn 2: Knights of the Lost Realm , который выйдет на Nintendo Switch осенью 2020 года. Спасибо за чтение!
Комментарии
Отправить комментарий