Система материалов, часть 2
Тем не менее, несмотря на вышеописанные недостатки, эта система весьма понравилась как раз программистам, которые никакие материалы естественно не настраивали, но зато у них перед глазами была рабочая концепция, которую можно было позаимствовать в свой движок, не утруждая себя мыслями о собственной. Здесь надо отметить что отголоски ку3шных шейдеров встречаются даже в исходном коде первого Crysis, хотя оно там уже практически зачахло и не использовалось, но тем не менее - такой вот любопытный факт вам в копилку.
После Quake III, был так же Doom III, где система шейдеров уже была переименована в систему материалов, худо-бедно научилась работать с освещением, обзавелась некоторыми пресетами, позволяющими не настраивать каждый новый материал, полностью прописывая его свойства и даже способностью подгружать фрагментные и вершинные шейдеры, передавая в них некий набор фиксированных параметров, но от фундаментальных недостатков, перечисленных выше, увы - так и не избавилась.
Потом свет увидел Half-Life 2, где материалы разместились каждый в своём текстовом файлике (тут чувствуется влияние Quake 2), где описание на первый взгляд было довольно простым, но по факту там были десятки встроенных параметров, каждый из которых за что-то отвечал.
И снова не было нормальной возможности полностью переиначить эту систему, сделать какой-то принципиально иной рендеринг, ведь система материалов явным образом опиралась на внутреннюю реализацию рендера. Так же следует сказать, что в большинстве тех движков, что я видел, имена шейдеров (настоящих, для исполнения на GPU), зачастую были жестко определены внутри самого рендерера и являлись монолитной частью системы рендеринга. А настройки материалов, как бы приходили с другой стороны и уже внутри кода копировались в юниформы для передачи в эти самые шейдеры.
При желании можно найти примеры движков, где код копирования разных параметров из описания материала в юниформы мог спокойно занимать 200-400 килобайт. То есть по сути это всё было однотипное перемещение данных но с разными именами.
Также следует упомянуть и о другом интересном перекосе - когда весь материал наоборот пытались описать там же где и сам GPU-шейдер, вводя препроцессинг. Этим часто болели различные инди-движки, вы без труда их вспомните.
Обычно там пытались сделать что-то вроде тэгов [vertexshader], [fragmentshader] и блока юниформов и текстур.
Впрочем, нечто аналогичное было и в DirectX, хотя и более гибкое, т.к. оно позволяло настраивать различные стейты конвейера, недоступные из шейдера, например включать прозрачность или отключать запись в буфер глубины.
Однако на полноценные материалы всё это на мой взгляд всё равно не тянуло. Основной критерий - удобство работы художника в настройке таких материалов и возможность подключения всё новых и новых эффектов, без модификации исходного кода рендерера.
Забегая вперёд скажу, что над собственной системой материалов (прежде чем её создать), я размышлял более пяти лет и забраковал не один десяток вариантов. Впрочем, даже уже, непосредственно, в процессе её написания, система претерпела фундаментальные изменения пять раз, прежде чем наконец-то превратилась в то, что есть сейчас. Лишнее подтверждение тому, что финальный вариант оказался правильным, я вижу в том, что для подключения новых эффектов у меня совершенно не возникает необходимости что-то менять ни в рендерере ни в системе материалов - достаточно лишь прописать этот новый эффект в скриптах.