Такой вопрос. Разбираюсь с главой из учебника "Shaders for game programmers and artists", которая касается глубины поля. Там приводится три способа реализации. Во втором при рендеринге в текстуру, мы в альфа-канал пишем глубину пикселя, преобразуя эту информацию так, чтобы в дальнейшем использовать ее как коэффициент, с которым мы будем смешивать нормальный рендер и заблюреный. Ну и все отлично, однако *неуставное* использование альфы лишает нас возможности ввести, скажем, полупрозрачные объекты. И вот в третьем варианте предлагается писать преобразованную информацию о глубине пикселя не в альфу, а в цветные каналы доп. текстуры. И там сказано, что писать лишь в один цветовой канал нельзя, так как под него выделяется 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 бит.

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

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

Регистр TEXCOORD0 используется вероятно потому что в нем значение глубины интерполируется между вершинами. И доступ к нему через float4 потому что он и есть float4. Используется всё равно только один флоат, так что пусть его.

Деление/умножение на 127 и floor() производится видимо с целью построить 16-битную карту из 24-битной с потерей точности. Как оно работает лично мне не совсем понятно, но напрямую 24 бита в восемь вы точно не запихаете. И если после этого шаманства там правда получаются 7-битные числа, две карты можно будет сложить не вылезая за пределы имеющегося байта. Восьмибитные карты тоже можно сложить, но в зависимости от того какие в них значения может получиться полная лажа.

И ещё сдаётся мне что либо книга эта - Г, либо читаете вы её не с начала.