Какое расширение файла подходит для шейдеров GLSL? [закрыто]

127

Закрыто . Этот вопрос основан на мнении . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы на него можно было ответить с помощью фактов и цитат, отредактировав этот пост .

Закрыт 12 месяцев назад .

Уточните этот вопрос

Я изучаю затенение glsl и сталкивался с разными форматами файлов. Я видел, как люди использовали свои вершинные и фрагментные шейдеры .vertи .fragрасширения. Но я также видел .vshи .fshрасширения, и даже оба шейдера вместе в одном .glslфайле. Поэтому мне интересно, есть ли стандартный формат файла или какой из них «правильный»?

opengl glsl shader

— Samssonart
источник

10

Насколько мне известно, у них нет «правильных» расширений, так как OpenGL все равно не будет читать их с диска.

— zneak

2

Некоторые люди называют их .vs и .fs (и .gs), чтобы понять, что внутри. Но, как сказал zneak, на самом деле это не имеет значения, "правильного" не бывает.

— Дэймон

11

GEdit использует .glslvи .glslfпри выборе подсветки синтаксиса. Это единственное место, где это важно.

— Piotr Praszmo

90

Стандартного расширения файлов для шейдеров GLSL не существует. Наиболее распространенными из них, вероятно, являются .vertи .frag, поскольку это расширения, которые 3D Labs использовали в некоторых своих инструментах. Но это все для любой формы стандартного расширения.

— Никол Болас
источник

21

Я не думаю, что .vert | .frag - хорошие имена расширений для шейдеров. Расширение - это то, что определяет общий класс файла. Наверное, им следовало бы назвать их vertex.glsl и fragment.glsl.

— Autodidact

5

Я тоже был удивлен, но разве нет небольшой разницы в синтаксисе между вершинными и фрагментными шейдерами, @SandeepDatta? Точно так же, как .h и .c могут иметь много общего, но они используются по-разному.

— Джозеф Хамфри

7

@SandeepDatta .hppvs. .cpp? .hпротив .c? Между вершинными и фрагментными шейдерами больше синтаксических и семантических различий, чем между заголовочными и исходными файлами C / C ++.

— Miles Rout

1

@MilesRout Даже не говоря о .cc

42

GLSLang, также известный как справочный синтаксический анализатор GLSL или справочный компилятор , является одним из инструментов, разработанных 3Dlabs . Он указан как инструмент SDK как на opengl.org, так и на khronos.org. В README списки расширений файлов , он ожидает , что для шейдерных файлов: .vert(вершинные), .frag(фрагмент), .tesc(контроль тесселяции), .tese(оценка тесселяции), .geom(геометрия), .comp(Compute).

— TachyonVortex

93

В спецификации нет официального расширения. OpenGL не поддерживает загрузку шейдеров из файлов; вы просто передаете код шейдера в виде строки, поэтому нет определенного формата файла.

Однако glslang , эталонный компилятор / валидатор GLSL от Khronos, использует следующие расширения, чтобы определить, для какого типа шейдера предназначен файл:

.vert - вершинный шейдер

.tesc - шейдер управления тесселяцией

.tese - шейдер оценки тесселяции

.geom - шейдер геометрии

.frag - фрагментный шейдер

.comp - вычислительный шейдер

— Полковник тридцать два
источник

18

Определение типа файла по расширению - это особенность Windows. Все остальные операционные системы используют разные подходы: MacOS X хранит тип файла в специальной структуре метаданных в записях файловой системы. Большинство * nix'ов идентифицируют файлы, проверяя их внутреннюю структуру по базе данных известных «магических байтов»; однако текстовые редакторы используют расширение.

В любом случае, исходники GLSL такие же, как и любой другой исходный файл программы: обычный текст, и это их тип файла.

Расширение вы можете выбрать по своему усмотрению. Я использую следующие названия:

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

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

— datenwolf
источник

5

Проголосовали против, потому что OS X уже много лет в основном использует расширение файла.

— Frederik Slijkerman

6

@FrederikSlijkerman: Нет, это не так. MacOS X - это Unix по своей сути, и расширения файлов никогда не использовались для идентификации. Да, стандартные типы имеют стандартные расширения файлов, но это только удобочитаемость человека. Возможно, Finder может полагаться на расширения файлов в качестве эвристики для некоторых типов. Но если он может идентифицировать файл только по его заголовку или некоторым магическим байтам, он будет использовать это. Как и любая система на базе Unix.

— datenwolf

3

+1 Я называю их именем- эффекта -fs.glsl или именем-эффекта -vs.glsl.

— legends2k

9

Я понимаю, что опаздываю на аргумент OS X на два года, но чувствовал, что должен добавить свои два цента. Все, что находится выше уровня UNIX, использует LaunchServices для определения ассоциаций файлов. Каждый файл имеет идентификатор типа com.stackoverflow.file, например , который хранится в виде метаданных. LaunchServices сначала пытается угадать его по типу MIME, если запись метаданных существует. Если нет, он будет искать расширение. Если он не может соответствовать ему, он будет искать код создателя HFS. Если его нет, он сдается. LaunchServices никогда не пытается идентифицировать файл по его заголовку или магическим байтам.

— zneak

2

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

— zneak

7

Как отмечали другие, нет правильного ответа в самом строгом смысле слова. Следует упомянуть, что Sublime (подтвержденный для v2 и v3) также ожидает .vert и .frag для выделения и проверки синтаксиса.

— Weavermount
источник

2

Я считаю, что это верно только в том случае, если у вас установлена библиотека GLSL в Sublime, например github.com/WebGLTools/GL-Shader-Validator - мой Sublime по умолчанию не распознает расширения.

— Воздух

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

— Weavermount

1

На сегодняшний день возвышенного-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

Есть два способа написания шейдеров.

Вы можете сохранить содержимое вершинного шейдера и фрагментного шейдера в char *переменной, а также скомпилировать, связать и присоединить шейдер к программе.

Другой способ - написать отдельный файл вершинного и фрагментного шейдера с любым расширением, которое вам нравится, и прочитать его, чтобы скомпилировать, связать и присоединить шейдер к программе.

Таким образом, соглашения об именах, такие как .vert / .frag, .vsdr / .fsdr и т. Д., Действительны, если вы знаете, как их читать ...

— user2439483
источник

-2

Как уже было сказано в нескольких ответах, на самом деле нет стандарта; Вам решать, какой подход будет вам наиболее полезен.

Я вижу преимущества использования расширений шейдеров для конкретных типов, но я предпочитаю использовать расширение .glsl для всех типов шейдеров, поскольку вам нужно только один раз определить, как оболочка использует файл.

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

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

— Льюис
источник