Как я делаю игру!
6 пост из серии о создании игры!
Чувак, без обид но с технической частью про рендеринг ты похоже многое напутал ^_^
1) Draw Call это не столько и не только обращение к видюхе (обращаться к видюхе можно по разному), сколько непосредственно вызов функции отрисовать меш после того, как все его свойства уже установлены (в том числе шейдер, все текстуры, параметры, кости и т.п.). Таким образом в принципе можно отрисовать одну модель, без разницы сколько и какие на ней текстуры и анимации всего за один DC. Другой вопрос, что это зависит от количества проходов, т.е. от используемого Rendering Path, количества источников освещения и т.п. В принципе, используя инстансинг вполне можно и не одну сотню анимированных моделек с одинаковым мешем отрендерить всего за один DC. Причина по которой все гонятся за малым DC - они очень дорого стоят на многих платформах (в первую очередь на мобильниках, на Directx9 они тоже довольно дороги, начиная с DirectX10 там говорят стало получше, но я не мерил).
2) По поводу порядка отрисовки - очень сильно сомневаюсь, что юнити использует z-сортинг. Его уже сто лет как никто не использует (за исключением с некоторыми модификациями для полупрозрачных объектов), т.к. в том виде в котором ты описал он во-первых будет давать графические артефакты, а во-вторых будет чудовищно неэффективен с точки зрения производительности (из-за громадного overdraw, т.е. перезаписи пикселей на экране и большого количества множества лишних выполнений пиксельных шейдеров). В современных играх иногда наоборот для оптимизации рендерят все объекты начиная от самых ближних до самых дальних (т.е. порядок как раз таки противоположный тому который ты описал, а для защиты от наложения используют обычный z-буфер).
раскрыть ветку (10)
Спасибо что прочитали мой пост.
Я писал про DrawCalls именно в юнити, в юнити вот такая вот аказия - каждый меш это DC, текстура тоже DC, анимация DC, вот по поводу нормал мап я уже сомневаюсь, что это DC. Оптимизируется путем сшивания всех мешей с одинаковой текстурой и собственно говоря созданием атласа текстур. По поводу сортировки по Z именно так и есть, как не печально. Скрытые объекты все равно дают дравколы если попадают в призму камеры.
раскрыть ветку (9)
Конечно скрытые дальние объекты за более ближними дают лишний DC, просто их пиксели отбрасываются тестом глубины сразу после вершинного шейдера, а дорогой пиксельный шейдер не выполняется - только в этом весь смысл. И это не повод говорить, что они сортируются от дальних к ближним, они могут при этом вообще не сортироваться. Если не веришь - можешь сам посмотреть в своем юнити, там есть пара хороших инструментов для этого - Profiler (при включенном GPU Usage) позволяет посмотреть количество DC, а Frame Debugger позволяет посмотреть даже их последовательнсоть и увидеть как по шагам видюха строит видимое изображение, а значит позволяет просто проверить, безо всяких необоснованных догадок в каком порядке они рендерятся. Так вот у меня в простой тестовой сцене более далекий объект рендерился после того, как отрендерился более близкий. В юнити 5 они доступны даже в бесплатной personal license. В юнити 4.6 они вроде тоже были, но только в Про лицензии (здесь могу ошибаться). Так что спор просто безоснователен - захочешь узнать правду в каком порядке и как юнити рендерит просто возьмешь стандартные инструменты и посмотришь сам (даже если в твоей юнити этого нет, можешь просто скомпилировать игру и запустить ее под графическим отладчиком, но здесь рекомендовать конкретный не буду, так как возможно придется попробовать несколько перед тем, как найдешь тот который работает играми из юнити).
Теперь по поводу DC. Посмотрел, действительно, там за один DC считается что-то странное. Он даже очистку камеры одним цветом или установку активной текстуры считает за один DC, что для меня лично немного странно. Просто я привык что для программистов DirectX/OpenGL один DC означает именно вызов какой-либо функции из семейства Draw*, который непосредственно и отрисовывает геометрию.
раскрыть ветку (8)
Да все считают drawcall как вызовы функций отрисовки. Более того, оно же прямо так и переводится. Если же unity считает drawcall'ом любой чих в сторону видеокарты, то это проблема использующих unity, ибо тогда их количество ничего не значит.
раскрыть ветку (3)
Собственно, я о том же. Но ради справедливости юнити все-же не любой чих записывает в drawcall (я неточно выразился, там под активной текстуры я подразумевал не текстуру для шейдера а текстуру рендертаргета), и в целом число которое он выдает в реальной программе, а не в рафинированном тесте с кубиками, как кажется должно примерно соответсвовать тому, что мы можно ожидать посчитав их в графическом отладчике.
Например простейшую сцену с одним кубиком и forward rendering path юнити 5 рендерит за 4 draw call'а (в других вариантах не меньше):
1) Очистка сцены (почему-то юнити решила делать это через 2 триангла, хотя могло быть и хуже - например для скайбокса ей требуется уже 1.7к трианглов, но я не жалуюсь ^^),
2) Рисование кубика (разумеется без разницы сколько текстур, кроме того, если кубиков несколько они отрисовывались одним drawcall'ом через dynamic batching, но это совсем не то же самое, что и инстансинг).
3-4) Зачем-то два раза подряд вызов RenderTexture.SetActive (без каких-либо подробностей, в профайлере, а в фрейм дебаггере они почему-то не отображаются). Не экспериментировал, но по-видимому это сделано для упрощения наложения постэффектов и худа (хотя они остаются и после того, как с камеры удалить все постэффекты и компонент для gui). Почему именно так, и тем более почему эти вызовы увеличивают счетчик drawcall'ов для меня тайна, которую я по-видимому так никогда не постигну :)
значит. при перевале в 1500 начинается резкое падение FPS на gtx460. Дравколы у юнити как вода в трубе, пока диаметр трубы позволяет бежать потоку все норм, но как только поток воды становится больше чем пропускает труба падает фпс.
раскрыть ветку (1)
Это верно лишь отчасти, при увеличении количества вызовов рисования мы можем уперется еще и в количество выводимых треугольников, в слишком сложные по расчетам материалы, в большое количество обрабатываемых пикселей и многое другое.
http://docs.unity3d.com/ru/current/Manual/OcclusionCulling.h...
цитирую прям из мануала
"Чаще всего сначала отрисовываются объекты, расположенные дальше от камеры и уже поверх них отрисовываются ближние к камере объекты (это называется “overdraw”)."
раскрыть ветку (3)
Я дал тебе указание воспользоваться нормальным инструментарием, поэтому не понимаю что еще ты пытаешься доказать. Сам ведь просил в посте в случае чего поправить, а теперь всеми силами препираешься, когда уже человек десять наверное указали тебе на грубые ошибки. Но тем не менее, продолжим.
Итак, "Чаще всего" != всегда. И тем более это не значит, что юнити как-то специально их сортирует (если бы сортировала, то выгоднее было бы сортировать в обратном порядке, чтобы избежать перерисовки). Чаще всего они отображаются дальше от камеры просто потому, что объем усеченной пирамиды исходящей от камеры увеличивается с расстоянием. Поэтому если объекты в мире распределены более-менее равномерно, то большая вероятность того, что они окажутся загорожены более близкими объектами, а значит их рендеринг оказался напрасным.
Далее, здесь не говорится что это что-то хорошее, наоборот это плохо для производительности и эта часть мануала как раз и описывает как задать PVS, значительно уменьшив количество перерисовок в закрытых помещениях. Таким образом этот короткий абзац никоим образом не доказывает твою правоту о том, что юнити сортирует объекты от дальних к близким и зачем-то рендерит их именно в таком порядке, а ты утверждал в посте именно это.
Более подробно про устройство рендеринга можно прочитать в том же мануале:
(обзорно) http://docs.unity3d.com/ru/current/Manual/RenderingPaths.htm...
(и немного подробнее) http://docs.unity3d.com/ru/current/Manual/Rendering-Tech.htm...
Ничего похожего на сортировку (если не брать полупрозрачные объекты) там нет и в помине, и если ты воспользуешься инструментами, которые я упоминал выше, либо воспользуешься их аналогами ты и сам сможешь в этом убедиться.
раскрыть ветку (2)
Я обязательно посмотрю порядок отрисовки когда доберусь до пк через профайлер как ты говорил, а мои догадки о порядке отрисовки связаны с следующими пунктами
1. Мануал на оклюжен куллинг, там на скринах изображена визуализация сцены по умолчанию. Рендерится все что есть в призме.
2. Зачем тогда нужен оклюжен куллинг?
3. Если я стою перед стеной а за ней карта то у меня овердофига дравколов, хотя я вижу лишь стену
раскрыть ветку (1)
Не вижу в чем противоречие ни по одному из пунктов)
1) Именно так. Если ничего специально не делать, то юнити по умолчанию выполняет только банальный фрустум куллинг.
2) Если коротко, то это позволяет просто не отправлять на отрисовку бОльшую часть геометрии, которая заведомо будет не видна при текущем положении камеры, ведь самый быстрый способ отрендерить что-то что не будет влиять на результирующую картинку - это просто не отправлять это на рендеринг. Оклюжены нужны только для оптимизации.
3) Именно так. Но это не говорит о какой-то специальной сортировке. Юнити не заботятся об этом - объекты рендерятся в "случайном" порядке (не в том смысле что юнити как-то специально их рандомизирует, а в том, что она не заботится об этом порядке). И даже если стена будет нарисована самой первой, это не избавит от лишних DC объектов, которые ей загорожены, потому что даже после рендера стены юнити не будет знать что объект не будет видим, а значит все-равно будет отправлять его на отрисовку, что и означает лишние DC и вероятное снижение производительности.