Gamedesign — Оптимизация рендеринга в Unity


Содержание

Возможности Unity для рендеринга в реальном времени

В январе появились новости, что в скором времени выйдет интерактивная история от первого лица, демонстрирующая возможности движка Unity версии 2020 года. Хотя «игра» пока не доступна, сейчас можно взглянуть на новое видео, представляющее, чего могут добиваться разработчики игр и художники.

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

По теме

Facebook планировала купить разработчиков движка Unity

Симулятор марсианской базы Project Eagle вышел в Steam

34 Комментария

Интересно, на каком железе все это рендерилось, хоть бы оставили пометку какую-нибудь, чтобы поплакать можно было.

@Jaycee, думаю что i7 содной 1080. Мне кажется тут дело в какой-то оптимизации рендера в не в железе

@Alexqa, да сцена просто мультяшная, нет SSS, текстуры не очень высокого качества. не думаю, что тут нежно топовое железо. Unreal такое могёт.

@Jaycee, Посмотрите обзоры FirePro w9100 и ей подобных видеокарт созданных специально для данных целей.

@GROOVY, да, у компании интересная разработка, в области анимации лиц. но я так понимаю, что она не процедурная, а сделана индивидуально под каждого персонажа. так что, такого качества в массах, ждать еще и ждать(

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

Unity как был позади, так и сейчас он там же. Всё таки тот же Unreal Engine в разы лучше во всех задачах и даже то, что здесь представлено, а именно рендеринг в реальном времени, уже давно демонстрировалось в UE4 и всё это выглядело на голову лучше.

@evekin, К сожалению в UE4 нет рендера в реальном времени и там приходится каждый раз компилировать сцену и только потом запускать. В том же Unity вы все изменения видите в реальном времени и там компиляция проекта происходит только после упаковки проекта в клиент игры

Консоли не потянут — массовым не станет, все закономерно, так что можете даже не мечтать о таком графоне до выхода пс5, хотя скорее уж до пс6

@evekin, нет таких вещей, которые можно сделать на UE4 и нельзя на Unity. Просто Unreal считается более «профессиональным» из-за своей долгой истории и огромным списком AAA проектов, а Unity облюбовали инди разработчики.

@GROOVY, там ue3
@Lutte, нет, они созданы для других целях, fire и quadro созданы для вычислений на гпу, тут простой рендеринг
@MedievalRain, в теории с покупкой сорсов нет, на практике есть, юнити как был отсталым от остальных движков так и остается, а продемонстрированный трейлер показываеь что подобное легко умел ue на старте еще, 4 года назад. уже про разработку крупных проектов

@Alex174s, причем тут UE3? Там компания, чью технологию использовали одна и таже.

@Alex174s, ну скажи какую технологию Unity не поддерживает?

@Triffid, Впечатляет демка. Жаль игр таких толком нет

@evekin, да нет. Там обычные компы. В крайнем случае titan x на gpu. Я не знаю про какое «узкоспециализированное» железо ты говоришь. буду рад ссылки на пример такого железа

@Cohen, да и не думаю, что будет, пока это все не выйдет на процедурно-генерируемый уровень. у них в послужном списке есть игры, но опять же, что бы делать прям тааак круто, да на движке, при данном развитии, это нужно слишком много тратить человеко-часов, лишь на одного персонажа. но в Injustice 2, лицевая анимация неплохая, вроде, в CGI трейлерах конечно.

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

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

@MedievalRain, Я тоже так думал, как и вы. Но потом потусовался немного на юнити-форумах и пришёл к выводу, что в жизни всё не так радужно как в зазывалке на cайте Unity.
Короче, на сегодняшний день унреал однозначно лучше для разрабов. А игры не нём, сделанные пряморукими программерами, например такими каr DE (Warframe), не греют видеокарту вообще даже с включённым наилучшим сглаживанием.

@MedievalRain, а ты скачай и посмотри, и увидишь буквально во многих аспектах анрил проработанней и обширнее чем юнити. Будь-то это возможности api движка, или редактора. Или работа со звуком или с графикой. Ну вот для примера тебе в юнити нет нормальных моделей освещения для волос и ткани, и то что показано в видео, займет куда больше времени на реализацию чем в ue

И то и то в Unity уже есть как несколько лет из коробки. Не нужно говорить о том, в чем ты не разбираешься. А по тебе видно, что ты даже понятия не имеешь, что пишешь.

сама сцена дико тормозит в редакторе, это было видно по тем 2-3 сек, некомфортно работать когда задрано так много

Автор в комментариях под видео отметил, что это проблемы записывающего софта. Более того, Unity отлично в редакторе показывает более тяжелые сцены без тормозов. Эта демка не сильно впечатляющая, чтобы редактор на ней томрозил. Даже на Adam он работает нормально, а там очень много объектов.

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

Потому что демка показывает работу со светом. Нужны не статические сцены — смотри Book of the Dead — там куча динамики в риалтайме. (https://www.youtube.com/watch?v=DDsRfbfnC_A)

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

Что показывает Unity из того, что UE4 умел 4 года назад? Почти по всем технологиям они идут лоб в лоб. Кончай заниматься демагогией, диванный эксперт, либо указывай конкретные технологии. Unity это второй движок после UE4 для разработки игр.

Unity как был позади, так и сейчас он там же. Всё таки тот же Unreal Engine в разы лучше во всех задачах и даже то, что здесь представлено, а именно рендеринг в реальном времени, уже давно демонстрировалось в UE4 и всё это выглядело на голову лучше

Интересные истории. Работал с и тем, и тем движком? Я вот работал. Unity лучший движок для создания не AAA-игр, потому что на нем намного проще писать эффективный код, в нем быстрый процесс итераций (как сказали выше, на Unity что-то поменял и все перезагрузилось мгновенно, а на UE4 надо компилировать от нескольких секунд до часов, если проект большой и вы не на одних блюпринтах его делаете), очень простой и мощный редактор, намного ниже системные требования как для разработчика, так и для игр (да-да, не удивляйтесь, нормальные игры на Unity заметно меньше требуют, чем нормальные игры на UE4), удобнее и мощнее разработка под мобильные устройства и на выходе билды весят намного меньше.

Я, конечно, понимаю, что аудитория здешняя привыкла судить по ужасным инди-хоррорам поры Unity 4 из 2013 года, но сейчас уже 2020. На Unity сделали очень много игр, за которые не стыдно — Subnautica, которая в оптимизации прыгнула в 3 раза за год, и это еще они не используют будущие технологии от Unity, которые ооочень сильно поднимут производительность. The Long Dark, Pillars of Eternity, Tyrany, Cuphead, Hollow Knight, Inside, Firewatch, Ori and the Blind Forest (учитывая сколько там всего на экране происходит, и как она на моем не самом топовом ПК на максималках работала идеально, почти не нагружая систему, низкий поклон), Layers of Fear, Furi, Tabletop Simulator, VRChat даже (как феномен и идея он очень крут).

И напомните мне, сколько ужасных по качеству игр вышло на UE4, когда на нем получили возможность клепать инди-хорроры все подряд? Да дохера. Куча всяких тормозящих шутеров и прочего. Напомнить про Hello Neighbour?

Прежде чем сидеть и поливать какой-то движок помоями, надо разобраться, не заблуждаетесь ли вы и актуальна ли ваша информация. У Unity есть проблемы, как есть и у UE4 (у него их меньше, но некоторые никогда не исправить, потому что это решения архитектурного фундамента, как например очень долгая компиляция C++). Оба движка совершенствуются и в данный момент Unity только выходит на рынок AAA-разработки. Это идеальное решение для любой инди-студии, особенно для 2D игр и не топовых графонистых AAA-проектов. И судя по новым решениям, скоро движок составит хорошую конкуренцию UE4 на поприще AAA. А вот Unreal уже вряд ли составит конкуренцию Unity в 2D разработке и мобилках.

А по поводу демок — все демки на UE4 такие же статичные. Можно поглядеть даже на то, как некоторые почти одинаковые сцены выглядят и там и там и с каким ФПС — not-lonely.com/blog/making-of/unity-vs-ue-pt-3/.

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

Как оптимизировать рендер ue4? Мучения unity-нуба.

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

к записи приложил видео из unity, тут 300-400 фпс, запечен свет, фейкануты спекуларные отражения. совершенно аналогичная же сцена на ue4 выдает 30-40 фпс. если я верно понимаю методику, то если у unity надо что-то добавлять для нормального рендера, то у ue4 сразу все включено чуть ли не на максимуме, deffered рендер, много графических фич, которые в него входят.

суть проблемы — не могу найти толковых туторов и советов по оптимизации настроек. вроде бы находил что-то внятное и предметное, без рассусоливания в духе «надо снизить количество вертексов», но начинаю пробовать и совершенно непонятные результаты. пустая скомпиленная сцена выдает 120 фпс. как только добавляется static освещение без теней — сразу съедается 20 фпс. пробовал на версиях 4.18 и 4.20, 4 ядерник и 1070.

если я правильно понимаю, то по умолчанию включены качественные затенения, отражения и прочее, что не всегда требуется, может что-то еще, чего я не знаю. кто сталкивался, подскажите, как этим процессом можно руководить нормально, а не просто дергая ползунок качества? (с которым тоже весело, разница между cinematic и low — 10-15 фпс). статы, если нужно, выложу позже, но вдруг есть какой-то набор обязательных фич для ускорения при работе с движком?

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

п.п.п.с. без холиваров, плз. не надо разводить unity vs ue4.

Никак. Анрил не предназначен для высокого перфа.

Battle Angel Alita
досадно, спасибо за ответ

CTPEJIOK22
> досадно, спасибо за ответ
Лол, ты сразу повёлся на глупый вброс без аргументов?

Всё в UE нормально и даже местами лучше чем Unity


Любая проблема решается с выявлением bottleneck’a и её локализации, а уж потом подкручивание и изменение контента.
В последней твоей ссылки вполне достаточно показаны тулзы, с помощью которых можно определить что выжирает больше времени и его уже размусоливать

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

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

вопрос решился задать, когда, после двух дней мучений, создал совершенно пустую сцену в ue4 и она выдала 120 фпс (кап, само собой), но стоило добавить 1 омни даже без теней — и у меня сразу на 10-20 фпс все просело до 90-110. как так и почему — не понятно.

изначально мой вопрос куда обширнее — как переехать с одного движка на другой и какие особенности выявлены, потому как по unity такой инфы много, а по ue4 постоянно натыкаюсь на одно и то же разными словами, а у меня опыта в этом мало и большинство ответов «запусти stat и смотри что тормозит», в примерах аналогично — «вот я сделал сцену, видите, тут прозрачности, они тормозят, уберем прозрачности — и не будут тормозить» или же «используйте меньше event tick в блупринтах». я вот в восторге был от оптимизации по первой ссылке, где провернули переход на мобильный рендер, что схоже на render pipelines в unity, чтобы получить стабильные 60 фпс. хотелось почитать про что-то подобное, обсудить, наверняка же люди уже давно вникли в нужные моменты, логику движка понимают, типа «100 фпс можно получить совершая такие-то действия, отключая то, то и то», может какие-то темплейты есть, не знаю.

а пока что выходит, что действительно проще ни у кого ничего не спрашивать, а сидеть и копаться в статах.

в любом случае, спасибо, буду пробовать усерднее.

никто кроме эпиков не знает как ue заставить нормально работать, что собственно по доступным на рынке продуктам и видно. так что открывай https://docs.unrealengine.com/en-us/Engine/Performance и до потери пульса :)

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

1) r.maxfps 1000
2) r.ScreenPercentage 100
3) r.SetRes 1920×1080

выдает 300-350 фпс, отлично. сейчас пробую пошагово добавлять все то, что было в прошлом тесте и очень интересно отключить все, что не нужно — ао, dof, sslr, итд, и ничего не сломать.
тестирую не чистый билд, а standalone game, pie тупит. и очень радует, что билд на телефоны дает 650-700 фпс.

с этим уже можно работать и что-то пробовать, не так грустно, как прошлая сборка и 30-40 фпс непонятно почему.

upd: запеченый свет еще прибавил 100 фпс, теперь в районе 450 показывает на стандартной сцене. совсем другое дело. прям стало интересно докопаться, что и почему в старой сцене тупит.

CTPEJIOK22
На сколько я помню по моему небольшому опыту — самое тормозное в анриле это реалтайм генерация SDF. А её очень просто по случайности включить, тыкнешь какой-нибудь сцен-колижен для гпу частиц и всё, фпс в жопе.

Battle Angel Alita
попробовал — и действительно. если на сцену добавить немного частиц, огонь тот же, то резко фпс падает до 60. убираю — 300.
sdf в данном контексте — это что именно? и есть ли возможность отключить?

Battle Angel Alita
благодарю

получилось в тестовой сцене отключить часть лишнего и поднять со 100 фпс до 250 и с нормальным качеством картинки. с полным запеканием света и рефлекшн пробами выходит и 350 фпс с норманым качеством картинки.

r.SSR 0
r.HZBOcclusion 0
r.SSR.quality 0
r.AmbientOcclusionLevels 0
r.PostProcessAAQuality 3

так же может помочь.

FireFenix
> вопрос решился задать, когда, после двух дней мучений, создал совершенно пустую
> сцену в ue4 и она выдала 120 фпс

это стандартный лок синхронизации (разлочить t.MaxFPS 500 \ 100500)

CTPEJIOK22
> но стоило добавить 1 омни даже без теней — и у меня сразу на 10-20 фпс все
> просело до 90-110. как так и почему — не понятно.

каналы лайта использованы? материалы инстансированы?

CTPEJIOK22
> изначально мой вопрос куда обширнее — как переехать с одного движка на другой и
> какие особенности выявлены, потому как по unity такой инфы много, а по ue4
> постоянно натыкаюсь на одно и то же разными словами

да берешь и переезжаешь. инфы полно. некоторые базовые вещи неплохо бы знать самому, как работают: ПБР, отложенное\прямое освещение, планарные отражения, постпроцесс и партикл эммитеры. потом в документации смотреть особенности реализации в Анриле.
рецепта «как получить 100 фпс» не существует. Все определяется видом окружения (индор\аутдор), насыщеностью локации, проработкой деталей и. сложностью освещение конечно же.

CTPEJIOK22
> выдает 300-350 фпс, отлично

не на это нужно смотреть. нам важно количество миллисекунд потраченное на построение кадра, т.к. количество FPS count не отследить, а потребляемые миллисекунды в статах — вполне реально.

CTPEJIOK22
> интересно отключить все, что не нужно — ао, dof, sslr, итд, и ничего не
> сломать.

сломать таким макаром можно только освещение. кстати, картинка в #10 это и демонстрирует.
лучше не отключить, а правильно настроить. gtx 1070 вполне переваривает эти эффекты.

CTPEJIOK22
> запеченый свет еще прибавил 100 фпс, теперь в районе 450 показывает на
> стандартной сцене. совсем другое дело. прям стало интересно докопаться, что и
> почему в старой сцене тупит.

наверное потому, что Анрил по сути заточен на статическое\комбинированное освещение с помощью Лайтмасс. Специально для минимизации переключений текстур в версию 4.21 Эпики собираются вшить виртуальное текстурирование (привет играм Rage и новым Return to Castle Wolfenstein). Совпадение? Не думаю. Главное что бы стриммер не запороли. Это не значит, что нельзя фулл динамик лайтинг — просто качество будет такое себе и вторичные отскоки света от ИС нас явно не порадуют.
Пока что всякие DFAO, DFGI и VXGI — мало того что очень требовательны, так еще и не блещут качеством.

Анрил очень хорошо оптимизируется, но надо разбираться и копать, в чем проблема. Большие возможности создают массу точек где можно ошибиться. Грубо говоря, неправильно настроенные cascade shadows на directional light могут просто уничтожить твой fps.
Используй cpu / gpu профайлер, также проводи тесты с консольными командами типа stat SceneRendering и stat LightRendering
Весь тред не читал, но сложилось впечатление, что действуешь вслепую, отключая всё подряд. Если заюзаешь профайлер, то поймёшь, на что конкретно уходят твои миллисекунды :)

Если Эпикам не удалось заставить работать своё творение быстро, как это удасться обычному пользователю?
Современные движки это такие конструкторы, там куча техник и надо подобрать комбинацию, при которой и выглядит приятно и тормозит не сильно.

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

>каналы лайта использованы? материалы инстансированы?

про каналы лайта не скажу, даже не знаю что это, но там обычная сцена без всего, просто bsp и omni — падал фпс, какое-то странное поведение. поставил новую версию движка, вроде такой аномалии уже нет.

>рецепта «как получить 100 фпс» не существует

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

>потребляемые миллисекунды в статах — вполне реально.

понял, спс. разбираюсь потихоньку с профайлером, сперва хватило для вдохновения просто увидеть в районе 700 фпс на простой сцене, секунды дальше буду разбирать.

>сломать таким макаром можно только освещение. кстати, картинка в #10 это и демонстрирует.

тут не совсем понял. в #10 на первой свет по максимуму убрал, на второй же свет запечен и там вроде все нормально выглядит.

>Это не значит, что нельзя фулл динамик лайтинг — просто качество будет такое себе и вторичные отскоки света от ИС нас явно не порадуют.

пока что наблюдал — мало где в серьезных играх есть полностью динамический свет. а где есть, взять тот же black ops 4 с их интересной системой, там оперативку и видеопамять есть немерено. собственно, начитавшись диздоков от создателей калды и захотелось сильнее вникнуть в скорость работы, у них это ключевой момент.

>Грубо говоря, неправильно настроенные cascade shadows на directional light могут просто уничтожить твой fps.

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

Что нового в Unity 2020.2

Релиз Unity 2020.2 состоялся!

В обновлении Unity 2020.2 более 1000 разработчиков Unity.Technologies подготовили порядка 170 новых функций и улучшений для художников, дизайнеров и программистов. Были обновлены такие инструменты, как ProBuilder, Shader Graph, 2D Animation tools, Burst Compiler, UI Elements и многое другое.

Больше фич, инструменты и процессы лучше

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

ProBuilder 4.0 теперь поставляется с версией 2020.2 и является уникальным гибридом инструментов трехмерного моделирования и проектирования уровней, оптимизированных для построения простой геометрии, но способных к детальному редактированию и созданию UV-разверток при необходимости.


Polybrush теперь доступен через менеджер пакетов. Этот универсальный инструмент позволяет создавать сложные фигуры из любой 3D-модели, размещать детализированные сетки, рисовать при произвольном освещении и цвете, а также смешивать текстуры на сетке непосредственно в редакторе.

DSPGraph — это новая система рендеринга / микширования звука, построенная на основе Unity C# Job System. Предварительная версия этого пакета, теперь доступна в менеджере для свободной загрузки.

Также был обновлен фреймворк UI Elements для улучшения отображения UI инструментов, использующие в своей основе графы, таких как Shader Graph, Visual Effect Graph и Visual Scripting Graph. Эти изменения обеспечивают гораздо более плавное и отзывчивое поведение интерфейса при разработки более сложных графов в редакторе.

Чтобы помочь вам лучше организовать сложные графы, мы добавили в Visual Effect Graph подграфы. Вы можете обмениваться, комбинировать и повторно использовать их для блоков и операторов, а также встраивать полноценный VFX в VFX. Мы также улучшили интеграцию между Visual Effect Graph и High-Definition Render Pipeline (HDRP), который по умолчанию включает в себя граф VFX, предоставляя вам дополнительные функции рендеринга.

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

Мы добавили возможность использования заменяемого спрайта в инструмент 2D-анимации. С помощью этой новой функции вы можете изменять отображаемые спрайты GameObject’а, одновременно используя ту же скелетную основу и анимационные клипы. Это позволяет быстро создавать несколько различных персонажей с использованием разных библиотек спрайтов или настраивать их части с помощью механизма разрешения спрайтов (Sprite Resolvers).

Инструменты для программирования

Burst Compiler вышел из предварительного просмотра в 2020.1. В этом выпуске Burst Compiler 1.1 включает в себя несколько улучшений JIT runtime-компиляции и некоторые улучшения C#.

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

Для разработчиков мобильных приложений мы ввели управление яркостью экрана с помощью нового свойства Screen.brightness (iOS и Andro >API ReplayKit (iOS). Мы также упростили настройку вашего пользовательского интерфейса, добавив поддержку для определения ограничивающего прямоугольника вокруг вырезов.

Мы перенесли Библиотеку PhysX Cloth из предыдущей PxCloth в NvCloth в рамках нашего перехода с PhysX 3.4 на PhysX 4.x.

Мы начали переносить интеграцию с редакторами кода (и, следовательно, >Visual Studio Code и JetBrains R >Visual Studio будет доступна в виде пакета позже.

Мы удалили поддержку старой среду исполнения кода .NET 3.5. Любые проекты, использующие ее, будут автоматически обновлены для новой версии .NET 4.x.

Инкрементальная сборка мусора, выпущенная как экспериментальная на некоторых платформах в Unity 2020.1, теперь поддерживает все платформы, кроме WebGL.

Этот выпуск также включает поддержку усилителя Intel® VTune ™ для автономного проигрывателя Windows (x86, 64-разрядная версия) и редактора Windows, включая выборочное профилирование кода C#.

Графика

В обновлении Unity 2020.2 High-Definition Render Pipeline (HDRP) включает API для произвольных форматов результирующих переменных (AOV), позволяющий получать только определенные свойства материала, или только данные об освещении, буфер глубины или других проходов рендера сцены. Кроме того, этот API теперь используется в Unity Recorder, что упрощает экспорт определенных данных для рендеринга с HDRP.

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

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

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

Цукерберг рекомендует:  Быстрая разработка кроссплатформенных игр и приложений

В Light-Weight Render Pipeline (LWRP) появились новые 2D-функции, такие как экспериментальный 2D-рендер, который теперь содержит опции 2D Pixel Perfect (Пиксельное отображение без сглаживания границ) и 2D Lights. Новые 2D-источники света позволяют легко улучшать визуальные элементы 2D-проектов напрямую, без использования 3D-источников света или пользовательских шейдеров.

Shader Graph теперь имеет 2D Master узлы для создания 2D Unlit и 2D Lit Sprite шейдеров. Кроме того, точные режимы позволяют настроить узлы на использование меньшего объема памяти графического процессора, что помогает повысить производительность на различных платформах, включая мобильные.

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

С помощью Probe-Lit GI Contributors вы можете выбирать, должны ли объекты, которые способствуют глобальному освещению, получать глобальное освещение от световых зон или световых карт. Это позволяет моделям, размещенных на сцене, вносить свой вклад в расчеты отраженного освещения, не занимая тексели на карте освещения, что может привести к значительному улучшению времени запекания и уменьшению использования памяти.

NV >NVIDIA Turing. Поддерживается в графическом процессоре Lightmapper.

Карты освещения теперь поддерживают библиотеку Intel Open Image Denoise, которая является фильтром на основе машинного обучения. Это улучшит ваш рабочий процесс создания карт освещения и их качество за счет пост-обработки. Шум и нежелательные артефакты удаляются, так что вы можете получить более гладкие и без шумные карты освещения.

Платформы и Редактор Unity 3D

Оптимизированное кадрирование кадров для Andro >Google Android Gaming and Graphics, обеспечивает постоянную частоту кадров и, следовательно, более плавный игровой процесс, позволяя распределять кадры с меньшей дисперсией.

Разработчики мобильных приложений также получат некоторые преимущества от улучшенной поддержки OpenGL, так как мы добавили поддержку многопоточности в OpenGL (iOS), чтобы повысить производительность на старых версиях устройств iOS, которые не поддерживают технологию Metal. Мы также добавили поддержку OpenGL для SRP-батчинга для iOS и Android, чтобы повысить производительность процессора в проектах, использующих упрощенный конвейер рендеринга (LWRP).

Мы добавили проверку размера APK с помощью Android App Bundle, чтобы вы могли видеть окончательный размер APK для различных конфигураций для больших приложений.

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

Поддержка Vuforia перенесена из настроек проигрывателя в диспетчер пакетов, что дает вам доступ к последней версии Vuforia Engine 8.3.

Исправление багов, улучшения и обновление API

Мы продолжаем делать редактор более компактным и модульным, преобразовывая несколько существующих функций в отдельные пакеты, включая Unity UI, 2D Sprite Editor и 2D Tilemap Editor. Они могут быть легко интегрированы, обновлены или удалены с помощью диспетчера пакетов.

Как и во всех обновлениях, Unity 2020.2 включает в себя большое количество улучшений и исправлений ошибок. Особая благодарность нашему альфа- и бета-сообществу за использование и тестирование всех новых инструментов и возможностей. Ваши уместные и своевременные отзывы помогли нам решить большое количество проблем и доработать это обновление.

Вы можете найти полный список функций, улучшений и исправлений в примечаниях к обновлению, которые доступны здесь. Вы также можете использовать систему баг-трекинга, чтобы найти конкретную информацию о задачах и багах в Unity 3D.

Что готовит следующее обновление?

Вам интересно, что будет в Unity 2020.3? Вы можете получить доступ к альфа-версии прямо сейчас или дождаться бета-версии, которую мы планируем запустить позже этим летом. Полный выпуск Unity 2020.3 запланирован на осень 2020 года. Если вам интересно узнать больше о наших пакетах предварительного просмотра, ознакомьтесь с обзором здесь.

Вы не только получите ранний доступ к последним новым функциям, но и сможете убедиться, что ваш проект будет совместим с новой версией. Вы также можете помочь повлиять на будущее Unity, поделившись своими отзывами с нашими командами по исследованиям и разработкам на наших форумах или лично.

Gamedesign — Оптимизация рендеринга в Unity

Лоды (LOD — Level of Detail) уровень детализации сетки(Mesh). самый детальный уровень вблизи наблюдателя и самый не детализированный на максимально возможном расстоянии от наблюдателя.

Проверка Фрустума камеры. Камера видит усеченную пирамиду то что в ходит в нее рисуется что за пределами пирамиды не рисуется. Проверяют обычно: точки центры объектов, сферы описывающие объем объектов или их коробки на предмет попадания в пирамиду видимости .

Восьмеричное дерево. Октрии(Octree). Все пространство делиться тремя ортогональными(взаимно перпендикулярными) плоскостями. Полученные в результате объемы вновь делятся и так далее. В результата каждый уровень окто-дерева содержит 8-мь узлов. В которых так же могут находиться под-узлы и так далее.
Затем для оптимизации скорости прорисовки проверяют с верху(корень дерева) если узел виден во фрустуме камеры рисуют объекты которые находятся в нем и проверяют остальные под узлы данного узла. Однако, если узел не виден во фрустуме камеры его не рисуют, отбрасывают и дочерние узлы не проверяют.

Инстансинг – прорисовка большого кол-ва однотипных объектов. За минимальное кол-во вызовов ф-й граф. АПИ и с минимальной нагрузкой на ЦПУ. Поскольку все необходимые данные предоставляются видео карте. Обычно это связка двух вершинных буферов и шейдерной программы, в первом буфере может находиться модель которую нужно нарисовать, а в другом позиция/размер/ориентация, т.е то как надо отрисовать очередного из многих.

Забыл как эта технология называется, но суть в том что бы рендерить очень редко модель в текстуру, а эту текстуру использовать как удаленный объект. Такая текстура накладывается на два треугольника(прямоугольник), последний может ориентироваться на наблюдателя.

Occlusion Queries. Проверка прошли ли обработку какие-нибудь семплы рисуемого объекта. Как правило делает либо в отдельным пассом(шагом) с самыим простыми шейдерами и без записи в цветовой буфер, можно проверить была ли запись в буфер глубины, если да то объект виден. Значит нужно рисовать более качественное его представление. Так же Occlusion Queries может быть иерархическим некая аналогия с окто деревом. Если дом не виден, зачем нам проверять на предмет видимости его содержимое? Occlusion Queries можно кидать на проверку в текущем кадре с нормальной прорисовкой объектов а использоваться лишь на следующем.
.

Gamedesign — Оптимизация рендеринга в Unity

400 DC, 70-80 FPS

850 DC 35-40 FPS

1,3K DC 20-25 FPS
Расширения для Unity3D
Блог программиста — PoqXert.ru

NEBR Дата: Понедельник, 21 Октября 2013, 10:31 | Сообщение # 7
PoqXert, дело говорит. Используй динамический батчинг, его суть в том что два объекта с одинаковым материалом отрисуются как один. В твоем случае 60 к кубов отрисуются как один куб. Ну и, может есть смысл в том чтобы куб сделать самому в 3d редакторе, таким, каким он и должен быть — из 6 полигонов.

Добавлено (21.10.2013, 10:31)
———————————————
Не обратил внимания, оказывается динамический батчинг уже используется. Заостри внимание на материалах. Чтобы на одном кубе был один материал
King Size #Gamiron12


Ranger Дата: Понедельник, 21 Октября 2013, 11:27 | Сообщение # 8
Мне вот интересно, если грохнуть один куб, то кубы сверху «пойдут» вниз, или будут «держаться» за соседей сбоку?
Barbatos Дата: Понедельник, 21 Октября 2013, 11:31 | Сообщение # 9
Ranger,
Это зависит от настрое физики, должны упасть если на них висит rigidbody или как-то так.
Его остатки и на хлеб не намазать. Мой тебе совет Пабло — относись к жизни как к веселухе, но непродолжительной. @Эш
Ranger Дата: Понедельник, 21 Октября 2013, 11:35 | Сообщение # 10

Да про rigidbody понятно.
Просто при его использовании «в лоб». В здании нельзя будет «насверлить» дырок оружием и оно будет рушиться ненатурально(слоями).
Сам думал об этом, поэтому Автора и спросил.
Bizzy Дата: Понедельник, 21 Октября 2013, 12:32 | Сообщение # 11
Отключи тени и если про версия то юзай «occlusion culling». Также если будет много текстур, сделай атласс.
robertono Дата: Понедельник, 21 Октября 2013, 16:31 | Сообщение # 12
Спасибо огромное за ответы конечно.. но всё же
Моя проблема в том что я не сказал что кубы можно будет ломать

Нету смысла создавать куб без всех 6 полигонов, т.к. этот куб можно будет сломать , и если полигонов не будет то это будет уже не куб..

Да, потому что там наверняка это делается совсем по другому. Я могу выложить префаб в котором будет все 6 зданий и вы сами всё у себя попробуете.

Это куб созданный в юнити. GameObject — Create — Cube

На каждом кубе один и тот же difuse материал который ставится когда создаёшь куб в юнити.

Я про физику ничего не говорил

+5 фпс только. Того 14.

Дело не в том, есть ли тени, какие материалы, есть ли оклюжн кулинг, сколько полигонов на кубе юнити.
В этой кубической игре отсутствуют чанки. В этой игре куб, это отдельно созданный gameobject cube без материала. Каждый куб.
Возможно мне нужно просто посмотреть MinePackage.
Я в первом сообщении не просто так упомянул

.
Просто в других играх это делается совсем по другому как я понял.

Вы видите характеристики моего компьютера? Выигрыш 5 фпс от теней, от полигонов безсмыссленый , так как игра сильно тормозит на видео карте Geforce GTX 770 !

Добавлено (21.10.2013, 16:19)
———————————————
Вот вам префаб одного здания, врубите юнити, поставьте first person controller, поставьте здание на сцену 6 раз (у меня стоит 6 зданий) и посмотрите сколько фпс будет у вас. Не думаю что больше 2.

Добавлено (21.10.2013, 16:29)
———————————————
Открыл я значит MinePackage, текстуры у меня грузится не хотели , но я включил максимальное сглаживание (x8), fantastic, врубил тени.

Добавлено (21.10.2013, 16:31)
———————————————
Но там не ломаются блоки почему то.

KamiRonin Дата: Понедельник, 21 Октября 2013, 22:23 | Сообщение # 13
насколько смог разобраться, в MinePackage используется вычисление лицевых сторон, батч процессор, который рассовывает все вычисления по отдельным потокам, и декоратор, который накладывает текстуру на видимый полигон используя признаки «пиксола» (тоже в отдельном потоке).
там вообще нет кубов!
мир хранится в координатах и признаках (позиция, текстура, UV развертка). каждый chunk хранит в себе и меш, и меш рендер, и меш фильтр, но они включаются только для видимых блоков, наверное только в зоне досягаемости рейкаста плейера.
грубо говоря — после декорирования это просто литой «пиксольный» (вортексный) объект, который просто выглядит как куча блоков.
когда ломаешь «пиксол» — то декоратор вычисляет новое видимое поле, только для сопряженных с измененным chunk’ом и все. мы снова имеем единый вортексный объект.
если сделаешь в 3D max такой «террайн» слитый с деревьями, удалив все скрытые полигоны, и запекши текстуры — то он вот так и будет работать в unity. у меня 68 fps / 1M вертексов / 513K триугольников в FullHD на весь мир.
Мыслю — значит программирую.
Конструктивная критика — умных ведет к совершенству.
Великие умы обсуждают идеи, средние — обсуждают поступки, а малые — людей.

Рисунок 20. Уровень детализации 2. Это последний уровень детализации, здесь используются наименее сложные модели

Переключаясь между разными уровнями детализации, я измерял кадровую скорость для сравнения (таблица 7).

Таблица 7. Сравнение кадровой скорости при разных уровнях детализации

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

Пакетная обработка

Избыточное количество вызовов рендеринга может привести к чрезмерной нагрузке на ЦП и снижению производительности. Чем больше на экране объектов, тем больше вызовов рендеринга нужно сделать. В Unity поддерживается так называемая пакетная обработка, позволяющая поместить несколько игровых объектов в один вызов рендеринга. Статическая пакетная обработка предназначена для статических объектов, а динамическая — для движущихся объектов. Динамическая пакетная обработка выполняется автоматически при выполнении всех требований (см. документацию по пакетной обработке), а статическую пакетную обработку требуется задавать вручную.

Существуют определенные требования для совместного рендеринга объектов и для динамической, и для статической пакетной обработки. Все эти требования перечислены в документе по пакетной обработке, ссылка на который приведена в разделе справочных материалов.

Для тестирования прироста производительности при статической пакетной обработке я создал сцену со сложными игровыми объектами в виде самолетов (рис. 21) и измерил кадровую скорость с пакетной обработкой и без нее (таблица 8).

Рисунок 21. Статическая пакетная обработка тестовой сцены с очень сложными моделями самолета

Таблица 8. Разница в кадровой скорости и количестве вызовов рендеринга при включенной и отключенной статической пакетной обработке (рис. 21)

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

Заключение

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

Справочные материалы

Документация по параметрам качества:

Об авторе

Джон Весоловски, стажер

Задачей группы, в которой я работал в Intel, была подготовка наборов микросхем Intel ® для перспективных технологий с упором на видеоигры. Мы должны были тестировать самые последние и будущие видеоигры, чтобы обнаруживать возможные ошибки или области для дальнейшего улучшения в архитектуре Intel ® и в самих играх.

Вне работы мне всегда нравилось играть в Halo* 2 с друзьями через Интернет, но, поскольку в Майкрософт отключили Xbox LIVE* для игр для первой консоли Xbox*, мы с друзьями играем в Halo 2 по локальной сети, когда собираемся вместе. Еще мне нравится играть в покер и запускать воздушные змеи. Сейчас я учусь в университете штата Калифорния в Монтерей-Бэй, моя специальность — компьютерные науки и информационные технологии.

Примечания

ИНФОРМАЦИЯ В ДАННОМ ДОКУМЕНТЕ ПРИВЕДЕНА ТОЛЬКО В ОТНОШЕНИИ ПРОДУКТОВ INTEL. ДАННЫЙ ДОКУМЕНТ НЕ ПРЕДОСТАВЛЯЕТ ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМОЙ ЛИЦЕНЗИИ, ЛИШЕНИЯ ПРАВА ВОЗРАЖЕНИЯ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ. КРОМЕ СЛУЧАЕВ, УКАЗАННЫХ В УСЛОВИЯХ И ПРАВИЛАХ ПРОДАЖИ ТАКИХ ПРОДУКТОВ, INTEL НЕ НЕСЕТ НИКАКОЙ ОТВЕТСТВЕННОСТИ И ОТКАЗЫВАЕТСЯ ОТ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ В ОТНОШЕНИИ ПРОДАЖИ И/ИЛИ ИСПОЛЬЗОВАНИЯ СВОИХ ПРОДУКТОВ, ВКЛЮЧАЯ ОТВЕТСТВЕННОСТЬ ИЛИ ГАРАНТИИ ОТНОСИТЕЛЬНО ИХ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ, ОБЕСПЕЧЕНИЯ ПРИБЫЛИ ИЛИ НАРУШЕНИЯ КАКИХ-ЛИБО ПАТЕНТОВ, АВТОРСКИХ ПРАВ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.

КРОМЕ СЛУЧАЕВ, СОГЛАСОВАННЫХ INTEL В ПИСЬМЕННОЙ ФОРМЕ, ПРОДУКТЫ INTEL НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В СИТУАЦИЯХ, КОГДА ИХ НЕИСПРАВНОСТЬ МОЖЕТ ПРИВЕСТИ К ТРАВМАМ ИЛИ ЛЕТАЛЬНОМУ ИСХОДУ.

Корпорация Intel оставляет за собой право вносить изменения в технические характеристики и описания своих продуктов без предварительного уведомления. Проектировщики не должны полагаться на отсутствующие характеристики, а также характеристики с пометками «зарезервировано» или «не определено». Эти характеристики резервируются Intel для будущего использования, поэтому отсутствие конфликтов совместимости для них не гарантируется. Информация в данном документе может быть изменена без предварительного уведомления. Не используйте эту информацию в окончательном варианте дизайна.

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

Перед размещением заказа получите последние версии спецификаций в региональном офисе продаж Intel или у местного дистрибьютора.

Копии документов с порядковым номером, ссылки на которые содержатся в этом документе, а также другую литературу Intel можно получить, позвонив по телефону
1-800-548-47-25 либо на сайте http://www.intel.com/design/literature.htm

Программное обеспечение и нагрузки, использованные в тестах производительности, могли быть оптимизированы для достижения высокой производительности на микропроцессорах Intel. Тесты производительности, такие как SYSmark* и MobileMark*, проводятся на определенных компьютерных системах, компонентах, программах, операциях и функциях. Любые изменения любого из этих элементов могут привести к изменению результатов. При выборе приобретаемых продуктов следует обращаться к другой информации и тестам производительности, в том числе к тестам производительности определенного продукта в сочетании с другими продуктами.

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

Intel и эмблема Intel являются товарными знаками корпорации Intel в США и в других странах. © Intel Corporation, 2014. Все права защищены.

* Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

Разница в результате рендеринга для окна Game и в билде

Всем доброго всего.

Работаю над проектом CRPG, стоит задача — делать объекты полупрозрачными, когда герой забегает за них. В целом задача решена при помощи программного влезания в шейдер объекта (стандартный шейдер Unity), но, как говорится, «есть нюанс».

При запуске теста в редакторе, в окне Game — все отлично. Привожу ссылку на скриншот (яндекс.диск): https://yadi.sk/i/OdkaOXqM3T7pE2

При создании билда и запуске — видно, что у шейдера объекта меняется только свойство RenderType (c Opaque на Transparent), а величина альфа-канала у цвета визуально остается равной единице, хотя в правом верхнем углу выводится информация для дебага, и там указано, что у данного объекта colorAlpha = 0.1. Снова привожу ссылку на скриншот: https://yadi.sk/i/V_0qXeeF3T7pfm

Также привожу код на C#:

robertono Дата: Вторник, 22 Октября 2013, 00:04 | Сообщение # 14
KamiRonin, из твоего выше сказанного, для себя я могу выбрать создание системы вычисления лицевых сторон. Это должно очень сильно поднять производительность (я думаю). А где можно прочитать про батч процессор?

А вот хотелось бы поговорить о чанках — нужны ли они мне? Если я в какой то момент захочу добавить кубам (во время игры, любой куб который я выберу) rigidbody, то получается чанки тогда безсмысслено делать? И если я хочу построить небоскрёб, сделать ему красивое падение и разрушение то чанки тоже уже не годятся?

Occlusion Culling своими руками.
Можно сделать? Точнее вопрос можно ли выглядит тупо, потому что написать можно что угодно. Скорее вопрос «как».
Я видел такую крутую штуку, Field Of View с помощью теней.
http://unitycoder.com/upload/demos/FOVShadowcasting1/
Может можно как то тени обрабатывать но не обрабатывать ? Т.е. как бы просчитывать их но не выводить на экран?
И например куда лучи солнца попадают, всмысле на какие объекты , те и рендерить. Источник света повесить на камеру или игрока. Но что бы тоже света небыло, теней небыло но они обрабатывались (очень сомневаюсь что реально, но может можно сделать как то очень похоже). Так можно было бы не рендерить то что находится например ЗА каким нибудь кубом и совсем не видно!

Добавлено (21.10.2013, 22:52)
———————————————
KamiRonin, Какие вообще есть способы что бы не рендерить объекты которые не видно но они например находятся за какими то объектами спереди?

Добавлено (21.10.2013, 23:00)
———————————————
KamiRonin, А мне кажется всё равно пришлось бы писать свою оклюжн кулинг систему, т.к. которая в про версии она же как запекает объекты, а значит если они динамические то это уже не получится использовать!

Добавлено (21.10.2013, 23:21)
———————————————
KamiRonin, Из чего вообще состоят эти системы? Сетка из триггеров?

Оптимизация сцены и работа со светом в Unity 5 — советы 3D-художника студии Rammen Speed

Платформа для разработки Unity вместе с vc.ru публикует истории разработки игровых проектов, созданных на базе популярной технологии. Расскажите о своём кейсе, чтобы попасть в рубрику.

Сегодня в выпуске — рассказ 3D-художника Киммо Каунела о своей работе с физически обоснованным рендерингом в Unity 5. Автор даёт несколько полезных советов по оптимизации сцен в играх.

Я 3D-художник и живу в Финляндии. Сейчас я работаю в студии Rammin Speed и являюсь частью талантливой команды, работающей над проектом мобильной игры, — отвечаю за вовлечение игроков и общий визуальный стиль. Это работа моей мечты, и этот проект по-настоящему вдохновляет меня.

Я играл в игры почти всю жизнь, и счастлив быть частью этой индустрии. Поскольку я художник-самоучка, то стараюсь быть в курсе новых технологий, во многом из-за этого я и решил заняться Zero Gravity. 3D-графика сочетает в себе красивую визуализацию и технические препятствия, которые нужно каким-то образом преодолевать, и мне всё это очень нравится.

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

Моей целью было создание правдоподобного образа фантастического окружения, которое могло бы существовать в 80-е годы. Просматривая многочисленные материалы, я понял, что космические станции являются модульными структурами, и это понимание стало отправной точкой для моего проекта.

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

О Marmoset Toolbag 2

Начав работать над этим проектом, я занялся изучением физически обоснованного рендеринга. В то время Marmoset Toolbag 2 был для этого лучшим инструментом. Я видел его потенциал, но мне хотелось самому проверить, чего я смогу добиться с его помощью. Этот инструмент отлично подходил для простых моделей, но никто до меня не использовал его для создания окружения.

Я до сих пор использую его для тестирования своих моделей и текстур. Это действительно быстрый и простой в использовании инструмент, который в реальном времени выдаёт результаты, сравнимые с офлайновым рендерингом.

О физически обоснованном рендеринге

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

Многие думают, что физически обоснованный рендеринг можно использовать только для создания фотореалистичный графики, но это не так. Просто намного проще полагаться на физические величины. Это не исключает художественный стиль, но позволяет получать более реалистичные и последовательные результаты. Чем больше созданные вами модели напоминают реальный мир, тем лучше они вовлекают пользователей, а это очень важно для игр и кинофильмов. В качестве примера можно привести студию Pixar с их удивительным пакетом программ RenderMan.

Сейчас физически обоснованный рендеринг поддерживают такие движки, как Unreal Engine 4, CryEngine 3.6 и Unity 5. PBR обеспечивает более качественную графику и, как показывает мой опыт, иногда позволяет работать быстрее по сравнению со старым подходом к шейдингу и текстурированию

Один из ключевых элементов, позволяющих получить красивую графику, — это правильное освещение. Но его расчёт в реальном времени — дорогое удовольствие. Решить эту проблему помогает IBL — Image Based Lighting, освещение, основанное на изображении. Это один из элементов концепции PBR. Смоделировать правильное естественное освещение очень трудно, а IBL позволяет это сделать намного проще.

Ещё одно преимущество PBS (физически обоснованного шейдинга) — то, что он позволяет более точно представить материал. Металл выглядит как настоящий металл, а кроме того, вы можете использовать один и тот же шейдер для многих объектов. До того, как появился PBS, нам приходилось создавать огромное количество шейдеров для разных объектов.

Я привёл всего несколько примеров того, как физически обоснованный рендеринг помогает улучшить графику. Было бы здорово посмотреть, как эта технология работает на мобильных устройствах. PBR требует определённой мощности, и некоторые мобильные устройства пока к этому не готовы.

Работа с Unity 5

Когда я завершил сцену Zero Gravity в Marmoset Toolbag 2, мне захотелось протестировать визуальные возможности Unity 4.6, и я решил построить в нём ту же сцену. Довольно скоро я понял, что это невозможно. Я старался как мог, но, в конце концов получилась обычная сцена из Unity 4. Так случилось потому, что мне нужны были сложные шейдеры и освещение, чтобы повторить результат визуализации, полученный в Toolbag 2.

Я с нетерпением ждал появления Unity 5, потому что знал, что этот движок будет поддерживать PBR и сможет понимать тот язык, который я использовал в Toolbag 2. И действительно, с Unity 5 не было никаких проблем. Я просто импортировал туда свои модели и за несколько часов получил красивый результат. Новая система освещения сделала свою работу замечательно, после того как я разместил в сцене Light probe (зонды освещения) и Reflection probe (зонды отражения). Особенно впечатлила новая система освещения (GI) в реальном времени.

Я использовал те же текстуры, что и в Marmoset Toolbag 2. Всё, что мне пришлось сделать, — это добавить к моделям коллайдеры и контроллер для камеры, и можно было нажимать на кнопку play. За несколько дней я сделал всё, что нужно, со всеми деталями и дополнительными эффектами. Это был настоящий прорыв по сравнению со старой версией Unity.

Unity 5 поддерживает рабочие потоки Spec/Gloss и Metalness/Roughness подходы к шейдингу, так что вы можете выбрать то, что вам лучше подходит. Визуальное качество просто отличное, и эти сцены идут неплохо даже на моём шестилетнем стареньком компьютере. Именно поэтому я считаю Unity 5 огромным шагом вперёд.

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

Система освещения в Unity 5

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

Light probe’ы и Reflection probe позволяют работать с довольно сложными сценами. Технология глобального освещения добавляет реалистичности. Ещё один интересный момент: в новой системе Unity сама рассчитывает фоновое освещение, пока вы делаете свою работу.


Инструменты оптимизации в Unity 5

Я создал много объектов для мобильных игр, поэтому стараюсь оптимизировать всё, что только можно. Мне хочется создать сцену, которая будет работать не только на персональном компьютере, но и на менее мощных устройствах и даже с виртуальной реальностью. На конечную производительность влияет множество мелочей, но есть некоторые вещи, которые я считаю полезными для оптимизации сцен в Unity.

Одна из таких вещей — постараться по возможности организовать модульную работу. То, что сцена Zero Gravity составлена из многих частей, позволяет поддерживать хорошую производительность. Если вы будете использовать одинаковые модели и материалы, движок сможет использовать батчинг и за счёт этого разгрузить центральный процессор. Конечно, уникальные детали тоже нужны, поэтому конечный результат представляет собой комбинацию модульных и уникальных частей.

Постарайтесь разбить ваш уровень на несколько слоёв и подумать, какие из них требуют большего количества деталей. Я обычно стараюсь делить мои сцены на три разных слоя.

  • Первый слой — структурный (пол, крыша, стены), поверх него будет лежать средний слой.
  • Средний слой (панели для стен, двери, мебель) должен иметь больше деталей, чем структурный слой, потому что его игрок будет больше рассматривать.
  • Верхний слой должен быть самым проработанным из всех. Этот слой содержит те предметы, которые игрок будет видеть очень близко и с которыми будет взаимодействовать.

Ещё одна вещь, о которой нельзя забывать, — это текстурные разрешения. В моей системе было всего 512 Мбайт видеопамяти, и я старался не превышать этот предел. Чтобы всё гладко работало, лучше заранее планировать работу с текстурами. Сходные элементы в моделях могут занимать одно и то же текстурное пространство, а также несколько моделей могут использовать одинаковые текстуры.

Старайтесь экономить текстурное пространство, используя его для нескольких моделей. Я называю это текстурным атласом. Это облегчает батчинг в Unity и сокращает время, которое вы тратите на работу с текстурами. При этом не обязательно использовать одни и те же текстурные разрешения со всеми картами, а также старайтесь использовать простой цвет для альбедо (вместо детальной текстуры, как при старом подходе).

Для хорошей производительности идеально подходят повторяющиеся (tiling) текстуры, поэтому по возможности используйте их чаще.

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

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

Несколько предложений для будущих версий Unity 5

Unity 5 — это действительно большой шаг вперёд во многих отношениях. Мне очень нравится, что все визуальные эффекты и профайлер можно использовать даже в бесплатной версии, хотя раньше они были доступны только в версии PRO. Это делает Unity очень интересным и конкурентоспособным движком.

Я мало что понимаю в программировании шейдеров, поэтому мне бы хотелось иметь в Unity 5 какой-нибудь визуальный редактор, позволяющий создавать простые шейдеры или скрипты, как в UE4. К счастью, в Unity Asset Store есть такие инструменты, но всё же было бы хорошо, если бы они были по умолчанию встроены в Unity 5.

Эффекты частиц — это то, что тоже хорошо бы усовершенствовать в Unity. Во всём остальном Unity 5 — отличный движок для самых разных платформ.

Если вы работаете на технологии Unity, хотите рассказать о своём опыте разработки или задать вопрос экспертам — оставьте заявку нашим менторам с помощью специальной формы.

Советы по оптимизации VR-проектов

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

По сути, в оптимизации нет ничего сложного, но только в том случае, если делать ее заблаговременно и часто. Представьте себе 4-сторонние качели, которые стоят на крыше поезда, и во все четыре сидения воткнуты булавки, а на каждой булавке балансирует шар для боулинга. Каждый шар отвечает за какой-то тип нагрузки – размер проекта, процессор, видеопроцессор и оперативная память. Поезд – это весь остальной проект, на огромной скорости мчащийся вперед. Вам, как оптимизатору, нужно смотреть на эту картину в целом и понимать, по каким законам двигаются все части этого сложного механизма.

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

В качестве введения

Хотя виртуальная реальность открывает перед разработчиками целый простор возможностей, графика во многих ВР-проектах выглядит так, будто ее делали несколько десятков лет назад. Поэтому я попробую рассказать о трудностях, возникающих при оптимизации ВР-проектов, о том, как с этими трудностями справиться, а также об оптимизационных технологиях, которые появятся в ближайшем будущем. Это будет глубоким погружением в тему производительности, с обилием технической зауми (в частности, будет рассказано о автоматизированных системах для оптимизации ассетов). Поэтому читатель должен хорошо разбираться в работе игровых движков и быть заинтересован в том, чтобы выжать из своих систем самый максимум. Это не стандартный набор приемов по игровой оптимизации – об этом было написано уже не раз. Вместо этого мы сфокусируемся на темах «Нам нужно оптимизировать эту тысячу ассетов, но людей категорически не хватает» или «Мы оптимизировали все, что могли, но фреймрейт по-прежнему пробивает дно».

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

В настоящий момент плохая производительность в ВР главным образом связана с тремя вещами – лагами/задержками, фреймрейтом и многоэкранным рендерингом. Давайте рассмотрим каждую из них поподробней.

Лаги и задержки

Каждая ВР-система (будь то Vive, Rift или PSVR) оснащена станциями, чьи вычислительные ресурсы используются, во-первых, для обработки данных о расположении/вращении игрока и игровых устройств в 3-мерном пространстве, и во-вторых, для расчета прогнозов (с частотой 90 раз в секунду или даже чаще) о том, где игрок или игровые девайсы будут находиться в будущем. К примеру, если человек идет вперед, эти станции будут считать, что человек будет по-прежнему идти вперед. На это тоже требуются вычислительные ресурсы, которые не бесконечны.

Другая проблема – в скорости отслеживания. Во-первых, она отличается у разных ВР-систем, а во-вторых, у одних ВР-систем она более масштабируема, чем у других. Данные, потерянные из-за несовпадения скорости отслеживания и фреймрейта, компенсируются за счет прогнозов. Базовые станции Vive обновляются каждые 4 мс, а на Rift обновление привязано к фреймрейту, но в любом случае при фреймрейте 90 к/сек объект, двигающийся быстрее заданной скорости, будет лагать, и этих лагов можно избежать, только если ВР-шлем высчитывает прогноз.

Есть и проблемы, характерные для конкретных ВР-систем. К примеру, у Vive возникают трудности из-за репроецирования и композитинга функций вроде «Chaperone», а на обработку данных, генерируемых OSVR, по сообщениям некоторых пользователей, уходят целые ядра.

Как быть разработчику?

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

Фреймрейт

Теперь давайте перейдем от «тяжелых ранений» (т.е. от задержкек и лагов) к «поверхностным ранам» (т.е. к проблемам с фреймрейтом). У большинства обычных ААА-игр фреймрейт составляет в пределах 30-60 к/сек – вроде бы немного, да? Всего-то на треть быстрее. Но на самом деле проблема очень серьезна. Конечно, у большинства ВР-систем случайный провал фреймрейта можно компенсировать за счет репроецирования, но при сильной нагрузке не помогает и оно. Поэтому важно, чтобы у вас всегда оставался запас вычислительных ресурсов – особенно при использовании Vive. Если ваш проект рассчитан на 90 к/сек и не имеет такого запаса, то на какой-нибудь навороченной сцене фреймрейт может запросто обвалиться до 45 к/сек. Во избежание этого свой проект нужно подогнать под 100-110 к/сек, чтобы у вас наверняка хватило производительности на того 45-голового босса, с которым игроку предстоит сражаться на протяжении 10 минут.

Есть еще один фактор, который очень часто остается незамеченным – ресурсы, которые расходуются на вычисления, выполняемые драйвером. Для разработчиков игра – это что-то вроде шампуня. Процессор отсылает данные видеопроцессору, а тот показывает их на экране. Намылить, смыть и повторить Х раз в секунду и… бум! Игра готова. Но эти маленькие надбавки наслаиваются друг на друга, что в конце концов влияет и на производительность. Картинка ниже демонстрирует ситуацию, при которой на драйвер уходят непомерные 35% всех вычислительных ресурсов, затрачиваемых на выполнение ВР-проекта.

Как быть разработчику?

Чем выше фреймрейт, тем эффективней должна быть оптимизация. К примеру, что касается игр, то для них запас производительности должен быть очень большим. На переднем краю борьбы с этой проблемой находятся, собственно, сами драйверы; в частности, интересные возможности есть у DX12, Mantle и Vulcan. Кроме того, в будущем этих возможностей, а также драйверов и чипсетов, наверняка станет еще больше. Более подробно о методах борьбы с этой проблемой можно почитать тут.

Многоэкранный рендер

Внутри каждого ВР-шлема находятся два экрана – по одному на каждый глаз. Изображения на них смещены относительно друг друга, чтобы создать у пользователя иллюзию глубины и убедить его, что он находится именно на горе Эверест, а не в своей комфортной московской квартире. Но при использовании двух экранов удваивается и количество объектов, которые нужно отрендерить на экранах. Добавьте сюда необходимость два раза отрендерить одну и ту же текстуру. Добавьте сюда эффекты вроде карт нормалей или спрайтовых частиц. Плюс фреймрейт в 90 к/сек. Плюс обработка данных о движении игрока и девайсов. Но самый смак – это разрешение экранов, составляющее 2160 х 1200 (по 1080 х 1200 на каждый глаз), что сопоставимо с разрешением среднестатистического монитора формата 1080p. Кроме того, свою долю привносит и сглаживание. Поскольку экраны ВР-шлема находятся прямо у ваших глаз, качество картинки должно быть гораздо лучше, чем в обычных играх.

Как быть разработчику?

Во-первых, разработчик может воспользоваться функцией, принцип работы которой очень прост: если игра лагает, она уменьшает размер экрана и снижает качество сглаживания. Во-вторых, можно обеспечить постоянную отправку команд на GPU, чтобы ему всегда было, чем заняться. В-третьих, можно воспользоваться так называемым «экземплярным стерео-рендерингом» (от англ. «instanced stereo rendering») – это технология, которая берет информацию обо всех объектах на сцене, подготавливает ее на CPU, но пока только для одного глаза, затем упаковывает эту информацию, выполняет смещение, чтобы подогнать картинку под второй глаз, и лишь после этого выполняет рендер. Более подробно об этой технологии можно почитать тут.

Кроме того, есть технология «ямковый рендеринг» (от англ. «foveated rendering»), которая увеличивает разрешение центральной части экрана, попутно снижая разрешение периферийных областей. Это позволяет существенно снизить количество данных, идущих на каждый экран. При использовании технологии «кругового разуплотнения» (от англ. «radial density masking») картинка в центре остается неизменной, а на периферии формируется «шахматное» изображение, в котором одна половина пикселей рендерится, а вторая – нет, после чего на основе этой «шахматной» картинки формируется еще одна, где оставшиеся пиксели несут в себе информацию об утерянных пикселях. Более подробно об этих технологиях можно узнать в этой презентации от Алекса Влачоса (Alex Vlachos).

Большинство этих техник реализовано, к примеру, в программе Lab Render for Unity от Valve.

Решения будущего

Более эффективные устройства и ПО

В последнее время разработчики пытаются улучшить производительность игровых движков при помощи многопоточности (т.е. одновременной обработки данных несколькими процессорами), но для многих платформ эта технология пока в новинку. Если производители PC-комплектующих уже провели серьезную работу над повышением производительности ВР-проектов, то у производителей ВР-шлемов все еще впереди. Сегодняшний ВР-шлем – это, как правило, довольно примитивное устройство, просто импортирующее картинки на экраны. Новые версии должны быть оснащены собственными вычислительными ресурсами для обработки данных о движении, стерео-рендеринга и репроецирования (на случай низкого фреймрейта).

Улучшенное охлаждение на мобильных устройствах

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

Круговое разуплотнение (radial density masking)

Эта технология рендерит каждый второй пиксель, находящийся на периферии, а затем использует «уцелевшие» пиксели для восстановления неотрендеренных пикселей. Такой подход дает неплохой (но и не гигантский) прирост производительности – в некоторых случаях вплоть до 10%. Если использовать эту технологию вместе с ямковым рендерингом, можно добиться улучшения производительности, практически не жертвуя качеством картинки.

Ямковый рендеринг (foveated rendering)

Эта технология снижает разрешение периферийных участков изображения. Сейчас эту технологию правильней будет назвать фиксированным ямковым рендерингом: у центральной трети экрана разрешение увеличено, а у двух оставшихся – уменьшено. В ближайшем будущем должны появиться две новые версии этой технологии: акцентный ямковый рендеринг (от англ. «perceptually based foveated rendering») и следящий ямковый рендеринг (от англ. «gaze based foveated rendering»). В первом случае детализация изменяется в зависимости от важности объектов, находящихся в центре, а во втором – в зависимости от того, куда направлен взгляд пользователя (для этого используется слежение за движениями глаз). Эти технологии разбиваются на мириад других технологий вроде глубины резкости, зависящей от взгляда пользователя, или уровня детализации, зависящего от взгляда пользователя и т.д. Правда, при использовании следящего ямкового рендеринга разработчикам придется оснастить свои ВР-шлемы дополнительными вычислительными ресурсами, чтобы обработка данных о слежении за глазами не ложилась на плечи PC-комплектующих.

Но наличие всех этих технологий не отменяет творческого подхода к работе с аппаратными, программными и гейм-дизайнерскими ограничениями. Если использовать эти технологии по отдельности, они могут создать загруженность в других участках системы. К примеру, экземплярный стерео-рендеринг может увеличить нагрузку на GPU на 257%. Другие технологии могут переместить проблемы с производительностью в места, которые уже испытывают сильную нагрузку. К примеру, оптимизировать GPU при сильной загруженности CPU – это не только потеря времени, но и медвежья услуга всему проекту.

Как оптимизировать свой проект?


В данный момент возможности разработчиков ограничены, но большинство проблем ВР-проектов – такие же, как и в обычных играх. Следовательно, инструментарий для борьбы с этими проблемами будет примерно тем же. Разработчики мобильных игр могут задействовать уже известные им методы вроде атласинга (от англ. «atlasing»; это технология, при которой текстуры/материалы комбинируются в одном месте, которое и называется «атласом»; близкий термин – «текстурный атлас»), использования одного большого шейдера или запекания большинства (а то и всех) текстур. Если вы разрабатываете мобильную игру или используете для ВР свой ноутбук, то на производительность вашего проекта будет очень сильно влиять тротлинг. Современные GPU всегда испытывают максимальную загруженность – из-за особенностей своего устройства. Но если задействовать более мощный CPU (вроде 7-го поколения Intel Core i7 или лучше), это позволит разгрузить GPU и тем самым увеличить производительность. Это проблема, с которой разработчики сражаются годами: один GPU, один экран, отложенный рендеринг, полноэкранные эффекты. Но в ВР не один, а целых два экрана, и в итоге GPU загружен почти постоянно, поэтому умение оптимизировать GPU становится все важнее. В частности, Oculus не рекомендует использовать полноэкранные эффекты – как раз из-за последствий для производительности.

Анализ проекта

Чтобы выяснить, насколько сильно ваш проект нагружает CPU и GPU, можно воспользоваться инструментом Intel Graphics Performance Analyzers. Он удобен тем, что собирает все данные о производительности в одном месте. Скачать его можно отсюда, а обучающие материалы можно найти тут и тут.

Количество полигонов

Для обычных игр это практически не проблема, т.к. современные компьютеры могут с легкостью выдать несколько миллионов треугольников и даже не запыхаться. Однако для ВР-проекта проблемой будут даже 3 миллиона полигонов. Полигонную оптимизацию можно использовать и на «сырой» версии ассета, и на LOD-версиях.

Как определить

Как правило, у ВР-проекта нет ограничения на количество полигонов, но этот показатель тесно связан со скоростью заполнения (от англ. «fillrate»), освещением в реальном времени и сложностью шейдера. Проблемы со скоростью заполнения могут возникнуть из-за чрезмерного «загораживания» (от англ. «overdraw»; это ситуация при которой одни объекты загорожены другими, поэтому загороженные объекты рендерятся впустую), и снижение количества полигонов придется здесь весьма кстати. Если в вашем проекте используется много освещения в реальном времени, каждая из этих «ламп» дополнительно рендерит полигоны для упреждающего рендеринга (от англ. «forward rendering»; это рекомендуемая технология для ВР). Еще одна гремучая смесь – это сложный шейдер плюс большое количество полигонов, поэтому я рекомендую использовать для ВР мобильные шейдеры. Но чтобы картинка засияла, к делу нужно подойти творчески. Если просто снизить количество полигонов, «шейдерная» выгода будет совсем небольшой.

Что делать

Если у вас достаточно рабочих рук, то ни секунды не сомневайтесь и делайте эту работу руками. Если у вас достаточно средств, воспользуйтесь программами вроде Simplygon и Decimator от Maximo. Но есть и альтернативная техника, которая может разом обработать целую кучу ассетов. Используя ее, не забывайте про управление версиями, потому что такая «ковровая» оптимизация вряд ли сработает для всех моделей. К примеру, она плохо подходит для персонажных ассетов, и в этом случае вы наверняка захотите откатить оптимизацию назад.

import pymel.core as pm
# выделяем все объекты по типу геометрии:
pm.select(pm.listRelatives(pm.ls(geometry=True), p=True, path=True),r=True)
objectsToReduce = pm.ls(sl=True)
for objectToReduce in objectsToReduce:
pm.select(objectToReduce)
pm.polyReduce(percentage=35, version=1)

Уровни детализации (LOD)

Здесь проблемы возникают из-за двух вещей: ограниченного количества вершин и ограниченного количества команд отрисовки. Работа над уровнями детализации позволяет оптимизировать сцены за счет снижения детализации у объектов, находящихся на заденем плане. К примеру, перед носом у вас щелкает своими многочисленными челюстями 45-головый монстр, а на заднем плане ютится маленький чайник, на который приходится 2 тысячи полигонов и 6 команд отрисовки: цвет, карта нормалей, карта высот, карта отражений и запеченный объемный свет. 45-головый монстр, напомню, дышит вам прямо в лицо, а чайник тихонько булькает в дальнем углу. Какому объекту снизить детализацию? Монстру, верно? LOD в помощь!

Как определить

Конечно, LOD’ы не помогут вам в каждой сцене и с каждым объектом. Порой от использования LOD’ов становится даже хуже. LOD’ы подойдут для объектов с большим количеством полигонов и команд отрисовки – вроде большой или открытой комнаты, заполненной различными точками интереса. Но разумней всего использовать LOD’ы в сцене с небольшим количеством объектов, потому что люди склонны фокусироваться на отдельных предметах. Во всех этих случаях не следует сначала применять команды отрисовки, а потом делать LOD’ы, как и не стоит использовать LOD’ы в маленьких и тесных сценах. Дело в том, что переход от одного уровня детализации на другой происходит даже из-за малейших движений игрока, а эти переходы тоже стоят вычислительных «денег». Наслаиваясь друг на друга, они могут вызвать проблемы с производительностью, так что пользоваться LOD’ами нужно мудро.

Что делать

При работе с LOD’ами разработчик занимается тремя вещами: оптимизацией моделей, оптимизацией материалов и оптимизацией шейдеров. Для примера давайте возьмем все тот же чайник. Хотите реализма? Добавьте чайнику карту деталей. Хотите показать, что бабушка главного героя лелеяла этот чайник до своего самого последнего дня? Добавьте ему какой-нибудь приятный шейдер вроде PBR. Как только главный герой отдалится от чайника, уберите карты высот и нормалей, а затем вполовину уменьшите количество вершин, а когда удалится еще дальше – еще раз урежьте вершины и поменяйте шейдеры на мобильные.

import pymel.core as pm
# не забудьте выбрать объект:
reductionPrecentages = [0,10,20]
nameOfLODS = []
selectedObject = pm.ls(sl)
for x in range(0,ReductionPrecentages.length):
newName = (selectedObject + «_LOD[%s]»)%(x)
pm.duplicate(newName)
pm.parent(selectedObject)
pm.polyReduce(percentage=reductionPrecentages[x], version=1)

Это обновленный скрипт хорошо работает для Unity и даже выполняет за вас группировку LOD’ов. Мы модифицируем цикл for(), создаем переменную с процентом оптимизации и добавляем к этой переменной суффикс _LOD[переменная]. Затем пробегаем по списку необходимых размеров и экспортируем через FBX. Далее импортируем в Unity и – вуаля! – у нас есть группа LOD’ов.

Количество объектов

Все просто – чем больше объектов, тем больше ресурсов система тратит на их обработку. То же касается и текстур, наложенных на эти объекты.

Как определить

Давайте снова вспомним про чайник и добавим к нему целый чайный набор – с блюдцами, ложками, чашками и т.д. В результате у нас получится много разных объектов, для каждого из которых нужны специальные материалы и текстуры. Следовательно, для оптимизации этих объектов потребуются разные методы: просто комбинирование, комбинирование + атласинг и комбинирование + атласинг + LOD (для «дальних» уровней с низкой детализацией).

Комбинирование – это техника, при которой вы просто объединяете объекты воедино. Она помогает оптимизировать сцену при загораживании, потому что рендерит всё одним объектом, превращая весь чайный набор в одну сетку.

Комбинирование + атласинг – это техника, при которой, во-первых, все объекты объединены в одну сетку, а во-вторых, у них на всех лишь одна текстура. Данный метод очень эффективен для ВР-игр, т.к. объединенные текстуры стоят, выражаясь образно, жалкие копейки. Преимущество этой техники в том, что она требует всего шесть команд отрисовки, а недостаток – в том, что вы жертвуете детализацией, т.к. каждый объект, скорее всего, имеет собственную карту деталей.

Комбинирование + атласинг + LOD – это техника при которой объекты объединяются в одну сетку и оснащаются одной текстурой, но только на самых дальних уровнях детализации. С одной стороны, это позволяет сохранить детализацию, если игрок смотрит на объект вблизи, а с другой, позволяет быстро переключиться на оптимизированную версию, когда игрок отдаляется от объекта. В частности, эта техника полезна, если игрок может взять объект в руки.

Что делать

Если вы решили воспользоваться простым комбинированием, просто создайте скрипт с этим кодом (это из документации к Unity о функции Mesh.CombineMeshes):

using UnityEngine;
using System.Collections;
[RequireComponent(typeof(MeshFilter))]
[RequireComponent(typeof(MeshRenderer))]
public class ExampleClass : MonoBehaviour <
void Start() <
MeshFilter[] meshFilters = GetComponentsInChildren ();
CombineInstance[] combine = new CombineInstance[meshFilters.Length];
int i = 0;
while (i ().mesh = new Mesh();
transform.GetComponent ().mesh.CombineMeshes(combine);
transform.gameObject.active = true;
>
>

Если вы решили воспользоваться комбинированием с атласингом, советую программу Mesh Baker – она сэкономит вам множество рабочих часов. Для связки «комбинирование + атласинг + LOD» советую воспользоваться Mesh Baker LOD. Более подробно можно почитать тут и тут.

Есть и более продвинутая техника, которая, впрочем, потребует творческого подхода. Ее суть в том, чтобы экспортировать каждый LOD для каждого фрагмента каждого объекта. Сначала при помощи Mesh Baker скомбинируйте все сетки с высокой детализацией, но без объединения текстур. Затем дайте Mesh Baker оптимизировать среднюю детализацию и удалите некоторые текстуры. Наконец, для сеток с низкой детализацией замените все шейдеры максимально «легкими», но приемлемыми, а затем скомбинируйте. Эта техника потребует много времени, но зато сэкономит вам кучу вычислительных ресурсов.

Команды отрисовки (draw calls)

Команда отрисовки – это то, что через драйвер передается от CPU к GPU. Чем меньше команд прорисовки и чем они проще – тем лучше. Самый простой способ оптимизации команд отрисовки – это оптимизация количества разных материалов и текстурных атласов, а также сокращение количества второстепенных текстур вроде карт высот, карт нормалей и карт отражения. Выше я уже упоминал об оптимизации команд отрисовки, но в этом разделе я расскажу об этом поподробней.

Как определить

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

Что делать

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

Также полезно изучить игру самостоятельно, с надетым ВР-шлемом. Объекты, которые первыми бросаются в глаза, в будущем могут стать серьезной нагрузкой на вычислительные ресурсы. Если ассет не видно, просто удалите его, а если видно – попробуйте объединить его текстуры. Хотя это и требует дополнительной RAM-памяти и места на диске, зачастую комбинирование текстур стоит того, даже если вы заполняете атлас не полностью. Объединение текстур в один материал без объединения сеток дает гибкость в детализации.

Еще одно решение – самостоятельно разработать гибридную систему LOD’ов для объектов, двигающихся независимо друг от друга. Она начинает обрабатывать объекты, если они оказываются на такой дистанции, когда их можно будет объединить. Учтите, однако, что время пребывания объектов на экране может варьироваться, поэтому использование этой техники может быть хуже для производительности, чем ситуация, когда объекты обрабатываются раздельно. С другой стороны, этот прием может помочь, если GPU сильно загружен, а у CPU, наоборот, еще остались ресурсы для работы над другими задачами.

Еще одна техника, о которой разработчики почему-то часто забывают – это комбинирование текстур. Это НЕ атласинг, о котором я рассказывал выше; эту технику еще называют «укладкой в каналы» (от англ. «channel packing»). Ее суть в том, чтобы поместить разные карты в разные каналы одного RGB-файла. К примеру, у нашего чайника есть карта объемного света, карта отражений и карта высот. Если поместить объемный свет в красный канал, отражения – в зеленый канал, а высоты – в синий канал, в итоге у нас получается всего одна команда отрисовки. Останется лишь повозиться с тем, чтобы шейдеры знали, где искать нужную карту, но в этом, в общем-то, вся суть оптимизации слабодетализированных объектов.

Итак, процедура такова:

  • Выберите слой
  • Перейдите в каналы
  • Уделите зеленый и синий каналы, чтобы у вас остался один лишь красный канал
  • Перейдите к слоям и повторите то же самое для зеленого канала
  • Сделайте то же самое для синего канала
  • PROFIT!

Запечение обычного света и объемного света (baking)

Как вы уже, наверно, поняли, в ВР любые данные лучше обрабатывать заранее. CPU почти все время занят, пока GPU пыжится обработать спид-дейтинг сразу двух игр. Это значит, что чем больше вещей запечено – тем лучше. Используете везде освещение в реальном времени? Готовьтесь к куче проблем.

Как определить

Почти всему нужны карты теней, т.е. всем объектам, которые не взаимодействуют с освещением, обрабатываемом в реальном времени. Более подробно смотрите ниже. О том, как работать с картами теней, смотрите в Lab Render от Valve.

Что делать

Во-первых, ищите все, что можно запечь. К сожалению, в данный момент карты теней в Unity устроены так, что запечение света в больших сценах – это очень замороченный (а временами и вовсе безрезультативный) процесс. Поэтому рекомендую сначала экспортировать все ассеты в 3D-редактор вроде Maya, а затем спокойно запечь и обычный, и объемный свет. Создание хороших карт теней – это тема для отдельной статьи. По этой ссылке – документация по плагину Turtle для Maya, а по этой – документация по запечению объемного света при помощи Substance.

Недостаток этого метода в том, что вам также придется создать шейдеры, поддерживающие вновь созданные карты теней. Их, впрочем, не обязательно создавать с нуля – вы можете «разобрать», а затем оптимизировать шейдеры от Valve.

Тени от освещения в реальном времени не обязаны быть, собственно, тенями. Просто определите направление света, чтобы создать имитацию тени на земле – например, с помощью анимированного текстурного атласа, сопоставимого с персонажной анимацией или даже с древней методой, известной как «пузырь» (от англ. «blob shadow»; это обычная круглая тень), к которому прикручена возможность угловой изменчивости. Удивительно, но такую подделку замечают очень немногие.

Шейдеры

Шейдеры – корень зла (если говорить исключительно об оптимизации ВР-проектов). Лишь немногие разработчики умеют писать шейдеры, и многие из этих шейдеров плохо оптимизированы под ВР. Поэтому самый лучший подход – это либо воспользоваться мобильными шейдерами, либо творчески подойти к созданию собственного шейдера.


Как определить

Если у шейдера больше 4 слотов, и объект, для которого он используется, вряд ли привлечет пристальное внимание пользователя, то этот шейдер, по всей видимости, плохо оптимизирован для вашего ВР-проекта. Единственное, что нужно объектам «массовки» в ВР – это цвет, карта нормалей, карта обычного света и карта объемного света.

Что делать

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

Технология Occlusion Culling

Вы, вероятно, знаете, что в Unity по умолчанию включена технология Frustum Culling, которая отсекает все объекты, которые не находятся в поле зрения игрока. Но вдобавок к этому в Unity есть и технология Occlusion Culling (можно перевести как «отсечение загороженных объектов»). Представьте, к примеру, что позади нашего чайника лежат столовые ложки. При включенном Occlusion Culling эти ложки рендериться не будут, что благоприятно повлияет на производительность.

Как определить

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

Что делать

Occlusion Culling может быть и благом, и проклятьем. Лично моя точка зрения такова, что об Occlusion Culling не нужно беспокоиться вовсе. К примеру, представьте, что на столе стоит чайный набор, а вы стоите в соседней комнате, поэтому отгорожены от этого набора стеной. Как правило, в играх этот набор рендерится, а затем выбрасывается – как раз из-за стены. Но технология Occlusion Culling видит всю сцену заранее просчитанной решеткой, которая состоит из ячеек и знает, где какие объекты находятся. Камера отсылает лучи, чтобы проверить, какие ячейки попадают в поле ее видимости, а какие – нет. Ячейки, которые в поле видимости не попадают, не рендерятся. Советую для начала попробовать стандартные настройки – чтобы посмотреть, дает ли это хоть какой-то результат. Если результата нет, можно немного повозиться с настройками, благо много времени это не отнимет. А если отнимет – бросайте настройку и смело ставьте сцену на рендер. Если заметили улучшение, измерьте точный «вес» всех объектов на сцене.

И еще одна техника напоследок

Она совсем новая и называется «гибридный моно-рендеринг» (от англ. «hybrid mono rendering»). Если вкратце, ее суть в том, что объекты, находящиеся вблизи, рендерятся в стерео, а удаленные объекты – в моно. Подробнее о ней можно прочесть тут.

Дополнительные материалы

Надеюсь, эта статья поведала вам немало новых и интересных идей об оптимизации в сфере ВР. Но это – лишь капля в море, потому что…

  • …здесь можно почитать об оптимизации ВР в Unity
  • …а здесь – об оптимизации ВР в Unreal

Также выражаю большую благодарность программе Intel Innovator Program за поддержку в написании этой статьи.

Об авторе

Тим Портер (Tim Porter) трудится разработчиком графики для PC и ВР в Underminer Studios. Он имеет богатый опыт в работе с передовыми графическими технологиями, благодаря чему научился множеству полезных приемов и трюков. Кроме того, ранее он работал техническим художником, что позволяет ему видеть проблемы с оптимизацией максимально широко. Связаться с ним можно по почте.

Планирование оптимизации с Unity*

Представлено: Alexey Kostadinov, опубликовано: 30 марта 2015 г.

By John Wesolowski

Загрузки

Аннотация

Unity содержит ряд настроек и инструментов, позволяющих добиться плавной работы графики в играх. Для этого проекта мы отобрали те из них, с которыми могут возникнуть сложности, и проанализировали их влияние на производительность игр на ГП Intel ® .

Мы рассматриваем использование Unity с точки зрения разработчика игр. Мы стремились найти области снижения производительности, а затем определить, как улучшить работу приложений с помощью встроенных в Unity средств. Одно из преимуществ Unity состоит в возможности быстрого создания контента, но для того, чтобы добиться производительности, особенно на мобильных устройствах и планшетах, разработчику потребуется тщательно спланировать использование встроенных механизмов оптимизации производительности. В этой статье новым и существующим пользователям Unity предлагаются советы по повышению производительности при создании уровней и игр, а также описываются новые способы создания содержимого.

Введение

Создавать игры с использованием Unity относительно просто. В Unity имеется магазин, где можно приобретать различные элементы, такие как модели, готовые сценарии, демо или даже полные игры. Для тестирования я работал с существующей игрой, чтобы определить, в каких областях можно добиться повышения производительности, а в каких — нет. Я использовал техническое демо Unity под названием Boot Camp (ее можно бесплатно загрузить в магазине ресурсов), чтобы оценить сложность проблемы.

Для создания игровых параметров и запуска всех сцен я использовал Unity 3.0. Тестирование проводилось на компьютере с процессором Intel ® Core ™ 3-го поколения с ГП Intel ® HD Graphics 4000. Результаты тестирования неприменимы к мобильным устройствам.

Quality Manager

В Unity доступны дополнительные параметры рендеринга для игр: меню Edit->Project Settings->Quality (рис. 1). Это настраиваемые параметры рендеринга, которые можно настроить индивидуально. В Unity содержится встроенная документация, поясняющая параметры качества и их настройку с помощью API сценариев Unity.

Рисунок 1. Доступ к тегам и слоям осуществляется через меню Edit->Project Settings->Tag inspector

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

Качество текстур

В Quality Settings Inspector есть раскрывающееся меню, где можно выбрать разрешение рендеринга для текстур. Можно выбрать разрешение 1/8, ¼, ½ или полное разрешение. Для оценки прироста или снижения производительности при разном разрешении текстур я измерил кадровую скорость тестовой сцены при всех доступных в Unity настройках качества по умолчанию (Fastest, Fast, Good и пр.), изменяя только качество текстур перед каждым измерением.

На рис. 2 и 3 показано сравнение между сценами с 1/8 разрешения текстур и с полным разрешением текстур .

Рисунок 2. Сцена Unity* Boot Camp с разрешением 1/8

Рисунок 3. Сцена Unity* Boot Camp с полным разрешением

Мы измерили кадровую скорость (в кадрах в секунду) с помощью Intel ® Graphics Performance Analyzers (Intel ® GPA) после изменения разрешения текстур. При уровне качества Fantastic (таблица 1) видно, что производительность не слишком заметно изменилась при изменении размера текстур.

Таблица 1. Изменение кадровой скорости при переключении между различным качеством текстур в Unity

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

Shadow Distance

Shadow Distance — это параметр, определяющий глубину отбраковки, используемую для теней игровых объектов. Если игровой объект находится в пределах заданного расстояния от камеры, то тени этого объекта отрисовы­ваются, если же объект находится дальше этого расстояния, то тени такого объекта не отображаются (исключаются из отрисовки).

В зависимости от используемых параметров тени могут отрицательно повлиять на производительность, поскольку их расчет и отрисовка являются ресурсоемкими операциями. Тестирование влияния параметра Shadow Distance

  • Создайте тестовую сцену.
  • Задайте для этой сцены параметры качества Unity по умолчанию.
  • Постепенно увеличивайте значение параметра Shadow Distance и измеряйте кадровую скорость с помощью Intel GPA.
  • Выберите другое значение качества по умолчанию в Unity и повторите измерение кадровой скорости.

В этом тесте уровни качества Fastest и Fast не использовались, поскольку в этих режимах тени отключены.

Рисунок 4. Этот параметр доступен в меню Inspector: Edit->Project Settings->Quality

Рисунок 5. Техническое демо Unity* Boot Camp

Таблица 2. Изменение кадровой скорости при изменении значения параметра Shadow Distance в технической демонстрации Unity* Boot Camp

Тени значительно влияют на производительность. Тест показал, что кадровая скорость упала почти вдвое при переключении расстояния с 0 до 50 в режиме Simple. Важно учитывать, действительно ли видны игровые объекты, и убедиться, что ненужные тени не отрисовываются. Глубину отбраковки теней можно настра­ивать с помощью сценариев Unity для различных ситуаций. Мы проверили только воздействие глубины отбраковки теней, но аналогичные изменения производи­тельности могут возникать и при настройке других параметров качества теней.

Слои


Всем игровым объектам в Unity при создании назначается слой. Изначально всем объектам назначается слой по умолчанию, как показано на рис. 6, но можно создать собственные уникальные слои. Это можно сделать двумя способами. Можно просто щелкнуть поле Layer и выбрать Add New Layer. Также можно использовать меню Edit->Project Settings->Tags.

Рисунок 6. Меню Layer в окне Inspector игрового объекта

Рисунок 7. Tag Manager в окне Inspector

В окне Inspector (рис. 7) можно создать новый слой и указать, к какому номеру слоя он должен принадлежать. При использовании обоих методов открывается одно и то же окно Tag Manager. После создания слоя можно назначать этому слою игровые объекты, выбирая нужный слой в окне параметров в окне Inspector игрового объекта в поле Layer. Таким способом можно группировать объекты на одних и тех же слоях, чтобы затем обрабатывать их вместе. Помните о том, что такое слои, и как их создавать и настраивать, когда я буду рассказывать о некоторых других функциях слоев в этой статье.

Расстояния отбраковки слоев

Камера не будет отрисовывать игровые объекты, находящиеся за пределами плоскости отсечения в Unity. С помощью сценариев Unity можно задать для определенных слоев более короткое расстояние до плоскости отсечения.

Рисунок 8. Образец сценария из документации Unity с изменением расстояния отбраковки слоев

Настройка более короткого расстояния отбраковки для игровых объектов требует некоторой работы. Сначала нужно разместить объекты на слое. Затем нужно написать сценарий, чтобы изменить расстояние отбраковки этого конкретного слоя, и назначить сценарий камере. Образец сценария на рис. 8 показывает, как создается массив 32 значений с плавающей запятой, соответствующий 32 доступ­ным слоям, которые можно создать с помощью меню Edit->Project Settings->Tags. Если изменить значение индекса в этом массиве и присвоить его camera.layerCullDistances, то для соответствующего слоя изменится расстояние отбраковки. Если не назначить число индексу, то соответствующий слой будет использовать дальнюю плоскость отсечения камеры.

Для тестирования производительности layerCullDistances я создал три сцены, заполненные объектами низкой, средней и высокой сложности. В этих сценах идентичные игровые объекты собраны вместе и расположены в ряд с постепенным удалением от камеры. Я использовал Intel GPA для измерения кадровой скорости при постепенном увеличении расстояния отбраковки слоя, добавляя по группе объектов при каждом измерении (т. е. одна группа объектов при первом измерении, 6 групп объектов при шестом измерении).

На рисунках 9, 10 и 11 показаны сцены, которые я использовал для тестирования с объектами разных типов.

Сапоги: полигонов — 278, вершин — 218

Рисунок 9. Тестовая сцена с сапогами — объектами с низким числом полигонов и вершин

Динозавры: полигонов — 4398, вершин — 4400

Рисунок 10. Тестовая сцена с динозаврами — объектами со средним числом полигонов и вершин

Самолеты: полигонов — 112 074, вершин — 65 946

Рисунок 11. Тестовая сцена с самолетами — объектами с большим числом полигонов и вершин

В таблицах 3, 4 и 5 показано изменение кадровой скорости во всех тестовых сценах.

Таблица 3. Данные, полученные в сцене с сапогами (рис. 9)

Таблица 4. Данные, полученные в сцене с динозаврами (рис. 10)

Таблица 5. Данные, полученные в сцене с самолетами (рис. 11)

Таблица 6. Данные всех тестовых сцен в режиме Fantastic

Эти данные показывают повышение производительности, которого можно добиться с помощью функции layerCullDistances в Unity

В таблице 6 показано, как производительность изменяется при увеличении количества объектов на экране, особенно если это сложные объекты. С точки зрения разработчика игр, правильное использование layerCullDistances позволяет значительно повысить производительность. Например, для маленьких объектов со сложной моделью, расположенных дальше от камеры, можно настроить отрисовку только при достаточном приближении, когда эти объекты уже можно различить. При планировании и создании уровней разработчику следует учитывать сложность моделей и видимость объектов, расположенных на большом расстоянии от камеры. Заблаговременное планирование позволяет добиться лучших результатов при использовании layerCullDistances.

Камера

Я изучил возможности работы с камерой в Unity и ее настройки. Я попробовал выбрать различные параметры, поработал с другими компонентами и дополнениями.

Рисунок 12. Меню Inspector, открывающееся после выбора камеры

При создании новой сцены по умолчанию появляется только один игровой объект камеры под названием Main Camera. Чтобы добавить еще одну камеру, сначала создайте пустой игровой объект: Game Object->Create Empty. Затем выберите этот пустой объект и добавьте компонент камеры: Components->Rendering->Camera.

Камеры в Unity поддерживают широкие возможности настройки, как показано на рис. 12. Вот какие настройки я рассмотрел: Rendering Path и HDR.

Render Path

С помощью параметра Render Path можно указать в Unity, как обрабатывать рендеринг света и теней в игре. В Unity поддерживаются три типа рендеринга, вот они в порядке от наиболее ресурсоемкого к наименее ресурсоемкому: Deferred (отложенная, только в Unity Pro), Forward (заблаговременная) и Vertex Lit (освещение вертексов). В каждом случае тени и свет обрабатываются немного иначе, и для их обработки требуется разный объем ресурсов ЦП и ГП. Важно понимать, для какой платформы и для какого оборудования ведется разработка, чтобы выбрать соответствующий рендерер. Если выбрать рендерер, который не поддерживается графическим адаптером, Unity автоматически переключится на менее ресурсоемкий способ рендеринга.

Рисунок 13. Окно Player Settings Inspector

Настроить значение Rendering Path можно двумя способами. Первый способ:
Edit->Project Settings->Player (рис. 13). Раскрывающийся список Rendering Path находится на вкладке Others Settings. Второй способ: с помощью окна пользовательского интерфейса Camera Inspector (рис. 14). Если выбрать любой параметр, отличный от Use Player Settings, настройки по умолчанию будут заменены, но только для данной камеры. Поэтому можно использовать разные камеры с различными настройками буфера рендеринга для света и теней.

Рисунок 14. Раскрывающийся список при выборе параметра Rendering Path в окне Camera

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

HDR (High Dynamic Range)

При обычном рендеринге значения красного (R), зеленого (G) и синего (B) цветов каждого пикселя представлены десятичным числом, значение которого составляет от 0 до 1. Если ограничить диапазон значений для этих цветов, освещение будет выглядеть нереалистично. Чтобы добиться более естественного освещения, в Unity можно включить расширенный динамический диапазон (HDR). В этом случае значения R, G и B каждого пикселя могут выходить за пределы обычного диапазона. HDR создает буфер изображения, поддерживающий значения вне диапазона от 0 до 1, и выполняет постобработку графических эффектов, таких как размытие и блики. После вычисления эффектов постобработки значения R, G и B в буфере изображения сбрасываются до значений в пределах диапазона от 0 до 1 технологией построения карт оттенков Unity. Если построение карт оттенков не выполняется при использовании HDR, то пиксели могут оказаться за пределами допустимого диапазона, из-за чего некоторые цвета сцены могут выглядеть неправильно по сравнению с остальными.

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

Если сцена обрабатывается с помощью отложенного рендеринга, а камере присвоены графические эффекты, то следует включить HDR. На рис. 15 сравнивается количество вызовов рендеринга для сцены с эффектами и отложенным рендерингом при включенном и отключенном HDR. Без HDR количество вызовов рендерингазначительно выше, чем при использовании HDR, если сцена содержит эффекты. На рис. 15 количество вызовов рендеринга представлено отдельными синими полосками, а высота каждой полоски соответствует величине нагрузки каждого вызова на ГП.

Рисунок 15. Измерение, проведенное с помощью Intel® Graphics Performance Analyzers, показывает, что при отключенном HDR выполняется свыше 2000 вызовов рендеринга, тогда как при включенном HDR — немногим более 900 вызовов рендеринга.

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

Графические эффекты

В Unity Pro содержится ряд графических эффектов, которыеулучшают вид сцены. Чтобы добавить компонент Image Effects после создания проекта, используйте меню Assets->Import Package->Image Effects. После импорта можно добавить эффект к камере двумя способами. Щелкните игровой объект камеры, в окне камеры выберите Add Component, а затем Image Effects. Также можно щелкнуть объект камеры в меню, выбрав Component->Image Effect.

Рассеянное затенение в экранном пространстве — SSAO

Рассеянное затенение в экранном пространстве (SSAO) — это графический эффект в составе пакета Image Effect в Unity Pro. На рис. 16 показано различие между включенным и отключенным SSAO. Изображения выглядят схоже, но производительность существенно различается. У сцены без SSAO кадровая скорость составила 32 кадра в секунду, а с SSAO — 24 кадра в секунду, то есть на 25 % ниже.

Рисунок 16. Сравнение одного и того же уровня с отключенным SSAO (сверху) и с включенным SSAO (снизу)

Будьте осторожны при добавлении графических эффектов, поскольку они могут отрицательно повлиять на производительность. При подготовке этого документа мы тестировали только SSAO, но следует ожидать схожих результатов и при использовании других эффектов.

Исключение заслоненных объектов

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

Заслоняющий объект — объект, помеченный как заслоняющий, выступает в качестве преграды: все загороженные им объекты, помеченные как заслоняемые, не отрисовываются.

Заслоняемый объект — если пометить объект таким образом, он не будет отрисовываться в Unity, если его загораживает заслоняющий объект.

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

Использование и настройка исключения заслоненных объектов задокументированы в Unity. Ссылку на информацию по настройке см. в разделе справочных материалов.


Для демонстрации изменения производительности (в зависимости от исключения заслоненных объектов) я создал сцену, где на переднем плане находится стена, а за ней — объекты со сложными моделями. Я измерил кадровую скорость сцены с исключением заслоненных объектов, а затем без него. На рис. 17 показана сцена с разной кадровой скоростью.

Рисунок 17. На изображении слева исключение заслоненных объектов отключено, отрисовываются все объекты, расположенные за стеной, поэтому кадровая скорость составляет 31 кадр в секунду. На изображении справа исключение заслоненныхобъектов включено, объекты, заслоненные стеной, не отрисовываются, поэтому скорость возросла до 126 кадров в секунду.

Исключение заслоненных объектов должно быть настроено разработчиками вручную. Не следует забывать об исключении заслоненных объектов при проектировании игр, поскольку это снижает требования к оборудованию и позволяет повысить производительность.

Уровень детализации (LOD)

С помощью уровня детализации (LOD) можно присвоить одному игровому объекту несколько моделей разной сложности и переключаться между ними в зависимости от расстояния между объектом и камерой. Это может быть выгодно с точки зрения производительности для сложных игровых объектов, находящихся далеко от камеры. С помощью уровня детализации можно автоматически упрощать модели. Сведения об использовании и настройке уровня детализации см. в документации Unity. Ссылка приведена в разделе справочных материалов.

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

На рис. 18, 19 и 20 показаны три разных уровня сложности моделей с указанием количества полигонов и вершин в каждой модели.

Наилучшее качество — уровень детализации 0

Рисунок 18. Уровень детализации 0. Это наивысший уровень детализации, на котором используются самые сложные модели

Среднее качество — уровень детализации 1

Рисунок 19. Уровень детализации 1. Этот уровень находится на одну ступень ниже по шкале детализации, на нем используются модели средней сложности

Низкое качество — уровень детализации 2

Вершин — 320

08.03.2020, 17:13

Инициализация окна рендеринга в зависимости от операционной системы
Здравствуйте. Скоро надеюсь закончу читать книгу по C++, хочу в графику податься. С англ. у меня.


ПК для игр и рендеринга
Бюджет: 1500-1600р/800-850$ Беларусь, Минск Магазины: socket.by, sli.by Материнская плата.

Сборка Для Рендеринга
Нужно собрать Системник До 30к Для создания анимационных мультиков, чисто для рендеринга, записи.

Мощный ПК для рендеринга
работаю в Sony Vegas 1) Буду брать i7, лучше 1151 говорят, верно? например Intel Core i7-6700K.

#mopsicus

Оптимизация 2D игр на Unity

Этот пост будет периодически дополняться и обновляться.
Обновлено 08.10.2020

На Youtube куча уроков по созданию простейших 2D игр на Unity. Реально, сделать неплохой платформер можно за день, при наличии опыта и готовых ассетов. Но многие начинающие игроделы сделав проект и протестировать его на ПК, с ужасом наблюдают как их творение тормозит на мобильном устройстве.

В мануалах, что встречаются в сети, большинство советов собрано к версии Unity 4.6+, кроме того, они почти все на английском, что для некоторых является преградой. В этом посте, я постарался собрать те моменты, которые помогли мне избавится от лагов на iOS и Android. Но важно понимать — не все можно решить лишь настройками, очень важна и архитектура приложения, и подготовленные текстуры, и знание более оптимальных алгоритмов.

Что нужно предпринять, чтобы повысить производительность, поднять FPS, снизить CPU?

1. Кешируем все!

Все, что будет использоваться больше одного раза лучше закешировать. Операции типа GameObject.Find() или GetComponent() достаточно ресурсозатратны, а если они вызываются где-нибудь в цикле или в Update (), то производительность может упасть.

Не используйте Resources.Load () каждый раз когда нужно в рантайме загрузить что либо, это тоже дорогая операция. Лучше при старте закешировать и работать с кешем. Ну и конечно, объединяйте в префабы.

2. Настройки графики

В Unity есть 6 стандартных пресетов настройки качества графики. Но так как мы говорим про оптимизацию для 2D и для мобильных устройств, то все что выше Simple нет смысла ставить. Конечно, если у вас есть какие-то специфические моменты, частицы, и т. д., то с параметры можно поэкспериментировать найдя оптимальный баланс.

3. Используем FrameRate

По-умолчанию FrameRate равен 30. И зачастую этого бывает достаточно. Но например, при создании UI где есть прокручивающие списки и движущие элементы, может появится дрожание или шлейф. Я это заметил при тестировании на iPhone, поэтому вручную повысил FrameRate. А понижая FrameRate на сценах или игровых меню, где ничего не двигается, можно значительно снизить CPU, а следовательно продлить жизнь батарее устройства. Пользователи не любят когда игра сжирает аккумулятор за час.

4. Атлас текстур

Определенно, нужно упаковывать все свои спрайты в атласы. Для этого есть как встроенный инструмент Sprite Packer, так и продвинутый TexturePacker. Для работы встроенного упаковщика, достаточно задавать теги в настройках импорта, объединяя текстуры и спрайты по смыслу и месту использования.

Таким образом уменьшается количество вызовов отрисовок ваших спрайтов. Проверить как идет отрисовка можно с помощью встроенного инструмента Frame Debugger.

5. Используем пул объектов

GameObject.Instantiate () — очень дорогая операция! Если есть возможность не использовать ее в процессе игры — не используйте. Для большого количества однотипных объектов надо использовать пул объектов. Один раз инициализировав определенное количество, например пуль, они будут использоваться снова и снова, вместо создания и уничтожения каждый раз. Урок по пулу объектов и готовый шаблон, для начала будет достаточно.

6. Меньше Update — больше событий

Метод Update () вызывается каждый кадр, FixedUpdate () в некоторых случаях еще чаще. Если у вас в этих местах происходит много различных проверок и действий, это можно сказаться на производительности. Я использую событийную модель: вместо проверки условия в Update (), когда происходит какое-либо действие, отправляется событие, а в нужном месте это событие «слушается» и обрабатывается в зависимости от переданных параметров. Для этого можно использовать менеджер событий о котором я писал ранее.

7. Выключаем неиспользуемые компоненты

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

8. Настройки билда

Билд под конкретную платформу, тоже можно оптимизировать. Например, если акселерометр не используется в игре, его лучше вообще отключить. Кроме того, я не использую автовыбор графического API, а задаю его сам убирая все остальные, опять же, если вы не используете какие-то специфические функции из OpenGLES 3.0, а так второй версии вполне хватает, она уже давно протестирована. Включаем статичный и динамический батчинг, а для Android многопоточный рендеринг. Для iOS включаем Script Call Optimization в Fast but no Exceptions, но тут момент — если будет какое-то исключение, то игра крашится.

9. Используем Profiler

Не стоит обделять вниманием профайлер. Обязательно протестируйте свою игру и посмотрите, в какие моменты идет максимальная нагрузка. Эти места нужно оптимизировать в первую очередь. Большинство ответов можно найти на stackoverflow.com или форуме Unity, просто загуглив название метода который тратит больше всего ресурсов.

10. Использование материала для UI Image и SpriteRenderer

Если у вас сложный интерфейс и много компонентов, особенно UI Image, то они существенно будут влиять на FPS. Чтобы повысить производительность, улучшить плавность анимаций, можно применить такой хак: там где вы не используете маски, у картинок нужно задать материал Sprites-Default. Если это сделать вместе с маской, то маска не сработает и получите примерно такой варнинг:

Material Sprites-Default doesn’t have _Stencil property

Чтобы убрать эту ошибку нужно немного изменить стандартный шейдер, сделать новый материал и применить его там где есть маска, тогда все сработает. Ссылка на измененный шейдер.
Цена плавности — повышение CPU :(

11. Уменьшаем размер текстур

Отличная утилита которая позволяет снизить потребления памяти для текстур до 3х раз. Как это работает и ссылка на Github, в статье на Хабре.

12. Практическое руководство по оптимизации Unity игр

Подойдет как для 2D, так и для 3D. Много полезной информации которую в документации вряд ли найдешь. Тут и про инструменты, и про опыт. Рассказывает специалист по эксплуатации из Unity Technologies — очень интересно. Узнал про memory profiler и то, что Camera.main не закеширована О_О. Обязательно смотреть всем.

13. Используем оптимизированный код

Снова хочется посоветовать набор оптимизированных скриптов от Leopotam. Коллекции, сериализация, векторы и многое другое. Настоятельное рекомендую, к изучению и использованию.

14. Используем одинаковые материалы

Если на объектах стоят разные материалы, они не будут батчится и будет больше вызовов отрисовки. Соответственно, нужно по возможности использовать как можно меньше разных шейдеров и материалов. Для понимания, как работает начальная оптимизация графики 2D, на Lynda.com есть небольшой курс.

15. Размеры атласов и спрайтов

Для применения сжатия спрайтов на мобильных устройствах нужно использовать атласы с размерами кратными степени 2, т. е. 1024х1024, 2048х2048.

16. Используйте UI Profiler

В Unity 2020 появился UI Profiler! Крутая штука, теперь можно выяснить почему в интерфейсе много вызовов отрисовки, увидеть какие материалы на объектах и всё это оптимизировать. Особенно актуально, если у вас сложные интерфейсы со множеством элементов, которые например, прокручиваются в ScrollRect.

17. Уголок оптимизатора

На сайте Unity появился специальный раздел посвященный оптимизации — Optimization corner. Там и про UI, и профайлеры, и основные ошибки, в общем, стоит ознакомиться.

18. Несколько советов по оптимизации UI

Раннее уже упоминали про Camera.main, но в новой статье описаны ещё несколько интересных особенностей оптимизации UI.

19. Сборник советов от FunCorp

Хорошая статья про оптимизацию UI. Многое уже описано тут, но есть и замечания по новым компонентам, например TextMeshPro.

Пока все. Тут не было про физику, потому что пока я ее не использовал. Возможно, в будущем добавлю. Пишите в комментариях ваши проверенные способы оптимизации для 2D игр под Unity.

Цукерберг рекомендует:  Обучение - Задачи на Python
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих