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

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

Страницы: 14 5 6 740 Следующая »
#60
16:12, 28 июня 2017

-=MASTER=-
как насчёт перестать воровать готовое и попробовать написать самому? алгоритм я расскал, читер уже тоже реализовал подобное.

#61
16:38, 28 июня 2017

Suslik
> как насчёт перестать воровать готовое и попробовать написать самому?
воровать ... )))  Ну почему же сразу воровать, на сорцах любой алгоритм выглядит более наглядно, в этом и причина. Нет - так нет. Кстати, а где ты говоришь описание алгоритма приводил? В нуль посте вроде только общие фразы...

#62
20:34, 28 июня 2017

>>Кстати, а где ты говоришь описание алгоритма приводил?
ну вот же:
1. Мой алгоритм основан на предыдущей схеме расчёта HBAO, используя репроекцию
2. Алгоритм по факту считает вторичное освещение всех пикслеей framebuffer'а на все пиксели
Берёшь HBAO и дорабатываеш. А можно не дорабатывать, а самому чё-нить выдумать интересного.

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

#63
0:54, 29 июня 2017

к слову, как ты сделал репроекцию? просчитывал пост-эффект на перспективной матрице?

#64
3:25, 29 июня 2017

Berns
> к слову, как ты сделал репроекцию? просчитывал пост-эффект на перспективной
> матрице?
храню mvp на текущем и предыдущем кадре и сохраняю gbuffer с предыдущего кадра. для каждого фрагмента в текущем кадре определяю мировую позицию и по ней определяю, где этот фрагмент был на экране в предыдущем кадре. далее сравниваю, что у того фрагмента совпадают цвет, нормаль и всё такое с новым фрагментом. если фрагменты совпали, то мы считаем, что они успешно перепроецировались и используем накопленную в них монте-карло информацию с предыдущих кадров.

#65
18:57, 29 июня 2017

с точки зрения производительности и учета переотражений это правильно. но какие мысли по устранению вследствие этого артефактов?
кроме того, я заметил ореолы возле лап жуков, могу предположить, что это хоть и блюрится с учетом глубины неоднородностей, но не учитывает расстояние до камеры, да и в целом, всякие рандомные абиенты выглядят ужасно без суперсемплинга, но он почти и не спасает если карта шума больше 16x16
лично я склоняюсь реализации SSGI на базе SSLR с несколькими рандомными векторами. полагаю, чтобы избежать артефактов в динамических сценах, придется отказаться от репроекции и рассчитывать кадр сперва с какими-нибудь скайлайтами, после чего  делать проход, а то и несколько, с учетом GI. если дойдут руки, повыпендриваюсь результатами

#66
18:49, 14 июля 2017

Вот такую любопытную демку нашёл: http://madebyevan.com/shaders/lightmap/
По схождению чем-то тоже напоминает демку Суслика.

#67
20:24, 14 июля 2017

g-cont
> Вот такую любопытную демку нашёл: http://madebyevan.com/shaders/lightmap/
> По схождению чем-то тоже напоминает демку Суслика.
лол, у них если отключить репроекцию (галка "Accumulate across frames"), то становится очевидно, что техника 1-в-1 как у меня в этой демке:
https://www.youtube.com/watch?v=_fm7rPsR6TA

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

#68
11:50, 15 июля 2017

Suslik
ну да, он там тоже написал, что можно ускорить процесс через растеризацию. Видимо идея просто витала в воздухе :)
Да неплохая ведь техника, для рассчёта тех же лайтмап на лету отлично годится.

#69
16:06, 15 июля 2017

моя попытка. 400 выборок. почти нет артефактов. но для такой техники нужны карты коррекции радиусов и переотражений.

https://pp.userapi.com/c639522/v639522166/2adf8/tqDjpH9JmWE.jpg
https://pp.userapi.com/c639522/v639522166/2adf0/VMfioJvYwiM.jpg
https://pp.userapi.com/c636523/v636523166/63025/kN4DRFZI8hE.jpg

#70
16:15, 15 июля 2017

Suslik
> однако, у них данные пишутся в лайтмапу, а для этого нужна дополнительная
> память и дополнительный uv-set

Много ли памяти нужно? Есть оценки?
Как на счёт программной генерации развёртки?

Berns
> но для такой техники нужны карты коррекции радиусов и переотражений.
Что за карта коррекций? Можно поподробнее?

#71
16:27, 15 июля 2017

Что за карта коррекций?

да вся техника - это динамическая расстановка очень большого числа ламп, дополнительный проход геометрии, который строит карту глубины и цвета размером 20x20. можно и в скринспейсе делать, только буферы приходится блюрить.  ну а поскольку это источники типа "проектор", его радиус должен зависеть от размера полигона, иначе поверхность будет выглядеть будто на нее положили гирлянду

#72
16:45, 15 июля 2017

Berns
> моя попытка. 400 выборок. почти нет артефактов. но для такой техники нужны карты коррекции радиусов и переотражений.
результат выглядит неверно. например, единственные лучи, которые могут осветить чайник снизу — это отражённые от стола. но стол чёрный, поэтому ничего отражать не должен, однако, чайник всё равно освещён со всех сторон. даже прямых теней не видно, так что об артефактах пока заботиться рано, нужно сначала сделать, чтобы метод сходился к чему-то околореальному.

> да вся техника - это динамическая расстановка очень большого числа ламп,
> дополнительный проход геометрии, который строит карту глубины и цвета размером
> 20x20.
это RSM что ли? если так, то он в любом случае не учитывает occlusion и результат никогда не сойдётся ни к чему интересному, даже если исправить все ошибки.

Panzerschrek[CN]
> Много ли памяти нужно? Есть оценки?
> Как на счёт программной генерации развёртки?
памяти в идеальном случае понадобится пропорционально суммарной площади геометрии в сцене. то есть если взять сцену, представляющую из себя губку, да или просто лес, у которого суммарная площадь всех деревьев полуается огромной, то затраты памяти взлетят до неприемлемых величин. энивей, в 70% предпросчитанные лайтмапы — это нормальное решение, которое и так прекрасно подходит, меня больше интересует, что делать с оставшимися 30%, где по тем или иным причинам их использовать нельзя.

#73
17:40, 15 июля 2017

но стол чёрный, поэтому ничего отражать не должен

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

результат никогда не сойдётся ни к чему интересному

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

#74
18:31, 15 июля 2017

Berns
> поэтому и нужны карты коррекции, не из диффуза же высчитывать. самый удачный
> пример - последний скрин. вообще, эта техника мне нужна для освещения
> полузакрытых пространств, ну типа отскока света от стены от того же фонарика,
> или проникновение солнечного света через окно в комнату, не каждый ведь раз
> ставить источник освещения перед окном с зависимыми параметрами от солнца.
> причем почти не жрет ресурсов.
похоже на какие-то выдумки. какие ещё карты коррекции, если за это отвечает BDRF?

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

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