Qual è l'estensione di file corretta per gli shader GLSL? [chiuso]


127

Sto imparando glsl shading e ho trovato diversi formati di file. Ho visto persone dare il loro vertice e frammento shader .verted .fragestensioni. Ma ho anche visto .vshed .fshestensioni e persino entrambi gli shader in un unico .glslfile. Quindi mi chiedo se esiste un formato di file standard o in che modo è "corretto"?


10
Per quanto ne so, non hanno estensioni "corrette", poiché OpenGL non le legge comunque dal disco.
zneak,

2
Alcune persone li chiamano .vs e .fs (e .gs) per rendere esplicito cosa c'è dentro. Ma come ha detto zneak, non importa davvero, non esiste una cosa "corretta".
Damon,

11
GEdit usa .glslve .glslfquando sceglie l'evidenziazione della sintassi. Questo è l'unico posto che ho visto dove conta.
Piotr Praszmo,

Risposte:


90

Non esiste un'estensione di file standard per gli shader GLSL. Le più comuni sono probabilmente .verte .frag, poiché si tratta delle estensioni utilizzate da 3D Labs in alcuni dei loro strumenti. Ma questo è tutto per qualsiasi forma di estensione standard.


21
Non credo che .vert | .frag siano buoni nomi di estensione per shader. L'estensione è qualcosa che identifica la classe generale di un file. Probabilmente avrebbero dovuto chiamarli vertex.glsl e fragment.glsl.
Autodidatta,

5
Sono stato anche sorpreso, ma non c'è una leggera differenza nella sintassi tra vertici e frammenti di shader, @SandeepDatta? Allo stesso modo che .h e .c potrebbero condividere molto in comune, ma sono usati in modi diversi.
Joseph Humfrey

7
@SandeepDatta .hppvs. .cpp? .hvs. .c? Esistono più sintassi e differenze semantiche tra shader di vertici e frammenti rispetto a quelli tra intestazione C / C ++ e file di origine.
Miles Rout

1
@MilesRout Neanche per parlare di .cc

42
GLSLang, noto anche come Parser di riferimento GLSL o compilatore di riferimento , è uno degli strumenti sviluppati da 3Dlabs . È elencato come uno strumento SDK su opengl.org e khronos.org. Il file README elenca le estensioni dei file che si aspetta dai file shader: .vert(vertice), .frag(frammento), .tesc(controllo di tassellatura), .tese(valutazione di tassellatura), .geom(geometria), .comp(calcolo).
TachyonVortex,

93

Non ci sono estensioni ufficiali nelle specifiche. OpenGL non gestisce il caricamento di shader da file; devi solo inserire il codice shader come stringa, quindi non esiste un formato file specifico.

Tuttavia, glslang , compilatore / validatore GLSL di riferimento di Khronos, utilizza le seguenti estensioni per determinare a quale tipo di shader è destinato il file:

  • .vert - uno shader di vertice
  • .tesc - uno shader di controllo della tassellatura
  • .tese - uno shader di valutazione di tassellatura
  • .geom - uno shader di geometria
  • .frag - uno shader di frammenti
  • .comp - uno shader di calcolo

18

L'identificazione del tipo di file per estensione è una cosa specifica di Windows. Tutti gli altri sistemi operativi utilizzano approcci diversi: MacOS X memorizza il tipo di file in una struttura di metadati speciale nelle voci del file system. La maggior parte dei * nix identifica i file testando la loro struttura interna su un database di "byte magici" noti; tuttavia gli editor di testo usano l'estensione.

Ad ogni modo, le fonti GLSL sono esattamente come qualsiasi altro file sorgente del programma: testo semplice e questo è il loro tipo di file.

L'estensione che puoi scegliere come desideri. Uso la seguente denominazione:

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

ma questa è la mia scelta e tecnicamente i miei programmi non applicano nemmeno alcun schema di denominazione o estensione. Il nome è per gli umani di leggere e sapere cosa c'è dentro; avere un'estensione principale comune mi richiede di avere una regola di evidenziazione della sintassi per un solo set di estensioni di file.


5
Sottovalutato perché OS X utilizza principalmente l'estensione del file da anni.
Frederik Slijkerman,

6
@FrederikSlijkerman: No, non lo è. MacOS X è un Unix al suo interno e le estensioni di file non sono mai state usate lì per identificare qualcosa. Sì, i tipi standard ottengono estensioni di file standard, ma questa è solo una cosa di leggibilità umana. Forse il Finder può fare affidamento sulle estensioni dei file come euristica per alcuni tipi. Ma se è in grado di identificare un file solo tramite la sua intestazione o alcuni byte magici, lo utilizzerà. Come ogni sistema basato su Unix.
datenwolf

3
+1 Le chiamo come nome-effetto -fs.glsl o nome-effetto -vs.glsl.
legends2k,

9
Mi rendo conto che sono in ritardo di due anni per l'argomento OS X, ma mi sentivo come se dovessi buttare i miei due centesimi. Tutto al di sopra del livello UNIX utilizza LaunchServices per determinare le associazioni di file. Ogni file ha un identificatore di tipo simile com.stackoverflow.file, che viene archiviato come metadati. LaunchServices tenta di indovinarlo prima dal tipo MIME, se esiste la voce dei metadati. In caso contrario, cercherà l'estensione. Se non può corrispondere, cercherà un codice creatore HFS. Se non ce n'è, si arrende. LaunchServices non tenta mai di identificare un file in base all'intestazione o ai byte magici.
zneak,

2
Ciò significa che il modo più comune per determinare il tipo di un file su OS X è la sua estensione. Questo è solo allo scopo di identificare quale applicazione dovrebbe essere usata per aprire quale file, però. Una volta che l'applicazione apre il file, può decidere autonomamente cosa vuole farci, indipendentemente dal fatto che l'estensione sia corretta per il tipo di contenuto.
zneak,

7

Come altri hanno già detto, non esiste una risposta corretta nel senso più stretto. Vale la pena ricordare che Sublime (confermato per v2 e v3) prevede anche .vert e .frag per l'evidenziazione e la convalida della sintassi.


2
Credo che ciò sia vero solo se hai installato una libreria GLSL in Sublime, ad esempio github.com/WebGLTools/GL-Shader-Validator - il mio Sublime predefinito non riconosce le estensioni.
Air

La lib che hai collegato è di gran lunga la più popolare (e forse unica?) GLSL lib per sublime, e ho chiamato ciò che si aspetta come ciò che sublime si aspetta. Se lo chiami esagerazione, mi dichiarerò colpevole. Ma sì, hai ragione almeno quanto quel sublime come un doveroso editor di testo aprirà qualsiasi documento di testo ignorando le estensioni di cui non è a conoscenza.
Weavermount,

1
Ad oggi sublime-GLSL ( github.com/euler0/sublime-glsl ) è il più popolare plug-in GLSL e accetta la seguente serie di estensioni: vs, fs, gs, vsh, fsh, gsh, vshader, fshader, gshader, vert, frag, geom, tesc, tese, comp, glsl. Quindi c'è una varietà tra cui scegliere :)
F Lekschas,

-1

Esistono due modi per scrivere shader.

È possibile archiviare il vertex shader e frammentare il contenuto dello shader in una char *variabile e compilare, collegare e collegare lo shader a un programma.

Un altro modo è quello di scrivere il vertice separato e il file di shader di frammenti con qualsiasi estensione desiderata e leggerlo per compilare, collegare e collegare lo shader al programma.

Quindi la convenzione di denominazione, come .vert / .frag, .vsdr / .fsdr, ecc. Sono tutti validi fintanto che sai come leggerlo ...


-2

Come è già stato trattato da più risposte, in realtà non esiste uno standard; sta a te adottare l'approccio che ti è più utile.

Posso vedere i vantaggi nell'uso delle estensioni shader specifiche del tipo, ma la mia preferenza è quella di utilizzare l'estensione .glsl per tutti i tipi di shader, poiché è necessario definire come shell utilizza il file solo una volta.

Allo stesso modo, questa è anche una buona opzione se modifichi i tuoi file shader in Notepad ++, poiché puoi configurarlo per applicare automaticamente l'evidenziazione della sintassi specifica della lingua a tutti i tuoi file shader specificando solo un'estensione di file.

L'aspetto negativo di questo approccio è che è necessario utilizzare la propria convenzione di denominazione al fine di determinare il tipo di shader in base al nome del file, ma, per me, i vantaggi superano i costi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.