Suslik в заговоре с Global Illumination (2 стр)

Да, статейка не помешала бы. Что хочу узнать? Ну собственно банально как происходит расчет ги для конкретного пикселя.

Андрей5000

Suslik
> статью напишу, если будет больше чем двум человекам интересно. и надо
> определиться, про что именно люди хотят узнать.
Мне интересно, но статью не надо. Мне интересно сами проходы и что в каждом проходе считал вкраце (Возможно это и статья будет).

Кстати использовал  несколько проходов заместо 1?  Как пример заместо 16 выборок в 1 проходе делать. 2 прохода по 8 выборок. И на 2 проходе использовать данные предыдущего. Получается как бы 64 выборок.
Использовал разбиение экрана на 4 части чередованием пикселей? На каждой части используешь свою маску выборок. а потом результат объединять.
Вмести эти методы + еще можно на первый проход подать данные с предыдущего кадра но с учетом движения, дают быстрый и хороший результат.

susageP
А что за данные с первого прохода там можно использовать?

Андрей5000
> А что за данные с первого прохода там можно использовать?
Те которые считаем.

Очень упрощенна.
В начале у нас есть текстура с первичным освещением.
На первом этапе считаем сколько света попадает в точку от X точек -> получаем текстуру первого отражения.
На втором этапе мы считаем сколько света попадает в точку от X точек с учетом текстурой первого отражения -> получаем текстуру второго отражения.

Suslik
Хорошо выглядит!, (+без возни с развертками под LM и все такое), посмотреть бы на красивом, затекстуреном интерьере с отражениями\спекуляром. Скорость вполне достаточная для вьювера интерьеров. Мне тоже было бы интересно почитать статью по реализации.

susageP
А ну для баунса да, согласен.

susageP
>
> Кстати использовал  несколько проходов заместо 1?  Как пример заместо 16
> выборок в 1 проходе делать. 2 прохода по 8 выборок. И на 2 проходе использовать
> данные предыдущего. Получается как бы 64 выборок.
>
> Вмести эти методы + еще можно на первый проход подать данные с предыдущего кадра но с учетом движения, дают быстрый и хороший результат.
в моём ssgi используется reprojection с экспоненциальным accumulation buffer'ом и depth-aware blur, то есть выборки накапливаются с предыдущих кадров и от соседних пикселей одновременно.

> Использовал разбиение экрана на 4 части чередованием пикселей?
использовал такую технику в imperfect shadow maps. создаёт характерный повторяющийся шум, поэтому пока что я отказался от этого подхода и просто выбираю случайные направления для каждого пикселя, без фиксированных чередующихся блоков.

Ruslan
> +без возни с развертками под LM и все такое
собственно, это может показаться незначительным, особенно любителям запекать освещение в оффлайне. но на практике отсутствие дополнительной развёртки и уникальной текстуры для каждого объекта — это очень важный момент. например, в poe в принципе нельзя запечь освещение, несмотря на то, что почти вся геометрия статична, потому что разные тайлы используют одни и те же текстуры, а вторичное освещение для них должно быть разным. плюс скринспейс гораздо легче впилить в существующий rendering pipeline, чем любую другую технику.

> посмотреть бы на красивом, затекстуреном интерьере с отражениями\спекуляром
у меня велосипедный загрузчик моделей, даже без текстур, о pbr материалах вообще речи нет, так как использую его только для демок. так что следующим шагом уже просто попытаюсь впилить в наш проект, да посмотреть, как это выглядит в итоге.

Очень круто, но надо чем-то затыкать отсутствие данных за экраном и загороженными пикселями, иначе слишком плавает всё. Может быть лайтпробы с мини-гбуфером развешать и читать их, где экранной инфы нет - но это здорово всё усложняет.

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

Suslik
Красота!
Если камера top-down то круто бы сделать труъ освещение от небосвода (особенно для хмурой погоды и закатов/рассветов)

Zegalur
> Если камера top-down то круто бы сделать труъ освещение от небосвода (особенно
> для хмурой погоды и закатов/рассветов)
да, достаточно лишь небольшой модификации к SSAO шейдеру, чтобы учитывать только нижнюю полусферу при интегрировании.

Zegalur
> Красота!
спасибо

Suslik
По SSGI зачет! Я однажды пытался делать подобное во времена массовой эпидемии SSAO после выхода кризиса... нереально тупило и радиус выборки был довольно ограничен. Короче я думал, что такого качества как у тебя добиться нереально с нормальным фпс.

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

Che@ter
> Я вот ударился в воксели и реально в местах не хватает такой детализации
> небольших деталей.
вот именно. только реализовав алгоритм вроде Radiance Hints, LPV или VCT можно понять, насколько важен near-field occlusion, который в них напрочь отсутствует(хотя VCT в этом плане лучше остальных). конечно, его можно аппроксимировать обыкновенным SSAO, но это же не то. хочется, чтобы это была одна техника. кто не любил, им не понять :) спасибо за поддержку.

За статью! Разжуйте плз немного для чайников..