Z-Buffer
- Автор темы Narvi
- Дата создания
> Хмм....Kidd.....какой, извини, "zfile, сделанный через mayaiff rgbaz"?
Display "lamb.iff" "mayaiff" "rgbaz"
> Это ж просто display driver записал тебе iff.....и почему только 8 бит?
> Откуда такая информация, что 8?
Загрузил в Shake, и он мне показал - 8bit Z buffer.
Кроме того, я не делал
Quantize "rgba" 65535 0 65535 0.5 # uncomment this line for 16 bit output
Кстати, с этой строкой файл в формате mayaiff получается в 2 раза больше по размеру. И тоже легко засасывается шейком...
> Shake вроде не умеет показывать просто так z-buffer....только
> извратами, сокращая его до 8 бит.
Вполне возможно. Но я вижу обратное: Файл в формате mayaiff 16тибитный с zbuffer-ом нормально засосался и работает.
Display "lamb.iff" "mayaiff" "rgbaz"
> Это ж просто display driver записал тебе iff.....и почему только 8 бит?
> Откуда такая информация, что 8?
Загрузил в Shake, и он мне показал - 8bit Z buffer.
Кроме того, я не делал
Quantize "rgba" 65535 0 65535 0.5 # uncomment this line for 16 bit output
Кстати, с этой строкой файл в формате mayaiff получается в 2 раза больше по размеру. И тоже легко засасывается шейком...
> Shake вроде не умеет показывать просто так z-buffer....только
> извратами, сокращая его до 8 бит.
Вполне возможно. Но я вижу обратное: Файл в формате mayaiff 16тибитный с zbuffer-ом нормально засосался и работает.
http://www.dream.com.ua/downloads/z2tiff.exe
На выходе получается TIFF, 32бита на точку. Shake его правильно не показал, sho тоже, fcheck ругнулся. iv (из поставки Entropy) показал нормально. Photoshop не захотел. imconvert выдал срань. Image Alchemy распознал файл и глубину, но работать с такими не умеет. Больше у меня ничего нет ;-)
Пробуйте, расскажите, что у кого получится. Сорцы могу дать, я с ними поборолся немного - перевел из Little Endian и сделал независимыми от Windows. Наверное, придется унижаться до 16ти бит ;-))
На выходе получается TIFF, 32бита на точку. Shake его правильно не показал, sho тоже, fcheck ругнулся. iv (из поставки Entropy) показал нормально. Photoshop не захотел. imconvert выдал срань. Image Alchemy распознал файл и глубину, но работать с такими не умеет. Больше у меня ничего нет ;-)
Пробуйте, расскажите, что у кого получится. Сорцы могу дать, я с ними поборолся немного - перевел из Little Endian и сделал независимыми от Windows. Наверное, придется унижаться до 16ти бит ;-))
Joss, don't waste your time. Check these links out and you'll find "Affine Toolkit" written quite a while ago by Thomas E. Burge (sometime in 1995 - 98). Z2TIFF converter is included in "Bitmap Utilites".
http://www.affine.org/bmp.html
http://www.affine.org/index.html
affine0008.tar.gz is about 1.2M.
http://www.affine.org/bmp.html
http://www.affine.org/index.html
affine0008.tar.gz is about 1.2M.
Ладно, шутки с MayaMan и sho в сторону.
Joss, естественно, что z-buffer не фильтруется. Если посмотреть на process pipeline в RiSpec, то там нарисовано как image data и depth data попадают в imager и потом им renderman делает quantize и output, причем для z-buffer свой quantize, для data свой. Если выводить RGBAZ, то renderman автоматом использует box filter step 1 для RGBA, вне зависимости от того какой тип фильтра выставлен и выдает WARNING. Если использовать mayaiff display driver, то получается изврат, потому что, этот display driver пишет RGBA 8 или 16 bit, а z-buffer 32 bit float. Несмотря на то, что Nothing Real заявляют, что они тоже испольуют 32 bit float на channel, тем не менее есть разница, так как их float может быть < 0 и > 1, в то время как renderman, на основе camera clipping planes, делает им quantize м/у 0 и 1. Так что читать его Shake читает, но при попытке посмотреть с Depth Filter z-channel выглядит совсем не так, как должен. Кстати, на Highend3D тоже ничего умнее, чем конвертация в 8 bit TIFF, не придумали. По моему, самый простой выход - выводить z-buffer в 16 bit IFF файл из Maya, а RGBA делать prman-ом. Тем более, что IFF это родной формат для Shake. Что самое интересное, - именно этот способ у буржуев преподается в университетах на fine arts. Они его стандартно изучают, когда дело доходит до комбинации renderman + paint effects.
P.S.
1. Сорри, Kidd, не посмотрел на пост ( Z2TIFF ), заслал свой с работы, второпях.
2. Zfile format и shadow texture file format не одно и тоже.
3. У меня есть подозрение, что Pixar не смог пофиксить все баги связанные с Big и Little Endian нотациями, когда портировал renderman под NT. Три display driver поддерживают z-channel (mayaiff, tiff(zfile) и alais) и только 8 bit IFF читается FUSION-ами правильно?
P.P.S. Глубокоуважаемый Joss, 8 bit-ные depth file я никогда не использую и вообще, у прынцыпе, не люблю работать с 8 bit files.
Joss, естественно, что z-buffer не фильтруется. Если посмотреть на process pipeline в RiSpec, то там нарисовано как image data и depth data попадают в imager и потом им renderman делает quantize и output, причем для z-buffer свой quantize, для data свой. Если выводить RGBAZ, то renderman автоматом использует box filter step 1 для RGBA, вне зависимости от того какой тип фильтра выставлен и выдает WARNING. Если использовать mayaiff display driver, то получается изврат, потому что, этот display driver пишет RGBA 8 или 16 bit, а z-buffer 32 bit float. Несмотря на то, что Nothing Real заявляют, что они тоже испольуют 32 bit float на channel, тем не менее есть разница, так как их float может быть < 0 и > 1, в то время как renderman, на основе camera clipping planes, делает им quantize м/у 0 и 1. Так что читать его Shake читает, но при попытке посмотреть с Depth Filter z-channel выглядит совсем не так, как должен. Кстати, на Highend3D тоже ничего умнее, чем конвертация в 8 bit TIFF, не придумали. По моему, самый простой выход - выводить z-buffer в 16 bit IFF файл из Maya, а RGBA делать prman-ом. Тем более, что IFF это родной формат для Shake. Что самое интересное, - именно этот способ у буржуев преподается в университетах на fine arts. Они его стандартно изучают, когда дело доходит до комбинации renderman + paint effects.
P.S.
1. Сорри, Kidd, не посмотрел на пост ( Z2TIFF ), заслал свой с работы, второпях.
2. Zfile format и shadow texture file format не одно и тоже.
3. У меня есть подозрение, что Pixar не смог пофиксить все баги связанные с Big и Little Endian нотациями, когда портировал renderman под NT. Три display driver поддерживают z-channel (mayaiff, tiff(zfile) и alais) и только 8 bit IFF читается FUSION-ами правильно?
P.P.S. Глубокоуважаемый Joss, 8 bit-ные depth file я никогда не использую и вообще, у прынцыпе, не люблю работать с 8 bit files.
>Ладно, шутки с MayaMan и sho в сторону.
Это не шутки, это правда жизни.
"Joss, естественно, что z-buffer не фильтруется. Если посмотреть на process pipeline в RiSpec, то там нарисовано как image data и depth data попадают в imager и потом им renderman делает quantize и output, причем для z-buffer свой quantize, для data свой. Если выводить RGBAZ, то renderman автоматом использует box filter step 1 для RGBA, вне зависимости от того какой тип фильтра выставлен и выдает WARNING. Если использовать mayaiff display driver, то получается изврат, потому что, этот display driver пишет RGBA 8 или 16 bit, а z-buffer 32 bit float. Несмотря на то, что Nothing Real заявляют, что они тоже испольуют 32 bit float на channel, тем не менее есть разница, так как их float может быть < 0 и > 1, в то время как renderman, на основе camera clipping planes, делает им quantize м/у 0 и 1. Так что читать его Shake читает, но при попытке посмотреть с Depth Filter z-channel выглядит совсем не так, как должен. Кстати, на Highend3D тоже ничего умнее, чем конвертация в 8 bit TIFF, не придумали. По моему, самый простой выход - выводить z-buffer в 16 bit IFF файл из Maya, а RGBA делать prman-ом. Тем более, что IFF это родной формат для Shake. Что самое интересное, - именно этот способ у буржуев преподается в университетах на fine arts. Они его стандартно изучают, когда дело доходит до комбинации renderman + paint effects."
Хмм.....спасибо, конечно за трактат, но я спрашивал о конвертации zfile во что-либо, читаемое любым из PC'шных композеров. Желательно AFX/Shake.
Кстати - чем плохо то, что RGBA - 8/16 bit, а Z - 32 bit? И в PRMan'е ну никак не получится сделать Z value < 0 - там минимум будет равен minClipPlane'у.
А буржуйский способ - тупой, так как можно написать простенький конвертер zfile2tiff, надо только разобраться с типами этих тифов. Кроме того есть еще и PRMan'овский displacement, ради которого я и считаю именно в PRMan'е.
"P.P.S. Глубокоуважаемый Joss, 8 bit-ные depth file я никогда не использую и вообще, у прынцыпе, не люблю работать с 8 bit files."
??????? А я требовал использования 8-битных файлов?
PS: Блин, какой-то испорченный телефон в треде....
Это не шутки, это правда жизни.
"Joss, естественно, что z-buffer не фильтруется. Если посмотреть на process pipeline в RiSpec, то там нарисовано как image data и depth data попадают в imager и потом им renderman делает quantize и output, причем для z-buffer свой quantize, для data свой. Если выводить RGBAZ, то renderman автоматом использует box filter step 1 для RGBA, вне зависимости от того какой тип фильтра выставлен и выдает WARNING. Если использовать mayaiff display driver, то получается изврат, потому что, этот display driver пишет RGBA 8 или 16 bit, а z-buffer 32 bit float. Несмотря на то, что Nothing Real заявляют, что они тоже испольуют 32 bit float на channel, тем не менее есть разница, так как их float может быть < 0 и > 1, в то время как renderman, на основе camera clipping planes, делает им quantize м/у 0 и 1. Так что читать его Shake читает, но при попытке посмотреть с Depth Filter z-channel выглядит совсем не так, как должен. Кстати, на Highend3D тоже ничего умнее, чем конвертация в 8 bit TIFF, не придумали. По моему, самый простой выход - выводить z-buffer в 16 bit IFF файл из Maya, а RGBA делать prman-ом. Тем более, что IFF это родной формат для Shake. Что самое интересное, - именно этот способ у буржуев преподается в университетах на fine arts. Они его стандартно изучают, когда дело доходит до комбинации renderman + paint effects."
Хмм.....спасибо, конечно за трактат, но я спрашивал о конвертации zfile во что-либо, читаемое любым из PC'шных композеров. Желательно AFX/Shake.
Кстати - чем плохо то, что RGBA - 8/16 bit, а Z - 32 bit? И в PRMan'е ну никак не получится сделать Z value < 0 - там минимум будет равен minClipPlane'у.
А буржуйский способ - тупой, так как можно написать простенький конвертер zfile2tiff, надо только разобраться с типами этих тифов. Кроме того есть еще и PRMan'овский displacement, ради которого я и считаю именно в PRMan'е.
"P.P.S. Глубокоуважаемый Joss, 8 bit-ные depth file я никогда не использую и вообще, у прынцыпе, не люблю работать с 8 bit files."
??????? А я требовал использования 8-битных файлов?
PS: Блин, какой-то испорченный телефон в треде....
>"P.P.S. Глубокоуважаемый Joss, 8 bit-ные depth file я никогда не использую и вообще, у прынцыпе, не люблю работать с 8 bit files."
??????? А я требовал использования 8-битных файлов?
PS: Блин, какой-то испорченный телефон в треде....<
>Уважаемый D'n'D так любит работать с 8-битными z-bufer'ами?<
Телефон не испорченый, а по времени сдвинутый. Часов так от 8 до 16, в зависимости от наличия времени, чтоб набрать ответ с долбаной виртуальной клавы, что на Yandex. Умение быть саркастичным, оставаясь дружелюбным - удел немногих и, явно, не мой. Я лучше не буду больше комментировать риторические вопросы.
Как получить 32 bits/pixel IEEE float TIFF из zfile понятно. Далее, для того, чтобы конвертировать 32 bits IEEE float TIFF во что нибудь читабельное, то не надо изобретать велосипед. Toolkit упомянутый Kidd-ом и мной идет с сорцами. Reading and Writing Various 2D Image Formats часть описания этого Toolkit как раз описывает, как использовать writing functions (int pixelsize; /* number of bits per pixel */), чтобы заставить конвертер писать то, что надо на выходе.
А если использовать Image Magic (http://www.imagemagick.org), то там даже перекомпилировать ничего не надо, только библиотеки tiff-v3.5.4.tar.gz с http://www.libtiff.org/ загрузить.
Если необходимо больше информации по форматам и конвертерам, то http://www.faqs.org/faqs/graphics/fileformats-faq/part2/.
Описание TIFF6.0 spec м/о утянуть здесь http://partners.adobe.com/asn/developer/PDFS/TN/TIFF6.pdf.
А буржуйский способ не тупой, он просто рассчитан на среднего буржуя, который 2x2 без калькулятора не может, а не на российских Левшей.
??????? А я требовал использования 8-битных файлов?
PS: Блин, какой-то испорченный телефон в треде....<
>Уважаемый D'n'D так любит работать с 8-битными z-bufer'ами?<
Телефон не испорченый, а по времени сдвинутый. Часов так от 8 до 16, в зависимости от наличия времени, чтоб набрать ответ с долбаной виртуальной клавы, что на Yandex. Умение быть саркастичным, оставаясь дружелюбным - удел немногих и, явно, не мой. Я лучше не буду больше комментировать риторические вопросы.
Как получить 32 bits/pixel IEEE float TIFF из zfile понятно. Далее, для того, чтобы конвертировать 32 bits IEEE float TIFF во что нибудь читабельное, то не надо изобретать велосипед. Toolkit упомянутый Kidd-ом и мной идет с сорцами. Reading and Writing Various 2D Image Formats часть описания этого Toolkit как раз описывает, как использовать writing functions (int pixelsize; /* number of bits per pixel */), чтобы заставить конвертер писать то, что надо на выходе.
А если использовать Image Magic (http://www.imagemagick.org), то там даже перекомпилировать ничего не надо, только библиотеки tiff-v3.5.4.tar.gz с http://www.libtiff.org/ загрузить.
Если необходимо больше информации по форматам и конвертерам, то http://www.faqs.org/faqs/graphics/fileformats-faq/part2/.
Описание TIFF6.0 spec м/о утянуть здесь http://partners.adobe.com/asn/developer/PDFS/TN/TIFF6.pdf.
А буржуйский способ не тупой, он просто рассчитан на среднего буржуя, который 2x2 без калькулятора не может, а не на российских Левшей.
Я обнаружил, что майка, оказывается, идёт с FLlib и ILlib - низко- и высокоуровневые либы для записи родного IFF. Вот только из описания там полупокоцанный man. :-\
Проще уж сразу в IFF писать, чем в этот тиф генерить.....
Правда у меня там пока что проблемы возникли с пониманием пары структур, точнее процессом их заполнения, однака разберёмся.
Проще уж сразу в IFF писать, чем в этот тиф генерить.....
Правда у меня там пока что проблемы возникли с пониманием пары структур, точнее процессом их заполнения, однака разберёмся.