¿Cuál es la extensión de archivo correcta para los sombreadores GLSL? [cerrado]

127

Estoy aprendiendo el sombreado de glsl y me he encontrado con diferentes formatos de archivo. He visto personas que dan sus sombreadores .verty .fragextensiones de vértices y fragmentos . Pero también he visto .vshy .fshextensiones, e incluso ambos shaders juntos en un solo .glslarchivo. Entonces, me pregunto si hay un formato de archivo estándar, o ¿cuál es el formato 'correcto'?

opengl glsl shader

— Samssonart
fuente

10

Hasta donde yo sé, no tienen extensiones "correctas", ya que OpenGL no las leerá del disco de todos modos.

— zneak

2

Algunas personas los llaman .vs y .fs (y .gs) para hacer explícito lo que hay dentro. Pero como dijo Zneak, realmente no importa, no hay nada "correcto".

— Damon

11

GEdit utiliza .glslvy .glslfal elegir resaltado de sintaxis. Ese es el único lugar que he visto donde importa.

— Piotr Praszmo

90

No existe una extensión de archivo estándar para sombreadores GLSL. Los más comunes son probablemente .verty .frag, como estas son las extensiones que 3D Labs utilizó en algunas de sus herramientas. Pero eso es todo para cualquier forma de extensión estándar.

— Nicol Bolas
fuente

21

No creo que .vert | .frag sean buenos nombres de extensión para sombreadores. La extensión es algo que identifica la clase general de un archivo. Probablemente deberían haberlos llamado vertex.glsl y fragment.glsl.

— Autodidacta

55

También me sorprendió, pero ¿no hay una ligera diferencia en la sintaxis entre los sombreadores de vértices y fragmentos, @SandeepDatta? De la misma manera que .h y .c podrían compartir mucho en común, pero se usan de diferentes maneras.

— Joseph Humfrey

77

@SandeepDatta .hppvs .cpp? .hvs .c? Hay más sintaxis y diferencias semánticas entre los sombreadores de vértices y fragmentos que entre el encabezado C / C ++ y los archivos fuente.

— Miles Rout

1

@MilesRout Ni siquiera para hablar de .cc

42

GLSLang, también conocido como GLSL Reference Parser o Reference Compiler , es una de las herramientas desarrolladas por 3Dlabs . Está listado como una herramienta SDK en opengl.org y khronos.org. El archivo README enumera las extensiones de archivo que espera para los archivos de sombreado: .vert(vértice), .frag(fragmento), .tesc(control de teselación), .tese(evaluación de teselación), .geom(geometría), .comp(cálculo).

— TachyonVortex

93

No hay extensión oficial en la especificación. OpenGL no maneja los sombreadores de carga de los archivos; simplemente pasa el código del sombreador como una cadena, por lo que no hay un formato de archivo específico.

Sin embargo, glslang , el compilador / validador GLSL de referencia de Khronos, utiliza las siguientes extensiones para determinar para qué tipo de sombreador es el archivo:

.vert - un sombreador de vértices

.tesc - un sombreador de control de teselación

.tese - un sombreador de evaluación de teselación

.geom - un sombreador de geometría

.frag - un sombreador de fragmentos

.comp - un sombreador de cálculo

— Coronel treinta y dos
fuente

18

Identificar el tipo de archivo por extensión es algo específico de Windows. Todos los demás sistemas operativos utilizan enfoques diferentes: MacOS X almacena el tipo de archivo en una estructura de metadatos especial en las entradas del sistema de archivos. La mayoría de los * nixes identifican archivos al probar su estructura interna contra una base de datos de "bytes mágicos" conocidos; sin embargo, los editores de texto usan la extensión.

De todos modos, las fuentes GLSL son como cualquier otro archivo fuente del programa: texto plano, y ese es su tipo de archivo.

La extensión que puede elegir como desee. Yo uso los siguientes nombres:

ts.glsl
gs.glsl
vs.glsl
fs.glsl

pero esa es mi elección y técnicamente mis programas ni siquiera aplican ningún esquema de nombres o extensiones. El nombre es para que los humanos lean y sepan lo que contiene; tener una extensión principal común requiere que tenga una regla de resaltado de sintaxis para un solo conjunto de extensiones de archivo.

— datenwolf
fuente

55

Voto negativo porque OS X ha estado utilizando principalmente la extensión de archivo durante años.

— Frederik Slijkerman

66

@FrederikSlijkerman: No, no lo hace. MacOS X es un Unix en su núcleo y las extensiones de archivo nunca se usaron allí para identificar cosas. Sí, los tipos estándar obtienen extensiones de archivo estándar, pero eso es solo una cuestión de legibilidad humana. Quizás el Finder puede confiar en extensiones de archivo como heurísticas para algunos tipos. Pero si puede identificar un archivo únicamente por su encabezado o algunos bytes mágicos, lo usará. Como lo hace cualquier sistema basado en Unix.

— datenwolf

3

+1 Los nombro como effect-name -fs.glsl o effect-name -vs.glsl.

— legends2k

9

Me doy cuenta de que llego dos años tarde al argumento de OS X, pero sentí que debería tirar mis dos centavos. Todo lo que está por encima de la capa UNIX usa LaunchServices para determinar las asociaciones de archivos. Cada archivo tiene un identificador de tipo com.stackoverflow.file, que se almacena como metadatos. LaunchServices intenta adivinarlo desde el tipo MIME primero, si existe la entrada de metadatos. Si no, buscará la extensión. Si no puede coincidir, buscará un código de creador HFS. Si no hay ninguno, se rinde. LaunchServices nunca intenta identificar un archivo por su encabezado o bytes mágicos.

— zneak

2

Esto significa que la forma más común de determinar el tipo de archivo en OS X es su extensión. Sin embargo, esto es solo con el propósito de identificar qué aplicación se debe usar para abrir qué archivo. Una vez que la aplicación abre el archivo, puede decidir por sí misma qué quiere hacer con él, independientemente de si la extensión es correcta para el tipo de contenido.

— zneak

7

Como otros han mencionado, no hay una respuesta correcta en el sentido más estricto. Vale la pena mencionar que Sublime (confirmado para v2 y v3) también espera .vert y .frag para resaltar y validar la sintaxis.

— Weavermount
fuente

2

Creo que esto solo es cierto si tiene una biblioteca GLSL instalada en Sublime, por ejemplo, github.com/WebGLTools/GL-Shader-Validator : mi Sublime predeterminado no reconoce las extensiones.

— Aire

La biblioteca que vinculaste es, con mucho, la más popular (¿y posiblemente la única?) GLSL lib para sublime, y llamé lo que eso espera como lo que sublime espera. Si lo llamas una exageración, me declararé culpable. Pero sí, tiene razón al menos en lo sublime, ya que un editor de texto obediente abrirá cualquier documento de texto mientras ignora las extensiones que no conoce.

— Weavermount

1

A partir de hoy sublime-GLSL ( github.com/euler0/sublime-glsl ) es el complemento más popular GLSL y acepta el siguiente conjunto de extensiones: vs, fs, gs, vsh, fsh, gsh, vshader, fshader, gshader, vert, frag, geom, tesc, tese, comp, glsl. Así que hay una variedad para elegir :)

— F Lekschas

-1

Hay dos formas de escribir sombreadores.

Puede almacenar el sombreador de vértices y el contenido del sombreador de fragmentos en una char *variable y compilar, vincular y adjuntar el sombreador a un programa.

Otra forma es escribir el archivo separado de vértices y fragmentos de sombreador con cualquier extensión que desee y leerlo para compilar, vincular y adjuntar el sombreador al programa.

Por lo tanto, la convención de nomenclatura, como .vert / .frag, .vsdr / .fsdr, etc., son válidas siempre que sepa cómo leerla ...

— usuario2439483
fuente

-2

Como ya ha sido cubierto por múltiples respuestas, realmente no hay un estándar; depende de usted adoptar el enfoque que sea más útil para usted.

Puedo ver el beneficio de usar extensiones de sombreador específicas de tipo, pero mi preferencia es usar la extensión .glsl para todos los tipos de sombreador, ya que solo necesita definir cómo Shell utiliza el archivo una vez.

Del mismo modo, esta también es una buena opción si edita sus archivos de sombreador en Notepad ++, ya que puede configurarlo para aplicar automáticamente el resaltado de sintaxis específico del idioma a todos sus archivos de sombreador especificando solo una extensión de archivo.

La desventaja de este enfoque es que debe utilizar su propia convención de nomenclatura para determinar el tipo de sombreador por su nombre de archivo, pero, para mí, los beneficios superan el costo.

— Luis
fuente