Согласен, не факт) При небольшом количестве сэмплов может не упадет и останется на том же уровне.
Однако вопрос не в умножении vs обращение в память. При расчете непрямого освещения в любом случае придется обращаться к 3 текстурам: позиция, нормаль, flux или глубина, нормаль, flux. При том сэмплинг идёт по случайным координатам, так что с кэшем все грустно и так и так.
В карту глубины попадут значения, которые видны из источника освещения. Это будет задняя часть стены.
Во время расчета прямого освещения это означает, что передняя часть не видна, и передняя часть стены будет черной. (Если не светит глобально ambient)
А вот во время расчет непрямого освещения получиться:
Когда оно будет рассчитываться для пикселя из передней части стены, то сэмплируя соседние тексели (виртуальные источники освещения rsm), получиться, что они все на задней части стены. А это означает, что они не освещают наш пиксель (рассчитываться с помощью скалярного произведения) и соответственно дадут нулевой вкляд в непрямое освещение, так как задняя часть стены не видит переднюю.
Однако наш первоначальный источник освещения может находиться чуть выше этой стены и свет попадёт на пол перед передней частью стены. И вот виртуальные источники освещения от пола вполне могут осветить стену.
Конечно для всех этих вычислений используется карта позиций, нормалей и flux из RSM.э, а карта глубины нет. Но от нее не избавиться, ибо без нее не выйдет сформировать другие карты RSM.
Резонный вопрос)
И да, это сделано в целях экономии в вычислениях, так как каждый тексель становиться новым виртуальным источник освещения. Если для каждого восстанавливать позицию из глубины, то FPS сильно упадет.
Да, согласен, проблема с «ореолами» останется, но не будет настолько заметной после смешивания.
Автор и не пишет, что проблема полностью разрешиться алгоритмом, множество параметров у него подбирается вручную и передаются в качестве uniform, экспокоррекция в том числе (uExposureCompensation)
Хотя на самом деле ее стоит рассчитывать. Есть отличная статья на эту тему knarkowicz.wordpress.com/2016/01/09/automatic-exposure
В ней рассказывается, что экспокоррекцию рассчитывают из L по формуле, либо зависимость настаивается художниками и функция храниться в 1D текстуре. Второй вариант предпочтительнее
Согласен, не факт) При небольшом количестве сэмплов может не упадет и останется на том же уровне.
Однако вопрос не в умножении vs обращение в память. При расчете непрямого освещения в любом случае придется обращаться к 3 текстурам: позиция, нормаль, flux или глубина, нормаль, flux. При том сэмплинг идёт по случайным координатам, так что с кэшем все грустно и так и так.
:)
В карту глубины попадут значения, которые видны из источника освещения. Это будет задняя часть стены.
Во время расчета прямого освещения это означает, что передняя часть не видна, и передняя часть стены будет черной. (Если не светит глобально ambient)
А вот во время расчет непрямого освещения получиться:
Когда оно будет рассчитываться для пикселя из передней части стены, то сэмплируя соседние тексели (виртуальные источники освещения rsm), получиться, что они все на задней части стены. А это означает, что они не освещают наш пиксель (рассчитываться с помощью скалярного произведения) и соответственно дадут нулевой вкляд в непрямое освещение, так как задняя часть стены не видит переднюю.
Однако наш первоначальный источник освещения может находиться чуть выше этой стены и свет попадёт на пол перед передней частью стены. И вот виртуальные источники освещения от пола вполне могут осветить стену.
Конечно для всех этих вычислений используется карта позиций, нормалей и flux из RSM.э, а карта глубины нет. Но от нее не избавиться, ибо без нее не выйдет сформировать другие карты RSM.
Надеюсь, я смог ответить)
И да, это сделано в целях экономии в вычислениях, так как каждый тексель становиться новым виртуальным источник освещения. Если для каждого восстанавливать позицию из глубины, то FPS сильно упадет.
Автор и не пишет, что проблема полностью разрешиться алгоритмом, множество параметров у него подбирается вручную и передаются в качестве uniform, экспокоррекция в том числе (uExposureCompensation)
Хотя на самом деле ее стоит рассчитывать. Есть отличная статья на эту тему
knarkowicz.wordpress.com/2016/01/09/automatic-exposure
В ней рассказывается, что экспокоррекцию рассчитывают из L по формуле, либо зависимость настаивается художниками и функция храниться в 1D текстуре. Второй вариант предпочтительнее
С glDepthRange конечно смешно получилось))
Про glDepthRangef не знал, спасибо)