Войти
ПрограммированиеФорумГрафика

Конвертирование текстурных PBR-карт (4 стр)

Страницы: 1 2 3 4
#45
22:48, 9 окт. 2019

vindast
> все текстурные фильтры будут работать не так как ты ожидаешь
Прям черный ящик)

У нас есть фильтрация между текселями одного мипа (билинейная) и между мипами (трилинейная/анизотропная).

Так как я передаю точные текстурные координаты, то между соседними текселями текстуры работает стандартная фильтрация и тут вообще не нужно ничего делать.

Вопрос только в фильтрации между миппами. Но и тут все просто - функция textureLod берет на себя всю эту работу. Единственный момент - правильно вычислить LOD.
В 2010 году это можно было сделать только вручную, по формуле, указанной в стандарте OpenGL - "8.14.1 Scale Factor and Level-of-Detail". Тоесть никакого черного ящика. Но повторюсь - это было в 2010 году, сейчас есть функция textureQueryLod, которая возвращает тот самый лод который бы использовался для обычной выборки через texture. Тоесть и тут нет никакой магии. Все абсолютно контролируемо.

И опять же повторюсь - я уже делал это в 2010 году под OGL 2.1, пытаясь обойти ограничения deferred shading'а, так что результат я знаю, проблемы были, но они были совсем другого рода и сейчас их даже нет смысла вспоминать.

Чего я пока не знаю, это на сколько этот алгоритм будет производительным (по гибкости он даст фору классическому практически по всем пунктам).

vindast
> что убьет весь профит.
Вот это я и хочу выяснить. Тоесть у меня изначально нет иллюзий что он будет работать с такой же скоростью как и классический deferred shading, вопрос только в том, какая будет просадка. А уже на основе этого уже определять области применения.

Но и тут не все просто. Одно дело - синтетические тесты, тоесть одну и ту же картинку с одними и теми же материалами вывести с использованием двух разных техник. Совсем другое дело - встроить это в общий конвеер, к примеру - использовать возможность бесплатного буфера выбора, или практически бесплатного антиалиазинга. Вот тут уже можно выйти на ноль или даже получить профит от использования такого подхода, или нет :)


#46
23:39, 9 окт. 2019

Fantom09
> Если заменить materialID на ObjectID - моя техника ничем не будет отличаться

у объекта может быть несколько материалов

#47
(Правка: 0:23) 0:00, 10 окт. 2019

innuendo
> у объекта может быть несколько материалов

Да, сорь, забыл уточнить момент (простительно, это ж не статья)) -  это из темы инстансинга.
Тут вопрос как именно рисуется конкретная сцена.

Дело в том, что у меня сцена выводится через MultiDrawIndirect, там по сути каждый сабмеш объекта  рисуется как отдельный объект (со своим материалом), потому тут ObjectID это ID сабмеша в списке, а у него уже есть инфа о родителе. Тоесть конечный выбор "выбранного объекта" происходит уже на стороне CPU (хотя можно включить инфу о родителе и в структуру самого сабмеша, но я пока не вижу в этом необходимости). Бонусом - улучшается детализация такого выбора, тоесть я точно буду знать что юзер кликнул на книжку на полке а не на саму полку, или выбрал руку персонажа а не персонажа.

Этот ObjectID можно и иначе вычислять или явно передавать, зависит от организации сцены/рендера

P.S. чтоб сильно не оффтопить - в дополнению к шейдеру из поста 8 можно еще там же глянуть конвертеры:
https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/K… ness/examples

А вот тут в конце есть интересная табличка: https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/K… larGlossiness

Там приводятся правила как юзать разные вокфлоу, если для объекта задан либо один сет материалов либо оба, а так же рекомендации по производительности. Вот как раз это очень легко реализовать через описанный выше подход, так как по MaterialID будет доступен полный сет всех карт, включая  metallness и specular (если они есть конечно), и уже в шейдере легко можно выбрать какой из алгоритмов лучше юзать и с каким набором.

Но опять же - это все лишь частные случаи, "теоретических" возможностей там намного больше, но у меня и так сильно большие посты получаются)

#48
(Правка: 4:55) 2:23, 10 окт. 2019

BingoBongo
> float16 (view space z position)
Позиция фрагмента полностью восстанавливается из буфера глубины на основе zNear, zFar и инвертированной проекционно-видовой матрицы.

vindast
> Это уже безумие.
Да кто ж такое сказал-то! А для чего по твоему разработан формат сжатия BC6H?!! Как разберусь, где в BC6H_SF отваливаются отрицательные значения, буду скармливать шейдеру signed float текстуры нормалей, чтобы не конвертировать их каждый кадр для каждого фрагмента.

#49
12:12, 10 окт. 2019

Daniil Petrov
> чтобы не конвертировать их каждый кадр для каждого фрагмента.

скажи это афторам 3DC :)

#50
12:41, 10 окт. 2019

Daniil Petrov
> Позиция фрагмента полностью восстанавливается из буфера глубины на основе
> zNear, zFar и инвертированной проекционно-видовой матрицы.
И?

#51
20:04, 10 окт. 2019

https://github.com/TheRealMJP/DeferredTexturing

#52
21:48, 10 окт. 2019

0xc0de
> https://github.com/TheRealMJP/DeferredTexturing
>
Ого, спасибо! Есть что почитать. Щас глянул - количество статей в интернете существенно увеличилось, с момента как я в последний раз изучал эту тему.

Страницы: 1 2 3 4
ПрограммированиеФорумГрафика