Возможен ли отложенный рендеринг / затенение в OpenGL ES 2.0?

Я спрашивал об этом в StackOverflow , но здесь может быть больше смысла:

Кто-нибудь реализовал отложенный рендеринг / шейдинг в OpenGL ES 2.0? Он не поддерживает MRT, поэтому при наличии только одного цветового буфера это не то, что может быть реализовано «обычным» образом.

В частности, я исследую на iPad, iPhone4 (maaaybe iPhone 3gs) и Android. В приложении GLESView на iPad / iPhone4 / iPhone3gs присутствует расширение GL_OES_RGB8_RGBA8, и я пока что не слишком подробно изучил его, но с 8бит / канал эта идея интересна: http://www.gamedev.net/topic/ 562138-OpenGL-ES-20-и отсроченные-затенение /

Есть еще идеи? Это даже стоит делать, с точки зрения производительности?

Да, это возможно. Тем не менее, это не особенно стоит.

Во-первых, если у вас нет доступа к расширению NV_draw_buffers (как следует из названия, оно доступно только для NVIDIA. Поэтому, если вы не работаете в Tegra, у вас его нет), объекты кадрового буфера в ES 2.0 могут отображать только одно изображение вовремя. Таким образом, чтобы сгенерировать ваши G-буферы, вам нужно будет визуализировать вашу сцену несколько раз, тем самым устраняя одно из преимуществ отложенного рендеринга.

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

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

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

На iPhone 4 и iPad 1, Fillrate просто смешно. Единственное устройство IOS с хорошей скоростью заполнения - это iPad 2, но я сомневаюсь, что этого достаточно ... На андроиде только устройства Tegra имеют GL_NV_draw_buffers для использования MRT, но скорость заполнения тоже очень низкая. Мали 400, кажется, имеет лучшую скорость заполнения. Если вы хотите плакать, попробуйте заполнить цветной прямоугольник в полноэкранном разрешении 4 раза ... Многие устройства не могут сделать это 60 кадров в секунду.

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

Есть несколько примеров в WebGL (тот же API), так что это не ограничение API.

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

Я бы пошел на следующий формат GBuffer:

• Повторно используйте буфер глубины для прохода освещения, не зная, насколько широко это поддерживается на мобильных устройствах, но это бесплатная текстура глубины.
• Единственную текстуру GBuffer, внутри которой я бы сохранил: Normal U, Normal V, Param 0, Param 1. Lambert-Azimuthal кодирование выглядит очень хорошо для нормалей и сжимает их до двух компонентов, относительно дешево для кодирования и декодирования.
• Два параметра для переменных освещения - это много, можно использовать один в качестве перечисления для нескольких функций освещения, если оборудование хорошо справляется с динамическим ветвлением.

Отложенное освещение похоже на отложенное отображение, за исключением того, что вы визуализируете сцену дважды:

1. Рендеринг глубины геометрии, нормалей и параметров освещения в GBuffer.
2. Render Lights в буфер накопления.
3. Визуализируйте геометрию с помощью шейдеров материалов, комбинируйте ваше освещение и здесь. Если вам хорошо работать с обратными операторами уравнений освещения, вы можете сделать ОЧЕНЬ крутые вещи с этим шагом.
4. Сделайте любую постобработку, которую вы можете себе позволить, не забудьте злоупотребить глубиной и нормальными текстурами до смерти здесь для эффективности.

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

Однако наиболее важной частью будет использование буфера глубины трафарета в полной мере, убедитесь, что вы не отрисовываете какой-либо код освещения там, где он не нужен. Я бы даже зашел так далеко, чтобы добавить некоторые операторы отбрасывания в фрагментные шейдеры на условиях, которые снизят видимость света ниже отображаемого диапазона устройства (1e-3 обычно является безопасным отсечением).

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

Этот метод используется для уменьшения размера G-буфера, так как требуется меньше атрибутов. Это также дает вам преимущество в том, что G-Buffer и карта пространства экрана могут иметь более низкое разрешение, чем экран.

Я реализовал строгий рендерер, основанный на GLES 2.0 (хотя и экспериментальный), и мне удалось свести G-буфер к одной RGBA-текстуре (да, я использовал texture2D вместо рендеринга буфера). Он содержал карту нормалей экранного пространства + буфер глубины в альфа-канале (насколько я помню, был сжат с использованием логарифма).

Атрибуты положения (называемые здесь миром ) можно вычислить во время прохода освещения, используя тот факт, что в перспективной проекции .xy делится на .z , так что:

Я приблизил xy атрибута позиции, выполнив:

Примечание: мне пришлось делать дальнейшие настройки в зависимости от настроек матрицы проекции.

Также стоит отметить, что я был в состоянии опустить компонент .z нормальных векторов, так как я мог восстановить .z из .xy, поскольку вектор нормализован так, чтобы:

Используя эту технику, я смог освободить другой канал в моем G-буфере RGBA и использовал его для хранения зеркальной карты экранного пространства (или, если хотите, глянца).

Да, это абсолютно возможно. Частота заполнения не является такой проблемой, потому что мобильные графические чипы предназначены для работы с экранами с очень высоким разрешением. Фактически, отсроченный рендеринг помогает в этом, потому что ваши расчеты освещения не зависят от сложности сцены, поэтому перерисовка не вызывает замедления. Вот моя реализация для iPad четвертого поколения: http://www.youtube.com/watch?v=K4X1oF6b4V8

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

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

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