GLSLシェーダーの正しいファイル拡張子は何ですか?[閉まっている]


127

私はglslシェーディングを学んでいて、さまざまなファイル形式に出くわしました。頂点とフラグメントのシェーダー.vert.frag拡張機能を提供している人を見てきました。しかし、私はまた.vsh.fsh拡張機能、さらには両方のシェーダーを1つの.glslファイルにまとめて見ました。それで、標準のファイル形式があるのか​​、それとも「正しい」形式なのでしょうか?


10
私の知る限り、OpenGLはディスクからそれらを読み取ることができないため、「正しい」拡張機能はありません。
zneak

2
何が入っているかを明示するために、.vsや.fs(および.gs)と呼ぶ人もいます。しかしzneakが言ったように、それは本当に問題ではなく、「正しい」ものはありません。
デイモン

11
GEditは.glslv.glslf構文の強調表示を選択するときに使用します。それが重要な場所で私が見た唯一の場所です。
Piotr Praszmo

回答:


90

GLSLシェーダーには標準のファイル拡張子はありません。最も一般的なものは、おそらくある.vert.frag、これらは3D Labs社は、そのツールの一部で使用されることに拡張されているとして、。しかし、標準拡張のすべての形式についてはこれでおしまいです。


20
.vert | .fragはシェーダーの適切な拡張名ではないと思います。拡張子は、ファイルの一般的なクラスを識別するものです。彼らはおそらく、それらをvertex.glslおよびfragment.glslと呼んだはずです。
Autodidact 2013年

5
私も驚きましたが、頂点シェーダーとフラグメントシェーダー@SandeepDattaの構文にわずかな違いはありませんか?同じように、.hと.cは多くの点で共通していますが、使用方法は異なります。
ジョセフハンフリー

7
@SandeepDatta .hpp.cpp.h.c?頂点シェーダーとフラグメントシェーダーの構文と意味の違いは、C / C ++ヘッダーとソースファイルの違いよりも多くあります。
Miles Rout

1
@MilesRout .ccについて話すことすらしない

42
GLSLangは、GLSLリファレンスパーサーまたはリファレンスコンパイラとも呼ばれ、3Dlabsによって開発されたツールの1つです。opengl.orgとkhronos.orgの両方でSDKツールとしてリストされています。READMEのリストには、シェーダファイルに対して期待するファイル拡張子:.vert(頂点)、(.fragフラグメント)、 .tesc(テッセレーションコントロール)、 .tese(テッセレーション評価)、 .geom(幾何学)、 .comp(計算)。
TachyonVortex 2014年

93

仕様には公式の拡張機能はありません。OpenGLはファイルからのシェーダーの読み込みを処理しません。シェーダーコードを文字列として渡すだけなので、特定のファイル形式はありません。

ただし、KhronosのリファレンスGLSLコンパイラ/バリデーターであるglslangは、次の拡張機能を使用して、ファイルのシェーダーのタイプを決定します。

  • .vert -頂点シェーダー
  • .tesc -テッセレーションコントロールシェーダー
  • .tese -テッセレーション評価シェーダー
  • .geom -ジオメトリシェーダー
  • .frag -フラグメントシェーダー
  • .comp -計算シェーダー

18

拡張子によるファイルタイプの識別は、Windowsに固有のものです。他のすべてのオペレーティングシステムは異なるアプローチを使用します。MacOSXは、ファイルタイプをファイルシステムエントリの特別なメタデータ構造に格納します。ほとんどの* nixは、既知の「マジックバイト」のデータベースに対して内部構造をテストすることによってファイルを識別します。ただし、テキストエディタは拡張機能を使用します。

とにかく、GLSLソースは他のプログラムソースファイルと同じように、プレーンテキストであり、それがファイルタイプです。

必要に応じて選択できる拡張機能。私は次の名前を使用します:

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

しかし、それは私の選択であり、技術的には私のプログラムは名前付けや拡張スキームを強制することすらありません。ネーミングは、人間が何を読んでいるかを知るためのものです。共通の主要な拡張子を持つためには、1つのファイル拡張子セットに対してのみ構文の強調ルールが必要です。


5
OS Xが主にファイル拡張子を長年使用しているため、反対票が投じられました。
Frederik Slijkerman、2012年

6
@FrederikSlijkerman:いいえ、ありません。MacOS XはUnixであり、ファイル拡張子は識別に使用されていません。はい、標準タイプには標準のファイル拡張子が付きますが、それは人間が読みやすいものにすぎません。Finderは、一部のタイプのヒューリスティックとしてファイル拡張子に依存している可能性があります。ただし、ヘッダーまたはいくつかのマジックバイトだけでファイルを識別できる場合は、それを使用します。他のUnixベースのシステムのように。
datenwolf

3
+1私はそれらにeffect-name -fs.glslまたはeffect-name -vs.glsl という名前を付けます。
legends2k 2014

9
私はOS Xの議論に2年遅れていることを理解していますが、私は2セントを投入すべきだと感じました。UNIX層より上のすべてのものはLaunchServicesを使用してファイルの関連付けを決定します。各ファイルにはのようなタイプ識別子がありcom.stackoverflow.file、メタデータとして保存されます。LaunchServicesは、メタデータエントリが存在する場合、最初にMIMEタイプから推測しようとします。そうでない場合は、拡張子を探します。一致しない場合は、HFS作成者コードを探します。ない場合はあきらめます。LaunchServicesは、ヘッダーまたはマジックバイトでファイルを識別しようとすることはありません。
zneak

2
つまり、OS Xでファイルのタイプを判別する最も一般的な方法は、その拡張子です。ただし、これは、どのアプリケーションを使用してどのファイルを開くかを特定するためだけのものです。アプリケーションがファイルを開くと、拡張子がコンテンツタイプに対して正しいかどうかに関係なく、アプリケーションはそれを使用して何を実行するかを決定できます。
zneak

7

他の人が述べたように、厳密な意味での正解はありません。Sublime(v2とv3で確認済み)も、構文の強調表示と検証に.vertと.fragを期待していることは言及していません。


2
これは、GLSLライブラリがSublimeにインストールされている場合にのみ当てはまると思います(例:github.com/WebGLTools/GL-Shader-Validator-デフォルトのSublimeは拡張機能を認識しません)。
エア

あなたがリンクしたライブラリは、圧倒的に最も人気のある(そしておそらく唯一の?)GLSL libです。私は、崇高なものが期待するものとして、それを期待しているものと呼びました。あなたが誇張と呼ぶなら、私は有罪を認めます。しかし、はい、あなたは少なくとも、崇高なテキストエディタが知らない拡張機能を無視してテキストドキュメントを開くのと同じくらい、その崇高な点で正しいです。
Weavermount 2014年

1
現在、sublime-glsl(github.com/euler0/sublime-glsl)は最も人気のあるGLSLプラグインであり、次の拡張セットを受け入れますvs, fs, gs, vsh, fsh, gsh, vshader, fshader, gshader, vert, frag, geom, tesc, tese, comp, glsl。したがって、さまざまな選択肢があります:)
F Lekschas

-1

シェーダーを書く方法は2つあります。

頂点シェーダーとフラグメントシェーダーのコンテンツをchar *変数に格納し、コンパイルしてリンクし、プログラムにアタッチできます。

別の方法は、別の頂点とフラグメントシェーダーファイルに任意の拡張子を付けて書き込み、それを読み取ってコンパイルし、リンクして、プログラムにアタッチすることです。

したがって、.vert / .frag、.vsdr / .fsdrなどの命名規則は、それを読む方法を知っている限り、すべて有効です...


-2

すでに複数の回答でカバーされているように、実際には標準はありません。あなたにとって最も役立つアプローチを採用するのはあなた次第です。

タイプ固有のシェーダー拡張を使用する利点を確認できますが、シェルがファイルを1回使用する方法を定義するだけでよいため、すべてのタイプのシェーダーに.glsl拡張子を使用することをお勧めします。

同様に、これはNotepad ++でシェーダーファイルを編集する場合にも適しています。1つのファイル拡張子を指定するだけで、言語固有の構文強調表示をすべてのシェーダーファイルに自動的に適用するように構成できるためです。

このアプローチの欠点は、ファイル名でシェーダーのタイプを判別するために独自の命名規則を使用する必要があることですが、私にとっては、コストよりもメリットの方が勝っています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.