• null
• constant
• matte
• metal
• shinymetal
• plastic
• paintedplastic
• ambientlight
• distantlight
• pointlight
• spotlight
• depthcue
• fog
• bumpy
• background
Так что поиграть уже есть с чем, но мы хотим сделать что-то свое. Представим себе, что вы где-то из Интернета скачали шейдер, который обучает вас использованию в Shading Language функции noise:
surface noisetest ( float freq=10; )
£
Ci = color(noise(freq*s,freq*t));
}
Для продвинутых. Нойз (“шум”) - это отличный и обычно первый из приходящих в голову способов добавить нерегулярности в “стерильную” компьютерную картинку.
Сохраните его в текстовый файл под названием noisetest.si рядом с файлом test3.rib. Немного правим test3.rib, добавляя в него ссылку на новый материал:
Display “RenderMan” “framebuffer” “rgb”
Format 256 192 1 ShadingRate 1 Translate 0 0 2.7650300856 WorldBegin TransformBegin LightSource “ambientlight” 500
“lightcolor” [0.051 0.051 0.051]
LightSource “distantlight” 501 “from” [1 1.5 -1] “to” [0 0 0]
LightSource “distantlight” 502 “lightcolor” [0.2 0.2 0.2]
“from” [-1.3 -1.2 -1.0] “to” [0 0 0]
TransformEnd Surface “noisetest”
Sphere 1 -1 1 360 WorldEnd
Запускаем на рендеринг - и получаем сообщение об ошибке:
S01001 Cannot load shader “noisetest”. (WARNING)
Что происходит? Мы же, вроде бы, все правильно сделали, указали материал, положили шейдер рядом - что не так? Ан нет, не все так просто. Перед непосредственным использованием шейдер необходимо привести в состояние, которое будет максимально удобным для рендерера
- а попросту говоря, откомпилировать.
Для любознательных. Конечно же, рендерер мог бы и сам понять, чего от него хотят, и откомпилировать шейдер внутри себя. Но это бы противоречило духу и одному из основных принципов Unix (“для каждой задачи - своя небольшая программа”), исторической справедливости и не дало бы нам в руки могучее оружие пайпинга - а оно нам доступно и в этом случае.
Для компиляции используется вторая программа нашего могучего триумвирата - shader.exe. Возможности и гибкость вызова этой программы абсолютно аналогичны возможностям и гибкости prman.exe: если мы хотим, можем соорудить цепочку программ, которые будут генерировать тексты шейдеров на языке SL. Но мы сделаем просто:
shader noisetest.si
Программа отработала, и в нашей директории рядом с файлов noisetest.si появился noisetest.slo. Не стоит в него заглядывать - там интересно, но не настолько, чтобы мы отвлекались. Попробуем отрендерить картинку еще раз и вот:
Для продвинутых. Далеко не очевидна, особенно для начинающих, мысль, что шейдеры вообще нужно компилировать. Даже если не затрагивать исторические корни языка шейдеров (а именно, язык программирования С и модель работы с программами, написанными на нем), достаточно будет одного лишь довода в пользу такого требования скорость исполнения. Язык С достаточно сложен для того, чтобы быстро интерпретировать его (выполнить программу без предварительной компиляции) было почти невозможно. Поэтому создатели рендереров идут на что угодно, лишь бы ускорить процесс обработки шейдеров внутри своих программ, перенося эту задачу на компиляторы шейдеров. Prman внутри себя использует архитектуру выполнения SIMD, для которой компилятор shader генерирует специальный бинарный код. Другие рендереры поступают по-другому, например, RenderDotC превращает SL-код в минипрограмму на языке программирования C++, которая затем компилируется уже в файл DLL - и скорость выполнения шейдера таким, хитрым, образом увеличивается во много раз.