Краткий курс компьютерной графики: задание карт нормалей в касательном пространстве

[Mercury13]

Для меня эти дела ещё сложноваты, но я рискну.

Мой ответ

Чтобы не были видны грани и рёбра, ведь мы имитируем многогранником криволинейный объект.

Если быть более точным: чтобы при небольших поворотах модели или источника света освещение вело себя так, как будто освещено нечто криволинейное, а не вскрывало прямолинейные рёбра и плоские грани.

[haqreu]

Спасибо, правильно.

[Mercury13]

Для тех, кто любит игры и не хочет решать задачу

P.S. The Witness — хорошая игра, но мы пытаемся делать что-то близкое к реальности.

[haqreu]

А вот это было лишним, как мне кажется...

[entomolog]

Для отрисовки каждого пикселя растеризатор нам даёт барицентрические координаты пикселя (альфа, бета, гамма). Это означает, что текущий пиксель имеет пространственные координаты p = альфа p0 + бета p1 + гамма p2. Мы интерполируем текстурные координаты ровно так же, затем интерполируем и вектор нормали:

Если я правильно понимаю, то линейно интерполировать текстурные координаты и нормали после проецирования (а раз речь идет о растеризаторе, то получается после) можно только в случае ортогональной проекции. Правильно?
В случае с перспективной проекцией, там будут искажения. Я когда-то очень давно писал свой софтовый рендер и уперся в эту проблему. Несколько дней дебажил, думал что проблема в коде, а оказалась — в математике.
Забавно то, что на моем Asus A686 (Windows Mobile 5.0) по какой-то причине растеризатор как раз не учитывал перспективные искажения, получались точно такие же забавные артефакты.

[haqreu]

В целом да, перспектива вносит нелинейные искажения. Их коррекция подробно описана тут.

[entomolog]

Спасибо! Я когда-то давно взял готовый рецепт, но не понял как оно работает, а тут вы все подробно расписали, спасибо!

[kashey]

Есть еще один интересный момент, про который забыли сказать — само хранение и представление нормалей.
Дефакто подразумевается, что они приходят в RGB текстуре, где каждая компонента меняется в -127:127.
На самом деле это не так. Из-за того, что данные хранятся в нормализованном виде, часть значений не может быть использована.
Есть другой подход – "Octahedron normal vector encoding" – представление нормали как луча пересекающего октаеэдрон, или пирамиду. В том числе конечный 2д вектор представляется как 2д вектор, и чуть более "линеен".
Сам про это читал в документах valve, но сейчас не могу найти документ :(
Но в статье https://knarkowicz.wordpress.com/2014/04/16/octahedron-normal-vector-encoding/ есть пара ссылочек на докумены с тервером…
PS: Картинка для привлечения внимания:

[haqreu]

Признаться честно, я не то, что забыл, я никогда и не знал про другие способы хранения. Спасибо! Буду читать на досуге.

[kashey]

UPD: http://media.steampowered.com/apps/valve/2015/Alex_Vlachos_Advanced_VR_Rendering_GDC2015.pdf, 48 слайд, но лучше смотреть с начала.

[ef_end_y]

Раздел по мультисемплингу будет?

[haqreu]

Будет, но дату доставки обещать не могу.

[Hertz]

Поправьте меня, если я не прав, но ведь первая normal-map задана скорее в object space, а не в world space. Чтобы трансформировать её в world space, нужно умножить на транспонированную обратную model-матрицу.
P.S. А репер — устоявщаяся терминология? Википедия говорит Поверхность.

[haqreu]

Да, это так, но такие детали я опускаю за очевидностью. В моём движке model матрица единична.