Система материалов, часть 1
Перечитал посты на канале и заметил, что про систему материалов XashNT так не было сказано ни одного слова, только упоминания в комментариях. Буду исправляться.
Пока игровые движки только становились на ноги, необходимость в каком-то явном задании типов материала практически отсутствовала. Ну конечно же нам надо было поместить воду, небо и пару-тройку эффектов, типа скроллящейся текстуры. Через атрибут самой поверхности или особый символ в имени этой текстуры. Но уже начиная с Quake2, потребность настраивать материалы более гибко стала довольно актуальной.
Поскольку в 90-е все тренды задавала именно Id Software, я буду считать что первая система материалов появилась именно в Quake2, но если вы располагаете иной информацией, то напишите об этом в комментариях.
Система по современным меркам предлагала довольно бедные возможности: настроить анимацию текстур, два уровня прозрачности на выбор, установить поверхность в качестве источника света, а так же задать некие физические свойства - вода, небо, ну и разумеется пресловутый скроллинг текстуры (куда же без него).
В принципе на тот момент это можно было считать прорывом, но уже в третьем Quake, нам показали гораздо более мощную и продвинутую систему шейдеров (поскольку на тот момент ещё не было программируемого конвейера, то первое упоминание шейдеров связано именно с Quake III Arena). Однако, несмотря на кажущуюся мощь этой системы, на самом деле у нее было довольно много недостатков, которые были актуальны уже на момент её создания, но почему-то не были очевидны всем.
Перечислю их здесь, заодно проверим ваше мнение по этому поводу:
- У системы были крайне ограниченные возможности по работе с освещением. Можно было вручную лишь подключить лайтмапу, причём это нужно было сделать ещё и правильным образом, а влияние динамических источников света из материала практически никак не учитывалось и не регулировалось. Можно было лишь полностью запретить освещение материала такими источниками.
- Описание материала могло отсутствовать, тогда нам предлагался дефолтный материал: диффузная текстура + лайтмапа. Любая мелочь, например потребность добавить к материалу физическое свойство, приводило к необходимости полностью прописывать все свойства материала, путь к текстуре, настройки для лайтмапы и т.д.
- Архитектура шейдеров была завязана фиксированный конвейер, то есть описание материала выглядело как несколько настроенных текстурных юнитов, которые смешивались между собой. Когда появились настоящие шейдеры (т.е. программы для выполнения на GPU), их разумеется попытались гармонично увязать с уже существующей системой скриптовых шейдеров от Кармака, в многочисленных форках Quake III Arena, после опубликования её исходников. Без особого впрочем успеха, поскольку добавить функционал недостаточно - ведь надо было ещё как-то научить художников этим пользоваться.
- Несмотря на обилие параметров в подавляющем большинстве случаев весь функционал системы сводился к созданию мигающих и скроллящихся текстур в любых вариациях, на большее система была просто не рассчитана.
Это хорошо видно по самой Quake 3, где всё блестит и мигает, а, например в Return To Castle Wolfenstein, вся эта мощь шейдерной системы практически не используется - в сеттинге просто нечему мигать и блестеть. - Самый главный недостаток, который впоследствии успешно перекочевал и во множество других систем - это захардкоженность ключевых слов. То есть у нас есть некие команды, которыми мы можем задавать какие-то эффекты, руководствуясь внутренней логикой создателей этой системы. Чтобы добавить новый эффект нам приходится вносить изменения в бинарный код. И при этом ещё убедиться что не произошло никакого регресса.
Таким образом художник полностью зависим от программиста.