Comments 14
Если вам нужна глубина в сцене, то забудьте о батчинге.
Вот за это я и не люблю Unity (и все подобные комбаины «для простого старта»). Нет никакой проблемы батчить изометрию. Знаю проект, где вообще за 2 draw call'а сцена на 10 000 изометрических спрайтов с анимацией рисуется. Там безумное перекрытие объектов друг другом (over draw > 70). Но это всё оптимизируется и выпиливается, в итоге нет никакого over draw, нет тысяч вызовов. Одна проблема — этот подход требует скилов и очень гибкого движка. В случае с юнити единственный выход — уйти в C++, получить контекст и нарисовать всё самому. Но если так рисовать всю игру, то зачем вообще фреймвёрк?
На самом деле любым инструментом нужно уметь пользоваться. Как и С++/OpenGL, так и любой готовый движок требует определённого опыта. Хорошим контрпримером с «забудьте о батчинге» является игра Mushroom 11, где в огромной сцене с глубиной отрисовки, большим количеством активных объектов количество DC не превышает 10-11. Доклад можно посмотреть тут https://youtu.be/bYqI77dteYk?t=2734 (залинкованное время — скриншот статистики отрисовки).
Это не значит что любой только начавший что-то делать в движке сможет без всяких проблем достичь такого же результата — нужен опыт, контекст, и базовые знания по предметной области.
Это не значит что любой только начавший что-то делать в движке сможет без всяких проблем достичь такого же результата — нужен опыт, контекст, и базовые знания по предметной области.
Вот демка того самого проекта о котором говорит bfDeveloper Я пишу вообще под webGL.
Да приходится атласы в рантайме собирать из того что есть на сцене. Тут по полной используется z сортировка для экономии на overdraw т.к. всё рисуется с альфа блендингом. Два дроколла потому что вся сцена сначала рисуется спереди на зад с альфаотсечением, и при этом заполняется depth буфер, а потом уже с блендингом сзади на перёд.
Мобилам всё равно недоступен такой уровень количества ассетов на сцене, т.к. у них early z culling не работает. Основная проблема это запись в экранный буфер, большое overdraw не держат ни мобилки ни даже встроенные intel видео карты.
Краткая сводка:
252 типа ассетов на сцене, всего более 7000 типов может быть на участке игрока
9000 инстансов этих ассетов на сцене, рандомно сортированы, худший вариант для батчера
альфа блендинг на каждом ассете
каждый ассет играет рандомную анимацию из тех что у него есть, в своей, рандомной позиции анимации.
2 draw calls per frame (deferred alpha blending).
Полностью gpu анимация. Никакого аплоада буферов на рендере вообще. Только текущее время в юниформ и два дроколла, с установкой ещё одного юниформа для того чтоб сообщить шейдеру альфу отрезать или блендить.
Да приходится атласы в рантайме собирать из того что есть на сцене. Тут по полной используется z сортировка для экономии на overdraw т.к. всё рисуется с альфа блендингом. Два дроколла потому что вся сцена сначала рисуется спереди на зад с альфаотсечением, и при этом заполняется depth буфер, а потом уже с блендингом сзади на перёд.
Мобилам всё равно недоступен такой уровень количества ассетов на сцене, т.к. у них early z culling не работает. Основная проблема это запись в экранный буфер, большое overdraw не держат ни мобилки ни даже встроенные intel видео карты.
Краткая сводка:
252 типа ассетов на сцене, всего более 7000 типов может быть на участке игрока
9000 инстансов этих ассетов на сцене, рандомно сортированы, худший вариант для батчера
альфа блендинг на каждом ассете
каждый ассет играет рандомную анимацию из тех что у него есть, в своей, рандомной позиции анимации.
2 draw calls per frame (deferred alpha blending).
Полностью gpu анимация. Никакого аплоада буферов на рендере вообще. Только текущее время в юниформ и два дроколла, с установкой ещё одного юниформа для того чтоб сообщить шейдеру альфу отрезать или блендить.
Очень круто! А почему в центре игрового поля моргает дерево?
У дерева в кадрах анимации лежит анимация его срубания, оно при каждом ударе берёт следующий кадр. Т.е. в игре анимация деревьев всегда на паузе и тикает при ударах топором. Тут в демке она просто играется, потому кажется что моргает. Это уже к бизнес логике а не к движку относится, а до бизнес логики я ещё не дошёл в портировании. И да, фрутовые и декоративные деревья не рубят, потому они не мограют. Срубание подразумевают только дикие деревья, там из два видно. Если присмотреться даже видно как оно срубается.
Ещё раз перечитал статью. Изучайте не фреймвёрк а технологии. И профайлер советую не только юнитёвый, но и NVIDIA Nsight и Intel Graphics Performance Analyzer.
Когда читаю такие статьи думаю, что Unity это такой молоток с пропеллером и зубочисткой, которым не только все гвозди пытаются забить, а еще и шурупы, и дома убрать.
Если вы предпочли 2D вместо 3D, потому что испугались количества треугольников, то не думайте, что при использовании спрайтов с альфа-каналом треугольников будет сильно меньше. Спрайты с альфа-каналом, то есть с неровным контуром, тоже могут использовать множество треугольников и вершин.
Потому что при сложной альфа-маске спрайта гораздо производительнее будет триангулировать его видимую часть, оставив альфатесту только самые сложные места. Отрисовать сотню другую лишних треугольников и отсечь невидимое/видимое по z-тесту намного лучше, чем альфа-тест, ломающий параллелизм шейдеров.
Всегда используйте только атласы спрайтов PoT (Power of Two)
Unity здесь не причем. Иногда полезно узнать азы программирования компьютерной графики до знакомства с высокоуровневыми движками.
Естественно, вы хотите, чтобы игровая логика выполнялась в FixedUpdate (потому что в таком случае она будет надёжной и детерминированной), но анимации выполняются в простом Update. Уже замечаете грядущую проблему?
Если это такая проблема, она решается как минимум двумя способами: Update + Time.deltaTime. Либо переносом логики из события анимации в FixedUpdate, в этом случае в событии просто выставляем нужное состояние, а обрабатываем его в FixedUpdate.
Создавайте пулы объектов. Если вы стараетесь снизить нагрузку на процессор, куча вызовов Instantiate и Destroy НЕ будет вашими лучшими друзьями!
И опять же Unity не при чем. Даже в случае с ЯП без сборщика мусора new/delete слишком затратно в игровом цикле. В NASA, например, программа должна аллоцировать всю требуемую память на старте и не требовать аллокации во время работы.
Вам ведь нравится физика Unity? Жаль, что гравитация не согласована и её невозможно согласовать с симулированной вертикальной осью вашего игрового мира
Рисовать изометрию с пререндеренными спрайтами и хотеть 3d-физику? Месье знает толк…
Итак, он готовится к удару, и кадр X должен нанести урон, воспроизвести звук удара и т.д.<...> Естественно, вы хотите, чтобы игровая логика выполнялась в FixedUpdate (потому что в таком случае она будет надёжной и детерминированной), но анимации выполняются в простом Update.
Была схожая задача по синхронизации вращения многоствольной пушки и задержки выстрела — чтобы выстрел производился только когда ствол находится вверху. Я просто на каждый выстрел делал Invoke следующего, с задержкой, соответствующей времени поворота, а вращал вообще в отдельном скрипте. Если не нравится Invoke, можно создавать корунтину с WaitForSeconds.
Есть какие-то недостатки такого подхода?
Invoke медленный, так как использует рефлексию, имя метода задается строкой, что чревато проблемами при рефакторинге. А так — вполне себе нормальное решение. Корутины чуть получше будут, хотя не уверен, что и это достаточно производительное решение. Впрочем, я не настолько хорош в Unity, поэтому нужны более компетентные люди
А так — вполне себе нормальное решение.Если вы не хотите билдить под WebGL, конечно.
Если не трудно, не могли бы рассказать, прочему возникнут проблемы под WebGL?
Getting started with WebGL development.
WebGL не умеет в рефлексию и System.Threading.
WebGL не умеет в рефлексию и System.Threading.
А можете скинуть примеры ассетов, которые сэкономили вам время, можно в ЛС
Sign up to leave a comment.
Сложности при создании изометрической игры в Unity