За статью, конечно, плюсик, на хабре статьи по рендерингу бывают очень редко. Немного критики:
Мир рендерится один раз – геометрический шейдер автоматически выбирает нужную сторону для записи
Я бы поспорил с этим высказыванием. Геометрический шейдер ничего не выбирает, вы просто клонируете геометрию 6 раз, а каждая копия попадает в свой surface cubemap'а. Затем лишняя (для каждого surface своя лишняя) геометрия отсекается и, вуаля получили то, что хотели, как бы за дешево :) По большому счету, все отличие от олдскульного варианта в том, что цикл от 1 до 6 выполняется на GPU. Справедливости ради замечу, что если сцена будет высокополигональна, то теоретически копирование в геометрическом шейдере может по быстродействию уступить циклу на стороне CPU, где мы можем отсекать лишнюю геометрию по frustum'у или придумать что-либо еще.
взамен эмита новой геометрии – можно использовать инстансинг, выбирая нужный RTIndex исходя из InstanceID. Да, можно, но я получил заметный проигрыш в перфомансе. В подробности, почему так получилось – не вдавался. Оказалось куда проще заимитить новые треугольники, чем использовать полученные от инстансинга.
Это как-то не серьезно :) ИМХО надо или разобраться в чем дело, или не писать про это :)
О мотивации Apple я могу только догадываться, как вы понимаете. Думаю немаловажным фактором было наличие «собственного» языка, это в духе компании. Для себя я не нашел в этом языке фич, которых бы мне сильно не хватало в других языках. Да, в Metal Shading Language есть перегрузка функций и шаблоны, удобно, но не более того. Была попытка сблизить программы GPGPU и шейдеры синтаксически, удобно, но не революция.
Если уж говорить о моем сугубо личном мнении, языку шейдеров давно нужна стандартизация, один язык, который бы использовался везде.
Спасибо, за конструктивное замечание, убедили) Это обучающий материал, поэтому мнение обучаемых особенно ценно. В следующей серии, если она будет, обязательно исправлю это.
Я не к тому, что Metal загнется (Apple создали технологию, которую будут продавать еще долго). С выходом Direct3D 12 технологию Metal, возможно, будет с чем сравнивать на мобильных платформах
Те преимущества, что мне показались значимыми, я обозначил во «Вступлении». Из них я бы особенно выделил хорошую поддержку многопоточности. Мне доводилось реализовывать многопоточный рендеринг на Direct3D 11 API при помощи deferred-контекста, так что сравнивать есть с чем) Вопрос, что будет с Metal, когда выйдет Direct3D 12, в котором обещают схожую гибкость, но пока его нет, работаем с тем, что имеем.
Спасибо за отклик! Да, специально не использовал жесты, для управления камерой это оказалось даже проще. Да, заменить можно, но в данном конкретном случае использование недвоичного семафора мне показалось более уместным. dispatch_group я бы скорей использовал в ситуации, когда надо синхронизировать разнородные таски.
Несмотря на то, что dispatch_semaphore_t — указатель, работаем мы с ним как с объектом (я к тому, что указатель это его внутренняя организация). __block здесь носит информационный характер и говорит о том, что объект будет изменяться внутри блока.
Можно использовать и нотификации, более того, так и было в одной из демок Apple)) Так как контроллер у нас всегда один, я решил, что перегружать код контроллера подпиской/отпиской в центре нотификаций — лишнее
Спасибо за статью, легкий стиль изложения, безусловно, импонирует. Однако, показалось, что математических обоснований маловато. Барицентрические координаты затронуты только в обсуждении выше, проекция 3D-модели на 2D есть, но про матрицу проекции упоминаний нет. Предполагается, что у студентов уже есть необходимый бэкграунд?
По идее, качественно подготовленная трёхмерная текстура меха и должна такую маску создавать. Я в силу своих скромных художественных способностей, использовал наилучшую их тех, что смог получить. Я не берусь утверждать, что освещение не «пластиковое», но, на мой вкус, оно определённо выглядит более правдоподобно, чем стандартный еще более пластиковый Блинн-Фонг.
Насчет материалов, кстати, тоже интересно. Deferred shading имеет еще один не упомянутый недостаток, он усложняет работу с материалами, побуждая делать дополнительные приседания, чтобы не рисовать всю сцену однотипно. На вашей схеме DS я не нашел Material ID, значит всё различие в материалах сводится к набору параметров, «запеченных» в текстуры на этапе формирования G-буферов. В таком случае не совсем понятно, как вам поможет переделка системы материалов Ogre, ну да ладно. Спасибо за ответ, light-shafts в демке классно получились :)
Спасибо за рассказ. Что-то уже планируете предпринять для оптимизации рендеринга (раз уж речь про графику)? Запустил демку — 7фпс (1024x768, AMD Phenom II X4 970, 16Gb RAM, AMD Radeon HD 7700), и я так понимаю это без физики, AI, игровой логики.
Я не знаю особенностей вашей игры, но если вы сделаете так, как описали, то получите на виде сверху дополнительные тени позади всех объектов, на которые смотрит игрок. Например, игрок стоит перед другим игровым персонажем, а за последним длиннющая тень (действительно, игрок же не видит этот участок пространства). Рискну предположить, что нужно не это, а просто показать поле зрения игрока. В этом случае я бы в постпроцессинге проецировал пирамиду зрения игрока на плоскость зрения камеры. В самом простом случае можно подготовить текстуру с белым усеченным треугольником на черном фоне, и накладывать ее как декаль на всю сцену. Если предполагается, что на виде сверху мы видим комнаты без крыш (как в старых рпг) и внутри них должно быть темно, даже если мы смотрим куда-то в их направлении, то тут уже отдельная история. В общем, все зависит от требований.
Я бы поспорил с этим высказыванием. Геометрический шейдер ничего не выбирает, вы просто клонируете геометрию 6 раз, а каждая копия попадает в свой surface cubemap'а. Затем лишняя (для каждого surface своя лишняя) геометрия отсекается и, вуаля получили то, что хотели, как бы за дешево :) По большому счету, все отличие от олдскульного варианта в том, что цикл от 1 до 6 выполняется на GPU. Справедливости ради замечу, что если сцена будет высокополигональна, то теоретически копирование в геометрическом шейдере может по быстродействию уступить циклу на стороне CPU, где мы можем отсекать лишнюю геометрию по frustum'у или придумать что-либо еще.
Это как-то не серьезно :) ИМХО надо или разобраться в чем дело, или не писать про это :)
В общем, спасибо за статью. Жду следующих!
Если уж говорить о моем сугубо личном мнении, языку шейдеров давно нужна стандартизация, один язык, который бы использовался везде.
Несмотря на то, что dispatch_semaphore_t — указатель, работаем мы с ним как с объектом (я к тому, что указатель это его внутренняя организация). __block здесь носит информационный характер и говорит о том, что объект будет изменяться внутри блока.
Можно использовать и нотификации, более того, так и было в одной из демок Apple)) Так как контроллер у нас всегда один, я решил, что перегружать код контроллера подпиской/отпиской в центре нотификаций — лишнее