Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Программирование игр, графики и искусственного интеллекта > Shader, ScreenEffect

Автор: ForceKeeper 17.6.2010, 01:56

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

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

Автор: Bitter 17.6.2010, 11:28

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

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

Автор: ForceKeeper 20.6.2010, 00:56

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

Код


float4x4 view_proj_matrix;
float far_clip;
struct VS_OUTPUT 
{
   float4 Pos:     POSITION;
   float1 Depth:   TEXCOORD0;
};

VS_OUTPUT vs_main( 
   float4 inPos: POSITION, 
   float2 Txr1: TEXCOORD0
)
{
   VS_OUTPUT Out;
   float4 OutPos;

   // Compute the position of the vertex
   Out.Pos = OutPos = mul(view_proj_matrix, inPos);

   // Send the depth to the pixel shader for encoding
   Out.Depth = OutPos.w/far_clip;
   return Out;
}

Пиксельный.

Код


float4 ps_main( 
   float4 inDepth: TEXCOORD0
) : COLOR0
{
   //  Output the depth as computed by
   //  the vertex shader
   float4 Depth;
   Depth.w = 1.0;
   Depth.x = floor(inDepth.x*127)/127;
   Depth.y = floor((inDepth.x-Depth.x)*127*127)/127;
   Depth.z = 0;

   return Depth;
}

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

Код


Depth.x = floor(inDepth.x*127)/127;

передаст в красный канал старшие 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). Этим занимается строка

Код


Depth.y = floor((inDepth.x-Depth.x)*127*127)/127;

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

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

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

Автор: Rickert 20.6.2010, 12:47

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