Как должны быть написаны современные шейдеры OpenGL, чтобы быть совместимыми друг с другом? - PullRequest
6 голосов
/ 12 января 2011

В новых модных версиях OpenGL (3.0 и 4.0 и выше) встроенные атрибуты вершин , такие как gl_Vertex, устарели .«Новый способ» для рендеринга чего-либо - это указать свои собственные атрибуты вершин для позиции, цвета и т. Д., А затем связать эти пользовательские атрибуты с буферами.

Мой вопрос заключается в следующем: как это можно сделать безтесно связывает код рендеринга и шейдер?Если я пишу шейдер, который использует «положение» в качестве позиции вершины, то хост-код, использующий шейдер, должен это знать и передавать данные вершины как «положение».Если я хочу использовать другой шейдер, который был написан для получения данных вершин в "vertex_pos", я должен либо сначала переписать этот шейдер, либо изменить свой код хоста, чтобы вместо этого отправлять данные вершин как "vertex_pos".

Существует ли набор рекомендуемых имен для стандартных атрибутов вершин и фрагментов, которые должны использовать все шейдеры? Или существуют стандарты Balkanized, специфичные для движка, так что шейдер, написанный для одного движка, не может работать на другом безмодификация?Или вообще нет стандартов, так что, как правило, каждому объекту нужен свой собственный код рендеринга, соответствующий его пользовательскому шейдеру?

Ответы [ 3 ]

3 голосов
/ 12 января 2011

Просто продолжайте называть их старыми именами. Если у вас есть основной профиль (т. Е. Нет обратной совместимости), зарезервированные имена более старых спецификаций GLSL освобождены объявлены как недоступные; повторное выделение их для привязки атрибутов вершин. Кажется, чтобы изменить их атрибут доступности. В профиле совместимости эти имена переменных предварительно распределяются и связываются.

Итак, все сводится к следующему: сохранение старого именования в шейдерах является удобным и, похоже, работает с текущими компиляторами GLSL. Если вы хотите быть в безопасности, используйте препроцессор, чтобы перезаписать зарезервированные имена префикса gl_ в самостоятельно выбранный префикс и связать его.

1 голос
/ 12 января 2011

Сначала ответим на ваш вопрос.Я не знаю ни о каком таком стандартном соглашении об именах.

Но ... это сложнее, чем имена атрибутов.Под вопросом скрыто понятие семантики атрибутов.Каждый из входных атрибутов имеет некоторую семантику, которую ожидает каждый шейдер.

И что я узнал из фиксированных имен gl_, так это то, что они недостаточно указывают свою семантику.

  • Какой пробелнаходится gl_Position?(ответ: это полностью зависит от того, что передал хост. Движку не нужно передавать что-то локальное, например, если он уже трансформировал его, так как требовал мирового пространства по разным причинам).
  • gl_TexCoord1 - это координата текстуры или касательная?как насчет его ассортимента?Это закодировано?

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

Более проблематично,даже не очевидно, что конкретный движок (или конкретный актив) будет способен предоставлять конкретные атрибуты, требуемые шейдером, поступающим от другого движка.Что же тогда?

Это все причины, по которым мы получаем балканизированные шейдерные среды.

0 голосов
/ 13 июня 2011

См. Мой вопрос для списка возможных реализаций атрибута / унифицированной семантики.Боюсь, что даже с OpenGL 3.4 эта проблема не будет решена, и вы в значительной степени оставлены на свои собственные устройства, чтобы определить контракт между вашими шейдерами и вашим кодом.

...