¿Cómo deben escribirse los sombreadores modernos de OpenGL para que sean compatibles entre sí?

Question

En las nuevas versiones de lujo de OpenGL (3.0 y 4.0 arriba), atributos de vértice incorporados como gl_Vertex están en desuso. La "nueva forma" de representar realmente algo es especificar sus propios atributos de vértice para la posición, el color, etc., y luego vincular estos atributos personalizados a los búferes.

Mi pregunta es esta: ¿cómo se puede hacer esto sin acoplar estrechamente el código de renderizado y el sombreador? Si escribo un sombreador que usa "posición" como posición de vértice, el código de host que usa el sombreador debe saberlo y pasar datos de vértice como "posición". Si deseo usar un sombreador diferente que fue escrito para tomar datos de vértice en "vertex_pos", primero tengo que volver a escribir ese sombreador o modificar mi código de host para enviar datos de vértice como "vertex_pos" en su lugar.

¿Existe un conjunto de nombres de mejores prácticas para los atributos estándar de vértice y fragmento que todos los sombreadores deberían usar? ¿O existen estándares específicos del motor de Balkanized, de modo que un sombreador escrito para un motor no puede funcionar en otro sin modificación? ¿O no hay estándares en absoluto, de modo que, en general, cada objeto necesita su propio código de representación personalizado para que coincida con su sombreador personalizado?

Answer 1

Solo sigue llamándolos con los nombres antiguos. Si tiene un perfil central (es decir, no compatibilidad con versiones anteriores), los nombres reservados de las especificaciones anteriores de GLSL son liberados declarados como no disponibles; redeciéndolos para el enlace de atributos de vértice. Parece cambiar su atributo de disponibilidad. En el perfil de compatibilidad, los nombres de variables se asignan previamente y se vinculan.

Por lo tanto, se reduce a esto: Mantener la antigua denominación en los sombreadores es una conveniencia y parece funcionar con los compiladores actuales de GLSL. Si quiere ir a un lugar seguro, use el preprocesador para reescribir los nombres reservados del prefijo gl_ en un prefijo elegido por el usuario y vincular ese.

Answer 2

Primero, para responder a su pregunta. No estoy al tanto de ninguna convención de nomenclatura estándar.

Pero ... es más complicado que los nombres de atributos. Oculto bajo la pregunta está la noción de semántica de atributos. Cada uno de los atributos de entrada tiene alguna forma de semántica que cada sombreador espera.

Y lo que aprendí de los nombres gl_ fijos es que no especifican su semántica.

• ¿Qué espacio es gl_Position in? (respuesta: depende completamente de lo que haya pasado el host. El motor no tiene que pasar en algo que es espacio local, por ejemplo, si lo transformó ya que requirió espacio mundial por diferentes razones).
• es gl_TexCoord1 una coordenada de textura, ¿o realmente una tangente? ¿Qué hay de su rango? Está codificado?

No está claro si se puede encontrar una nomenclatura específica que realmente resuelva todos estos problemas, pero sería necesario hacer varios motores compatibles.

Más problemático, ni siquiera es obvio que un motor específico (o un activo específico) tenga la capacidad de proporcionar atributos específicos requeridos por un sombreador proveniente de un motor diferente. Entonces que ?

Esas son todas las razones por las que terminamos en entornos de sombreado balcanizados.

Answer 3

Consulte mi question para obtener una lista de posibles implementaciones de atributos/semántica uniforme. Me temo que, incluso con OpenGL 3.4, este problema no se resolverá y prácticamente quedará en sus propios dispositivos para definir un contrato entre sus sombreadores y su código.