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

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

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

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

Выполняется ли рисование спереди-назад, необходимое для оптимизации рендеринга?

Ответ 1

Как только примитив растеризуется, его значение z можно использовать для выполнения "раннего z-убийства", которое пропускает запуск шейдера фрагмента. Это главная причина, чтобы сделать фронт-к-назад. Совет. Когда у вас есть прозрачные (альфа-текстурированные) полигоны, вы должны визуализировать назад.

Спецификация OpenGL определяет конечный автомат и не указывает, в каком порядке выполняется рендеринг, только чтобы результаты были правильными (в пределах определенных допусков).

Изменить для ясности: то, что я пытаюсь сказать выше, заключается в том, что аппаратное обеспечение может делать все, что захочет, до тех пор, пока примитивы появятся, чтобы обработать в порядке

Однако большинство графических процессоров представляют собой потоковые процессоры, а их драйверы OpenGL не группируют "геометрию", за исключением, пожалуй, из соображений производительности (минимальный размер DMA и т.д.). Если вы подаете многоугольник A, за которым следует полигон B, то они поступают в конвейер один за другим и обрабатываются независимо (по большей части) друг от друга. Если есть достаточное количество полисов между A и B, тогда хороший шанс A завершается до B, а если B находится за A, его фрагменты будут отброшены через "раннее z kill".

Редактирование для ясности: то, что я пытаюсь сказать выше, состоит в том, что, поскольку hw не "загружает" геометрию, он не может автоматически выполнять привязку "вперед-назад".

Ответ 2

Вы путаете несколько концепций здесь. Нет необходимости переупорядочивать вершины (*). Но вы должны нарисовать объекты, которые непрозрачны спереди назад. Это позволяет так называемое "раннее отклонение z" на графическом процессоре. Если графический процессор знает, что пиксель не будет затенен тестом z, ему не нужно запускать шейдер, делать выборки текстур и т.д. Это относится к объектам в вызовах рисования, но не к отдельным объектам.

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

Прозрачная геометрия должна быть обращена вперед, конечно.

(*) = вершины могут быть переупорядочены для лучшей производительности. Но выполнение раннего z гораздо важнее и сделано для каждого объекта.