Комментарий к Статье Создание low модели головы человека с картой нормалей от А до Я.
В данной статье автор рассказывает о применении карт нормалей, чтобы добиться реалистичности низкополигональных моделей. В статье описываются техники построения карт нормалей при помощи программы NVIDIA Melody и плагина NormalMapFilter.
>ВНИМАНИЕ: текстура должна быть квадратной, и разрешение стороны должно быть кратно степени 2 (256х256, 512х512 … и т.д.),
Чем это обусловлено, что текстура должна быть обязательно квадратной?? Там же указывается и высота и ширина... в самой melody, а не просто "размер".
Спасибо за комменатрий, возможно я несколько жестковато выразился по поводу квадратных текстур (melody способен работать и с прямоугольными текстурами, на ваш выбор). Но в статье подразумевается, что мы делаем модель для игрового движка, и поэтому лучше придерживатся квадратных текстур (256х256, 512х512 … и т.д.) , обусловлено это тем, что для расчета мипмэп уровней удобнее располагать квадратной а не прямоугольной текстурой.
--
бр.. после ZBrush2+планшет получение карт нормалей из Hi/Low poly для органических объектов кажется очень неестественным.
Любопытно, а что надо из хардвера, чтобы можно было рендерить модель с NormalMap.
Есть ли какие-нибудь ограничения или программы могут рендерить его и софтваре ?
насчет харда это не ко мне вопрос.
ES_s2
Не вижу сложностей для движка в создании мип-уровней для не квадратной текстуры :) Может укажите чем удобнее? MIP-уровни могут быть не обязательно вплоть до 1х1, может минимальным уровнем быть и 1х2... 2х4,4х8,...,256х512.
Может я и ошибаюсь, но тогда хотелось бы услышать реальные аргументы в пользу квадратных текстур :)
KriGH
Преимущественно карты нормалей нашли применение в технологии под названием Bump Mapping (создание псевдорельефа). Производить расчёт в масштабе реального времени для моделей с normal map стало возможным при появлении вершинных и пиксельных шейдеров. Как известно, начало этому положили карты GeForce3 и Radeon 8500, осуществляющие полную аппаратную поддержку возможностей DirectX 8 и ставшие базовым минимум для последующих реализаций движков. Так что теоретически на этой линейке карт это возможно, другой вопрос - скорость. В своё время Джон Кармак был разочарован реализацией обработки пикселя в DirectX 8 и GeForce3. Причина тому - "неудобная" архитектура конвейера и ограничение на количество операций над пикселем. От этих проблем избавили карты на типе GPU NV3x: FX5200 (NV34), FX5600 (NV31), FX5900 (NV35) или соответствующие им Radeon 9200, Radeon 9600, Radeon 9800. Так что это можно назвать сиюминутным "полем боя". Дальше - чипы GPU ATI R4xx и NV4x от nVidia - лидеры mainstream'а.
Принудительная software обработка возможна только в DirectX (OpenGL в обязательном порядке требует аппаратной поддержки). Однако если Вы собрались рендерить модель в игре программно, то Вам следует учесть, что большую часть времени Ваш компьютер будет играть сам с собой ;-)
Dexus
Заранее извиняюсь, так как вопрос адресован не мне, но очень уж хочется ответить :)
Действительно, расчёт mip-map уровней для "не квадратной текстуры" не представляет никакой сложности для движка, главное - это время и скорость с которой он этот расчёт завершит. Например, в OpenGL существуют расширения EXT_texture_rectangle и NV_texture_rectangle, позволяющие обойти запрет на использование текстур размера не кратного степеням двойки (non-power-of-two dimensioned), заложенный инженерами-проектировщиками OpenGL. Однако на практике применение таких текстур вызывает общее снижение производительности. В целом, потери производительности можно назвать незначительными, но если учесть, что современные движки и без того загружены, то это нежелательное свойство. Кроме того, у такого рода текстур наблюдаются проблемы с режимами mip-map фильтрации: от появления артефактов, до полного её отсутствия. К существенным плюсам таких текстур относится то, что, предоставляя машине данные с которыми её не удобно работать (не комфортно ей "переламывать" такие числа :-)), мы рационально используем её память, размещая в ней меньше данных.
.dmd
Степени двойки - это конечно понятно. это фактически обязательный фактор. А вот именно неквадратность. ведь текстура 256х512 - не квадратная, но размерность кратна степени 2.
Если текстуру дорастягивать до 512х512, то биндинг текстуры будет занимать в 2 раза больше времени, ибо при пересылка текстуры в видюху важен только объем.
Если текстуру разбивать на две 256х256, то придется два раза переключать стейты чтобы нарисовать.
Если досжать до 256х256 - то может быть потеря качества...
Написанный мной тест по использованию текстур 512х512 и 1024х256 не показал никакой разницы в скорости.
.dmd
Присоединяюсь к сказанному Dexus.
Я допускаю теоретическую возможность некоторой потери производительности при использовании неквадратных текстур, но не более чем теоретическую.
Скажем, в тестах на отношениях сторон 1:1 и 1:2 никакой разницы я не наблюдал.
Да что вы так к этим размерам привязались? Может это обусловлено тем что голова прерасно разворачивается в квадратную текстуру? Я вот поставил указанный в статье инструментарий, буду смотреть и своим дизайнерам покажу %)
ES_s2
А почему была выбрана техника патчей? Чем не подходит, например, создание низкополигональной модели, потом дорезка её и тесселяция с последующим приданием нужной округлости?
azazello
А можно статью на тему ZBrush2? Интересно было бы посмотреть-почитать. Наверняка эта штука денег стоит, а ты, как пользователь, бы рассказал что там и как, а мы бы издали пооблизовались.
GLoom
усложнение лоу модели - это очень трудоемко, и чревато ошибками, поэтому предпочтительнее выбрать моделирование в патчах\сплайнах. во первых удобнее ( потому что оперируем кривыми, и модель "не отягощена" большим количеством полигонов как в mesh), во вторых с оптимизацией никаких проблем, указываем шаг и получаем требуемую лоу модель (вот ее потом можно подредактировать через editmesh)
--
моделирование в патчах\сплайнах можно освоить за несколько дней, главное побольше практики.
Dexus
aruslan
Да, действительно, вопрос об обязательном использовании квадратных текстур весьма спорен. В одном из проектов framework'а, столкнувшись с подобными вопросами, мы решили провести несколько скрупулёзных тестов. Система настраивалась на оптимальное быстродействие, и проводились неоднократные замеры времени перевода текстуры во внутренний формат OpenGL без использования сторонних библиотек и при условии, что ни одна текстура не превышает размера другой по одному из измерений (при замере использовались таймеры: GetTickCount(), QuerryPerformanceCounter(), timeGetTime()). Т.к. современное железо на удивление легко справляется с загрузкой единственной текстуры, то мы "грузили их пачками" :-) (именно это должно было предотвратить появления одинаковых результатов).
Разница в результатах (не большая, т.е. фактически незаметная для человека) была исключительно в пользу квадратных текстур, а при обрисовке сцены результат был на 2 - 4 fps больше. Исходя из этого, было принято решение при возможности, но не в ущерб качеству, использовать квадратные текстуры. Это всё, что я могу сказать. :)
Я убрал выражение про квадратность.
Тема в архиве.