Я тестирую ограничения движка Doom 3 - в отношении максимального размера карты.
Я заметил некоторые ошибки точности тени трафарета, которые становятся более выраженными, когда объекты удаляются все дальше и дальше от начала карты.
в положении: -10901 -18214 -11204
в положении: -10802 -26483 -19383
в положении: -10802 -34683 -27540
Я полагаю, что эти ошибки были названы «теневыми трещинами», но я не уверен, как эти артефакты назывались ранее.
Почти все артефакты появляются вдоль границ света / тени - что можно увидеть здесь:
Кто-нибудь видел этот тип графического артефакта раньше с трафаретными тенями? Как они называются? В чем причина?
Больше примеров:
Это ванильный движок Doom 3, который можно найти здесь: https://github.com/TTimo/doom3.gpl
Я заметил, что во время тестирования cvar r_useOptimizedShadows (который обрабатывает теневые объемы геометрии появления мира), артефакт исчез. Затем я работал над этой функцией:
R_LinkLightSurf( &vLight->globalShadows, tri, NULL, light, NULL, vLight->scissorRect, true /* FIXME? */ );
который я изменил на это:
R_LinkLightSurf( &vLight->globalShadows, tri, NULL, light, NULL, vLight->scissorRect, false /* FIXME? */ );
Это избавляет от артефактов - но теперь предполагается, что мы никогда не находимся в теневых объемах геометрии появления мира. Поэтому всякий раз, когда мы заходим в теневой объем, этот теневой объем не отображается должным образом.
float
). Вы легко израсходовали 5 из них. en.wikipedia.org/wiki/…Ответы:
Я наконец-то нашел решение - на самом деле несколько разных решений. Я не выяснить действительную причину артефакта от графического программирования точки зрения - но я нашел несколько решений.
Как я уже говорил в своем вопросе, оказалось, что артефакт возникает только на предварительно вычисленных теневых объемах статической геометрии появления мира (которая в основном представляет собой геометрию, которая, как знает двигатель, никогда не будет двигаться, поэтому он предварительно рассчитывает заранее время теневых томов и прочего с помощью команды, введенной в консоль, называемой «dmap»). Я не понял, почему это было только в тени статической геометрии появления мира, а не на любой из моделей ASE или LWO.
Теперь, что я заметил, было то, что на самом деле существует множество параметров, которые можно использовать с командой dmap - один из этих параметров называется «shadowOpt» - который должен обозначать уровень оптимизации теней. Этот параметр устанавливает перечисление - кажется, есть несколько различных уровней оптимизации теней:
У меня был успех с вариантом 2 - "SO_CULL_OCCLUDED". Он исправляет все артефакты - для его запуска требуется немного больше времени - но я полагаю, что большая часть этого времени уходит на вывод большого количества информации на консоль - эти отпечатки, вероятно, можно уменьшить или устранить.
Одним из мест, который дал мне некоторые подсказки, был комментарий здесь в tr_stencilshadow.cpp:
Теперь проблема только с выполнением этой «дополнительной» оптимизации теней во время «dmap» состоит в том, что, если какой-либо из этих источников света будет когда-либо перемещен (что всегда возможно в зависимости от типа проекта, который вы делаете), то он по умолчанию вернется к «неоптимизированный» процесс создания теневого объема в реальном времени (для перемещенного источника света) и артефакты появятся для этого источника света. Поэтому единственный способ гарантировать, что эти артефакты не появятся, - это всегда запускать очень дорогой процесс оптимизации для этих статических теней появления в мире. Это на самом деле очень дорого, так что это было бы абсолютным последним средством, если вы не можете найти правильное графическое решение. (если вы это сделаете, не забудьте опубликовать свое решение здесь.)
Я бы порекомендовал всем, кто создает большие карты для ванильного движка Doom 3 - и использует геометрию появления мира - они создают cvar, который они могут изменять в зависимости от своих потребностей в создании оптимизированных теневых объемов в реальном времени. Я назвал мой cvar r_useExорогоShadowOptimizations - который, кажется, оксюморон. Например:
Я также рекомендую, чтобы в зависимости от того, насколько велики ваши карты (и при условии, что источники света не будут двигаться), вы должны повысить уровень оптимизации статического теневого объема с помощью параметра "shadowOpt" для dmap.
Так что в основном все, что вам нужно, чтобы иметь большую карту и не иметь теневых артефактов, есть для вас, вам просто нужно решить, какие из них вам нужно будет использовать. Выполнение этого в режиме реального времени чрезвычайно дорого, и его следует выполнять только в крайнем случае, если вы не можете найти правильное графическое решение. Выполнение этого в DMAP имеет смысл, поскольку оно решает проблему и занимает всего несколько секунд для компиляции карты.
источник
Это вполне может быть ошибка точности плавающего указателя, поскольку Doom использует
float
s для рендеринга (в основном это ограничение OpenGL). Однако, возясьtr_stencilshadow.cpp
, я заметил этот комментарий, который может быть связан с проблемой (внутриPointsOrdered()
функции):Так и есть. Это также может быть известным ограничением способа рендеринга теней. Откровенно говоря, код очень грязный и трудно читаемый, поэтому я не могу вам точно сказать. Вы можете попробовать написать письмо разработчикам, чтобы получить больше информации.
источник