GPGPU, считалка нормалмапа

Небольшой брейн-дамп о считалке нормалмепа.

[23:01] <Zemedelec> захотелось считать нормалмап по лов-поли + хай-поли и уникальному маппингу на лов-поли

[23:01] <Zemedelec> почему – хз
[23:01] <Zemedelec> обжект спейс покатит
[23:01] <Zemedelec> не охота математики
[23:02] <Zemedelec> так вот
[23:02] <Zemedelec> рендим лов-поли меш, в текстурнъй спейс его маппинга – позиции и нормали – в fp32 таргетъ
[23:03] <Zemedelec> потом читаем их
[23:03] <Zemedelec> ето позиции и ориентации наших камер
[23:03] <Zemedelec> ну, да, надо будет и тангенту тоже отрендить
[23:04] <Zemedelec> или прямо тангенту и битангенту, вместо нормали
[23:04] <Zemedelec> соответно – имеем набор матриц, столько, сколько текселей в нормалмап текстуре
[23:05] <Zemedelec> – чернъе, но ето несущественно
[23:05] <Zemedelec> 1к на 1к -> 1м рендеров хай-поли меша
[23:05] <Zemedelec> хуже, 2м, ибо надо будет в обе сторонъ рендить
[23:08] <Zemedelec> начинаем ставить вьюпорт по бекбуферу, там может и не 1×1 пиксель, а больше, для усреднения, рендим весь меш в depth + его нормали в цвет
[23:08] <Zemedelec> как кончится RT, локаем, читаем, продолжаем опять
[23:08] <Zemedelec> 1м рендеров хай-поли меша однако будут зверски тормозить
[23:09] <Zemedelec> пусть 2м треугольника в нем
[23:09] <Zemedelec> 2м рендеров
[23:15] <Zemedelec> Г80, 300м/сек допустим
[23:15] <Zemedelec> 4м пер тексел нужно
[23:15] <Zemedelec> 75 текселей в сек
[23:16] <Zemedelec> 4 часа
[23:17] <Zemedelec> или 3, если чернъе пиксели и 400mt/sec на G80
[23:17] <Zemedelec> ужос короче
[23:17] <Zemedelec> мне так кажется, или софтовое решение с йерархией будет работать на порядок бъстрее?
[23:18] <Zemedelec> конечно, можно прикрутить и тут йерархию
[23:18] * Rageous читает и пьет пиво. понимал бы что-нить в графике – помог бы )
[23:18] <Zemedelec> камера – лучь, тест луча с йерахией наипростейшей – простое дело
[23:20] <Zemedelec> 2м треугольников, нужна елементарная йерархия и тест ее с лучом – на въходе несколько интералов иб
[23:20] <Zemedelec> ib
[23:20] <Zemedelec> или прямо vb+ib
[23:21] <Zemedelec> хоть какое bvh подойдет
[23:23] <Zemedelec> в идеале, да и по идее – камера очень локальна к поверхности
[23:23] <Zemedelec> так что bvh можно сильно измельчить
[23:24] <Zemedelec> т.е. дальше чем какого-то E от позиции камеръ нет смъсла рендить листья bvh
[23:25] <Zemedelec> смело предположим, что ето 1/10 от линейного размера бокса модели
[23:25] <Zemedelec> 1к меньше поликов
[23:25] <Zemedelec> т.е. где-то 2к-4к
[23:25] <Zemedelec> или в 1к раз бъстрее
[23:26] <Zemedelec> 11 сек
[23:26] <Zemedelec> bvh, то-другое, 15 сек
[23:27] <Zemedelec> надо посмотреть, как ето дело работает в MAX-e
[23:27] <Zemedelec> просто на вскидку, кода мало и он довольно тупой
[23:27] <Zemedelec> построение bvh, деление пополам по длиннейшей оси бокса
[23:29] <Zemedelec> лучь vs bvh – гм, вроде просто
[23:30] <Zemedelec> 1к vb/ib, въдержит ли рантайм… надо тестить
[23:32] <Zemedelec> можно и не bvh, можно грид, только нет гарантии что там под 64к индексов будет в клетке
[23:33] <Zemedelec> 10x10x10 грид, йерархичное построение
[23:33] <Zemedelec> гм, ето конечно тоже отнимет некое время… :)
[23:33] <Zemedelec> некое время даже отнимет чтение с диска :(

[23:35] <Zemedelec> идеи?

  • CEMEH

    Мне кажется, можно рендерять не per-texel, а per-polygon на low-poly, ага? Там же плоскость, можно вьюпорт по ней.
    И отсекать умно как-то, да…

  • IronPeter

    Так нельзя. Потому что tangent space curved. Надо чтобы все стыковалось на уровне ребер треугольников.

    Вообще, есть более правильное железо чем GPU. Правильное железо умеет 7 гигабайт в секунду DMA запросами по 128 байт случайным доступом по памяти. Одним DSP процессором. DSP процессоров у него 6 штук. Вместе они нагружают шину под 20 гигабайт в секунду. Каждый умеет 256 локальной памяти и 25 гигафлоп, сбалансированных с загрузкой-выгрузкой.

    На таком железе и нормалмапы считать и освещение и AO – удовольствие. И тесселировать террейн. И резать геометрию по-разному.

  • Sergei_am

    Прикинь, сколько времени оно будет 1М нормалмап считать для 1м модельки?

  • IronPeter

    ну как бы и прикидывать нечего. IBMовский трассировщик лучей делает 12 миллионов трейсов в секунду. на 6 SPU. На 1M сценах.

  • Sergei_am

    Тут даже не настоящие трейсъ, т.е. не нужна вся сцена.
    Значит на порядок, 10-20 раз – если трейс через всю сцену, а иначе вообще порвет…

  • Vlad Shcherbina

    >рендим лов-поли меш, в текстурнъй спейс его маппинга – позиции и нормали – в fp32 таргетъ
    Я правильно понимаю, что это для того, чтобы камеры, смотрящие на спорные тексели, принадлежащие нескольким граням, смотрели на них из какой-то промежуточной позиции? Т.е. рендерить надо на самом деле в большем разрешении, а потом усреднять?

    Если так, то можно нормали рисовать per poly, а потом уже эти poly помещать в окончательную текстуру, с тем же усреднением на рёбрах. Строго говоря, получится не эквивалентно описанному, но наверное тоже терпимо.

  • Sergei_am

    Конечно, рендер идет в вьюпорт не 1×1, а больше. Так что да, усреднение.

  • http://www.deep-shadows.com/hax/ hax

    GPGPU:
    GPU Mapper http://gpum.codingcorner.net/

    Distributed computing:
    ATI NormalMapper for hxGrid: http://www.deep-shadows.com/hax/hxgrid.htm
    xNormal for hxGrid: http://www.xnormal.net/