Тёмная тема
Доброго времени суток.
Подскажите как использовать набор шейдеров в одном файле. Допустим мне необходимо для объекта использовать вершинный и фрагментный для простоты понимания. стандартно разбивается на два файла, тут все ясно. Но если записать оба шейдера в один файл допустим с расширением glsl. Как правильно его парсить в своей программе по синтаксису не используя в файле "левые" метки. Количество шейдеров можно определять по
#version
void main()
дефайнами разбей
http://jorgesanchez.me/notes/multiple-shaders-in-one-file/
Посмотрел приведенный пример. На сколько такой подход по "феншую", предоставленая реализация с дефами проще чем с метками и при этом в рамках синтаксиса glsl. Взял на заметку. Ест ли еще методы или это оптимальный вариант без синтаксического анализа. Данный метод вполне подходит, хотел узнать альтернативы если есть. Благодарю за помощь.
Вставь метки, например <vertex>, <fragment> и парси самостоятельно.
Кстати в hlsl эти извраты не нужны, там имя шейдера ты сам определяешь.
signum7
Ещё проще:
файл\стрим состоит из множества кусков.
В начале каждого куска первые 4 байта - это длина куска, это же является указателем на следующий кусок. Тогда никакой мороки с адресами начала и не нужен заголовок.
Любой кусок можно безболезненно удалять, вся структура останется целостной.
Нужен кусок по индексу 5 - делаешь 4 прыжка.
Это легче, чем парсить, да и на порядки быстрее.
flint2
> В начале каждого куска первые 4 байта - это длина куска,
Вообще-то glsl это текстовый файл. Его руками правят, в текстовом редакторе. Какие куски, какая длина? Кто это будет вычислять после каждой правки?
Вот вам еще один вариант - можно использовать json формат. Тогда файл приобретет такой вид:
{
"Fragment" : " код фрагментного шейдера ",
"Vertex" : " код вертексного шейдера"
}
Парсеров Джейсона полно. Самому ничего писать не надо.
Но по моему lookid дал самое простое решение.
signum7
> На сколько такой подход по "феншую",
он по феншую, все так делают
san
ТС сперва создал себе проблему, потом пытается её решить. О дивный мир. На компиляцию ты всё равно будешь отправлять сырой кусок текста конкретного шейдера, а как ты его хранишь абсолютно не важно, выбери какой угодно способ представлений, хоть в json или xml их засунь, если так уж сильно хочется усложнить себе жизнь.
signum7 вот пример:
https://yadi.sk/d/p7zblCNFZn2kpA
Load file - загрузка файла скрипта в редактор.
Add txt - добавляет скрипт в файл со всеми скриптами scripts.glsl
Del ind - удаляет запись с индексом в окошке из scripts.glsl.
DataReplace - заменяет запись с индексом в окошке в scripts.glsl.
Load ind - загружает скрипт с индексом в окошке из scripts.glsl
Clear - чистит поле редактора.
Принципиальной разницы нет что пихать в поток.
Одна запись может быть музыкой, другая exe, третья картинкой, четвёртая текстом и всё это можно жать налету.
Времени не было, поэтому сделал только для текста и без сжатия.
Для примера накидал файлов всяко-разно - попробовать.
flint2
Я тоже хотел что-то типа редактора для файлов запилить. но все руки не доходят Embarcadero red studio уже полгода не открывал ))
Запись может быть музыкой, другая exe, третья картинкой хорошая вещь, хотелось бы увидеть реализацию.
Aroch
Та нет никакой проблемы, в одном файле все шейдеры удобнее чем несколько файлов согласись.
signum7
flint2
Я сейчас 3d движок пишу, в том числе будет поддержка LUA (в данный момент lua занимаюсь). если будет сохранение ресурсов в каком то формате известном вам на этапе проектирования вашего приложения, не что не помешает внедрить прямую загрузку данных в движок "на лету" пока собственно движок проектируется. движок переваривает такие данные как аудио, модели, колизии для физики, настройки. Модели в форматах obj для статических сцен (только мещь с текстурами). dae, 3ds все данные подераемые форматами.
signum7