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

PBR (статья на хабре)

Страницы: 1 2 3 4 5 6 Следующая »
#0
11:53, 12 мая 2017

В общем запилил статью по PBR, вот:
https://habrahabr.ru/post/326852/
Хотел просто ссылку тут оставить, возможно будет кому-то интересно.
p.s. Возможно промазал с разделом. Если так, то прошу модератора перенести тему.

#1
12:44, 12 мая 2017

Было бы неплохо в статье сделать акцент на PBR описываемый в готовящемся стандарте glTF 2.0, чтобы сделать совместимый рендерер.
Но видимо уже поздно.

#2
12:44, 12 мая 2017

Офигенная статья. Спасибо большое!

#3
12:46, 12 мая 2017

А че не на гд то, а?
Все нормальные пацаны на гд статьи пишут!

#4
13:01, 12 мая 2017

gkv311
> Было бы неплохо в статье сделать акцент на PBR описываемый в готовящемся
> стандарте glTF 2.0, чтобы сделать совместимый рендерер.
> Но видимо уже поздно.
Ага, поздно... или рано. Я вообще хотел в статье больше написать, но у меня сил хватило только на это. Итак жирная телега вышла.

The Player
> А че не на гд то, а?
> Все нормальные пацаны на гд статьи пишут!
Ну не сложилось у меня с gd.ru, ну прастити.

#5
13:08, 12 мая 2017

Отличная статья, в закладки...

#6
13:11, 12 мая 2017

Норм получилось.  Одобряем.

#7
13:41, 12 мая 2017

Отлично написано.

#8
14:21, 12 мая 2017

MrShoor

gkv311
Было бы неплохо в статье сделать акцент на PBR описываемый в готовящемся
стандарте glTF 2.0, чтобы сделать совместимый рендерер.
Но видимо уже поздно.

Ага, поздно... или рано. Я вообще хотел в статье больше написать, но у меня сил хватило только на это. Итак жирная телега вышла.

А вообще есть возможность прокомментировать как описанное в статье соотносится к продвигаемому PBR в glTF 2.0, или тема не изучалась ещё?

Просто мне, как разработчику далёкому от красивого и прекрасного, больше интересно не изучать научные труды о том, как сделать свою уникальную систему освещения "основанную на физике",
а внедрить наиболее подходящую, пусть и неидеальную, реализацию, совместимую хоть с какими-то стандартами (в данном случае glTF).

В статье, кстати, как-то не упоминается (или я упустил), что есть два существенно различающихся направления PBR:
- одно используется в играх и является упрощенным (но достаточно быстрым для сегодняшних GPU);
- второе направлено в сторону реалистичности (кинематограф) ценой медленного рендеринга.

#9
15:50, 12 мая 2017

MrShoor
> В общем запилил статью по PBR, вот:
ОМГ, хвала всевышнему, статья не про PBR в Unity.

#10
17:15, 12 мая 2017

Отличная статья, очень интересно, спасибо.
Буду ждать продолжения по тем 5 пунктам из заключения.

#11
17:28, 12 мая 2017

А зачем делать мультивыборку из уже подготовленной reflection текстуры с лодами, в которые, собстно, и запекают результат мультивыборки? Семплеры на железке поработать заставить впустую?

#12
17:40, 12 мая 2017

ArchiDevil
гм, а он это действительно делает? если да, то зря конечно) importance sampling'ом генерят мипы, которые затем одной выборкой выбирают.
тут правда есть один косяк, на который все забивают - т.к. обычный мипмаппинг становится не при делах, хайресная кубмапа начинает алиасить при уменьшении.
можно совместить выбор лода по шероховатости с выбором лода по обычным законам мипмапинга, но тут снова косяк - префильтрованные брдфом лоды отнюдь не похожи на обычные бокс-фильтром уменьшенные, выходит переблюривание, искажение воспринимаемой шершавости.
идеальный вариант, но для извращенцев - каждый префильтрованный мип хранить в своей кубмапе с обычной чередой боксфильтровых мипов - блендить между двумя ближайшими в шейдере лерпом.

#13
17:57, 12 мая 2017

ArchiDevil
мультивыборка зависит от угла взгляда на поверхность. такое нельзя заранее просчитать

#14
18:04, 12 мая 2017

Андрей5000
типа чтоб блик под углом вытягивался? не уверен, что 16 выборок хватит в таком случае, ну а выше не сильно практично. во всех играх и движках, что видел - это не работает, и кубмапные блики тупо изотропные (аля фонг).
надо тестить в общем на плейне под острым углом, а не на шарике.

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумГрафика