Crystallize технически для пользователя ничего не меняется, но свобода действий гораздо шире. Как и должно быть в норме.
Добавлено 25-03-2024 в 23:59:
Попытаюсь на примере объяснить разницу. Как устроены материалы во всех движках?
Есть некий фиксированный набор параметров, который вы можете указать материале. Строго определённые имена этих параметров, либо вообще бинарная структура. Иногда вы можете так же определить фиксированный набор пользовательских параметров с идиотскими именами, типа UserParam1, UserParam2. Дальше всё это парсится внутри движка и перенаправляется в шейдер, где подключается к точно таким же фиксированным именам юниформов. Т.е. движок по сути занимается каким-то копированием данных с жестко определёнными входными и выходными именами. Всё это берёт начало со времён Quake3, когда программируемого конвейера ещё не было. Т.е. исторически сложилось, да так и осталось.
Хотя смысла в этом никакого.
В Ксаше материалы устроены иначе. Вы объявляете переменную - и она автоматически превращается в юниформ. Или текстурный юнит. И вы назначаете этой переменной текстуру или источник данных. Согласно объявленному типу данных. Это может константное значение, выражение, какие-то данные из недр движка (вы сами выбираете, какие именно).
И всё это автоматически направляется в ваш шейдер. Движок об этом ничего не знает и занимается переброской абстрактных данных. Таким образом возможность написать любой шейдер больше не ограничена фиксированным набором входных данных, которые описывает материал.
Теперь в шейдер можно передавать любые данные. И всё это описано прямо в материале.
Тут легко догадаться, что подобное описание материала будет сильно напоминать уже полноценный язык программирования, а не лаконичный набор параметров. То есть это как минимум неудобно для художников.
И тут в дело вступает вторая подсистема - автозамена с перегрузкой.
Которая позволяет передавать произвольный набор параметров и оформлять макросы и как набор слов и как набор с фиксированными параметрами. Т.е. технически вы сперва формируете конвейер с произвольными эффектами - именно такими, какие нужны для вашей игры. А потом прячете все настройки под макросы и вместо кучи кода пишете одно-два ключевых слова, как будто работаете с классической системой материалов из конца 90-х.
Мощность системы тестировалась на возможности описать на ней шейдерный язык из Quake3, Doom 3. Так вот - моя система материалов позволяет без вмешательства в движок полностью реализовать шейдеры из Quake 3, чисто на макросах и автозаменах. И это будет полностью корректно работать, 1 в 1, как и в самой Quake3. К тому же есть возможность выполнять условия для оптимизации прямо по ходу чтения этих материалов. Я вам выложу имплементацию для Quake3 в очередной бета-версии. Помнится я однажды уже выкладывал, но тогда никто не понял что это такое. Да и сейчас я вижу доходит с величайшим трудом.
Дядя Миша писал: Так вот - моя система материалов позволяет без вмешательства в движок полностью реализовать шейдеры из Quake 3, чисто на макросах и автозаменах
Дядя Миша писал: Попытаюсь на примере объяснить разницу. Как устроены материалы во всех движках?
Есть некий фиксированный набор параметров, который вы можете указать материале. Строго определённые имена этих параметров, либо вообще бинарная структура. Иногда вы можете так же определить фиксированный набор пользовательских параметров с идиотскими именами, типа UserParam1, UserParam2. Дальше всё это парсится внутри движка и перенаправляется в шейдер, где подключается к точно таким же фиксированным именам юниформов. Т.е. движок по сути занимается каким-то копированием данных с жестко определёнными входными и выходными именами. Всё это берёт начало со времён Quake3, когда программируемого конвейера ещё не было. Т.е. исторически сложилось, да так и осталось.
Хотя смысла в этом никакого.
В Ксаше материалы устроены иначе. Вы объявляете переменную - и она автоматически превращается в юниформ. Или текстурный юнит. И вы назначаете этой переменной текстуру или источник данных. Согласно объявленному типу данных. Это может константное значение, выражение, какие-то данные из недр движка (вы сами выбираете, какие именно).
И всё это автоматически направляется в ваш шейдер. Движок об этом ничего не знает и занимается переброской абстрактных данных. Таким образом возможность написать любой шейдер больше не ограничена фиксированным набором входных данных, которые описывает материал.
Так в Юнити материал тоже составляется согласно юниформам шейдера. Прикол в том что хоть в первом дууме, хоть в третьей кваке, хоть в сорсе, хоть в кризисе, хоть в ведьмаке альбедо остаётся альбедо, а карта нормалей картой нормалей, независимо от материала, и вообще наличия материал системы как таковой. Дерево будет оставаться деревом не зависимо от движка и игры. А потом уже пользователь пишет кастомный шейдер и делает с этим набором любую дичь.
Цитата:
Дядя Миша писал: Мощность системы тестировалась на возможности описать на ней шейдерный язык из Quake3, Doom 3. Так вот - моя система материалов позволяет без вмешательства в движок полностью реализовать шейдеры из Quake 3, чисто на макросах и автозаменах. И это будет полностью корректно работать, 1 в 1, как и в самой Quake3. К тому же есть возможность выполнять условия для оптимизации прямо по ходу чтения этих материалов. Я вам выложу имплементацию для Quake3 в очередной бета-версии. Помнится я однажды уже выкладывал, но тогда никто не понял что это такое. Да и сейчас я вижу доходит с величайшим трудом.
Так, а как это влияет на поля с текстурами? Скажем Diffuse = "kek.png", Albedo("kek.png), Texture2d = "kek.png" это совершенно разные по концепции вещи? Ты же сам говоришь что система гибкая, так почему нельзя использовать какой то общий совместимый базовый шаблон? А там пускай пользователь конвертирует в материалы третьей кваки если ему надо.
FiEctro писал: Ну понятно, опять всё вручную прописывать в блокнотике
Не всё. Если ты программист - можно добавить суффиксы к именам текстур, как это сейчас в MIR - _bump, _spec, _luma, которые цепляются автоматически. Я, правда, не программист, но у меня есть. Имя материала в блендере - это ссылка, так же как и имя материала для меша после экспорта. По этому адресу цепляются битмапы. Дефолтный материал есть - то есть можно не создавать отдельный файл в блокноте, если ты, конечно, не хочешь, например, добавить прозрачность по альфе. Продолжая логику суффиксов, можно вообще все материалы выстроить по такому принципу - _metal, _wood, _glass итд. Обозвал, закинул - и какой надо сразу.
Ну вот я и думаю сериализовать содержимое исходника в формат похожий на абстрактный ксашевский материал. А вот обратно похоже только дифузку получится подцеплять из имени материала, хотя там тоже могут быть подвохи. Короче такая система крайне не юзерфрендли, но зато материалы из ку3 работают, правда я не знаю кому они нужны вообще.
Цитата:
Raid писал: Продолжая логику суффиксов, можно вообще все материалы выстроить по такому принципу - _metal, _wood, _glass итд. Обозвал, закинул - и какой надо сразу.
FiEctro писал: И получить DLL_hell только для суфиксов.
Это не имеет отношения к dll, т.к. из компиляторов только компиляторы уровней. Все суффиксы описываются либо макросами, которые ты потом дёргаешь в материал, либо прямо шейдерами, если жить скучно.
Raid писал: все материалы выстроить по такому принципу - _metal, _wood, _glass итд. Обозвал, закинул - и какой надо сразу.
Речь не про длл, а то что вы всячески стараетесь прибить параметры гвоздями. В итоге придётся пользователем делать свои дублирующие теги в духе _wall34868 которые ещё не факт что не будут конфликтовать.
Как говорил Дядя Миша материал описывает просто настройки для униформов шейдера.
Цитата:
Дядя Миша писал: Есть ещё вариант запись материала в одну строку, но он детально не тестировался.
Да чего уж, сразу азбукой морзе надо, и обязательно в обратном порядке как у арабов, чтобы наверняка никто не догадался.
Цитата:
Дядя Миша писал: Ты можешь придумать для себя абсолютно любую систему материалов.
И Ксаш её подхватит. Устроит такой вариант?
Но с ограничением, что описание каждого материала - это именованный блок фигурных скобок
С экспортом ещё более менее понятно. А вот как импортировать из чужих шейдеров?
Дядя Миша писал: Я вам выложу имплементацию для Quake3 в очередной бета-версии. Помнится я однажды уже выкладывал, но тогда никто не понял что это такое. Да и сейчас я вижу доходит с величайшим трудом.
Дядя Миша писал: Приведи пример, что ты собрался импортировать.
Ну вот есть условно у тебя моделька карты из сталкера в формате csm. Мне надо подгрузить или хотя бы сериализовать в одном месте все пути к текстурам, дифузки, карты нормалей и так далее.
Цитата:
Дядя Миша писал: Ну хотя я понял откуда такое недоверие. Это ты по Unity судишь.
Скорее по голдсорцу. Оттуда пошли эти дуратские теги и нарративы что имя текстуры == имени материала.
Цитата:
Дядя Миша писал: Ему объясняешь, что ничего никуда не прибито, он говорит - я понял, всё прибито гвоздями.
_metal, _wood, _glass
А это что такое?
Цитата:
Дядя Миша писал: Материал много чего описывает.
Это не правильно. Материал не должен перекладывать на себя функционал шейдера как это делает третья квака. Это должна быть просто структура без какой либо логики.
FiEctro писал: Мне надо подгрузить или хотя бы сериализовать в одном месте все пути к текстурам, дифузки, карты нормалей и так далее.
Пока нет своего редактора я не могу что-то комментировать.
Сейчас декомпиляторы настроены так, чтобы сохранить оригинальные пути к текстурам. Точнее даже не декомпиляторы, а материалы.
Цитата:
FiEctro писал: Оттуда пошли эти дуратские теги и нарративы что имя текстуры == имени материала.
Ксашевская система материалов НЕ НАВЯЗЫВАЕТ такой подход. Она его просто позволяет реализовать на уровне пользователя, не модифицируя бинарные файлы, чисто из скриптов. Raid сказал что ему так будет удобнее - я ему это сделал. Собственно всё. Придумай любой другой подход и точно так же настрой в скриптах.
Цитата:
FiEctro писал: Это не правильно. Материал не должен перекладывать на себя функционал шейдера как это делает третья квака. Это должна быть просто структура без какой либо логики.
Сказал человек в жизни не написавший ни одного движка и даже не утрудивший себя чтением документации по ксашу и самое страшное - даже не читающий что именно я ему пишу. Я ему толкую про абстрактные материалы, которые не перекладывают на себя функционал шейдера, он говорит - нет это неправильно, они не должны на себя перекладывать функционал шейдера. И вот так - уже третью страницу.
| IP: 
25-03-2024 20:59
