В связи с тем, что у меня вопросы по шейдерам стали накапливаться, то трансформирую эту темку в их аккумулятор.
посему просил бы модеров переименовать топик в нечто в духе *Вопросы по шейдерам*


Сел читать учебник Shaders for game programmers and artits, дошел до части со скрин эффектами. И там в начале учат, как в атишном RenderMonkey рендерить в текстуру, налкадывать ее на плейн и выводить результат в последнем проходе эффекта. Делал все как сказано - черный экран. Смотрю в ресурсах на текстуру - в нее рендерится верно. Но вот на выходе в превью окне чернота. Стал смотреть примеры пост-эффектов, что идут вместе со средой ати, и выяснил, что нужно добавить в последнем проходе рендер стейт, где указать в поле D3DRS_CULLMODE значение D3D_CULL_NONE или D3D_CULL_CW, но не D3D_CULL_CCW, который так походу в дефолте стоит. 
Вопрос, что это за радость? Тем более, что в книге о ней ни слова.

Это сообщение отредактировал(а) ForceKeeper - 20.6.2010, 00:55

D3DRS_CULLMODE это режим отсечения невидимых поверхностей.  D3D_CULL_NONE - значит что режим отсечения не используется, D3D_CULL_CW - значит, что нужно не рендерить полигоны, нарисованые по часовой стрелке, D3D_CULL_CCW - значит, что нужно отсекать полигоны, нарисованные против часовой стрелки. (CW - Clock wise) Если Вы не уверены как нарисованы полигоны в Вашем случае, то укажите D3D_CULL_NONE. 

Эти режимы используются, например, чтобы не рисовать заднюю часть сферы, которая всё равно не видна пользователю. И так далее.

Такой вопрос. Разбираюсь с главой из пресловутого учебника, которая касается глубины поля. Там приводится три способа реализации. Во втором при рендеринге в текстуру, мы в альфа-канал пишем глубину пикселя, преобразуя эту информацию так, чтобы в дальнейшем использовать ее как коэффициент, с которым мы будем смешивать нормальный рендер и заблюреный. Ну и все отлично, однако *неуставное* использование альфы лишает нас возможности ввести, скажем, полупрозрачные объекты. И вот в третьем варианте предлагается писать преобразованную информацию о глубине пикселя не в альфу, а в цветные каналы доп. текстуры. И там сказано, что писать лишь в один цветовой канал нельзя, так как под него выделяется 8 бит, а альфа на 24 идет. Поэтому автор книги предлагает разбить информацию на три куска. И вот он приводит пример, как это можно сделать.
Привожу код пасса, который пишет в текстуру информацию о глубине пикселей.
Вершинный шейдер.


Пиксельный.


А теперь разбор полетов.
Сначала меня смущает, что информация о глубине вершины помещается в единичный флоут (используя почему-то регистр для текстурных координат), а пиксельный шейдер принимает эту информацию как флоут4.
Потом, камрад пишет, что строка

передаст в красный канал старшие 8 бит (так как утверждается, что инфа о глубина на входе идет в 24 бита, а каналы цвета по 8). Ну ладно, пускай железо по дефолту при несовпадении размеров так поступает. Но зачем домножать (с учетом того, что инфа в инДепс уже в интервале от 0 до 1) на 127, округлять и делить обратно? Причем еще пишется, что вообще должно юзаться 255, но сделав замену на 127 мы оберегаем себя от выхода за разрядную сетку (guard against overflows) и это позволит в дальнейшем складывать вместе несколько информаций о глубине. Я слабо себе представляю, как это нас убережет от переполнения (т.к. разница между исходным числом, числом с пляской со 127 и числом с преобразованиями при 255 совсем не велика) и каким образом использование 127, а не 255, дает нам возможность складывать *глубинную* информацию, а в противном случае - нет.

Ну и чтобы окончательно отправить меня в перезагрузку, утверждается, что для того, дабы выделить под зеленый канал средние 8 бит, нужно отнять от входной информации значение, что мы сейчас имеем в красном канале, и далее провести ту же процедуру, что и с красным в начале (To repeat
the same process with the following 8 bits of precision, you simply need to remove the 8
high bits and repeat the same process). Этим занимается строка

И в чем фокус? Во-первых, мне опять же непонятны эти шаманства с домножениями + во-вторых, ну ладно, отняли (при этом я не знаю, как точно ведет себя проц видюхи, когда ему нужно отнять от куска памяти в 24 бита кусок в 8), но у нас-то в любом случае исходное число в 24 бита как было, так таковым и осталось, крайняя восьмерка битов изменилась и все. И если железяка при отправке 24-битного значения в 8-битное как брало старших 8 бит, так их и возьмет. И поэтому я не знаю каким чудом в зеленом канале вдруг очутятся средние 8 бит.

Ну и под занавес замечу, что автор не юзал синий канал. 

И совсем-совсем под занавес отмечу, что я отправил всю инфу глубины без этих домножений-делений просто в красный канал и результат ни на йоту не ухудшился. Каким финальный рендер был, таким и остался.

 Правила форума: http://forum.vingrad.ru/index.php?act=boardrules