SweetyDarkyRosy

Вот именно, что там вообще не всё так просто! Там на автоматику можно отдать лишь очищение diffuse-текстур от "запечённых" теней, чтобы получить чистую albedo-текстуру, и то не факт, что во всех случаях всё будет достаточно хорошо после "прогона". Specular'ы и карты глянцевости (если говорить о модели "spec/gloss", например) уже нужно вручную подгонять

А адаптировать текстуры и материалы в целом под него кто будет?

Нет, такие проблемы могут начаться исключительно с запечённым GI. Если же запекать карты AO для небольших объектов и правильно прописать работу с ними в шейдерах, то там не будет особых каких-то проблем с этим при разных погодных или временных условиях. Но, обычно, AO запекается в текстуры исключительно для очень малых объектов или объектов, где должна быть явная жёсткая глубина, но реализовать её нельзя без сильной потери производительности, что аж нормали банально не вывозят. А в первом случае это нужно уже потому, что даже AO в пространстве экрана при адекватных настройках не может нормально рассчитать затенение разных деталей у без того мелких объектов. Конечно, нужно смотреть детально, что там последние алгоритмы AO предлагают вообще в плане качества и точности, но факт остаётся фактом

Ну SSAO не основывается на трассировке лучей никак. Там иной подход. А если и реализовывать AO ставишими уже классическими техниками, то лучше стандартным вариантов вводить именно SSDO, который более точный и имеет ряд небольших преимуществ. А само AO же работает всегда локально. Оно не заменит полноценного GI, которое в условиях классической растеризации тоже не может полноценно предоставлять мелкие затенения. Тут именно это нужно учитывать. И то же AO на объектах отдельно запекается, как я помню, в виде отдельных текстур, с которыми нужным образом потом работают шейдеры

Есть самый простой вариант всегда, который приходит в голову нормальным людям при подобных вопросах,: интерес. Интерес может такой быть и девушек/женщин. Может быть ещё жажда адреналина, нестандартных приключений на свою голову и так далее. Как вообще можно думать, что женщинам это не свойственно? Они, блин, когда получили возможности в правовом и не только полях, стали пробовать себя сразу во многих направлениях, включая даже автомобилестроение. Да, процент таких девушек/женщин невелик, но он есть (!), что важно учитывать. Вот и запрётся, что называется, за год минимум 3-5 женщин в Зону, а вот какими они будут - это вопрос другой. Она может быть и заранее подготовленной по нескольким пунктам (изучение теории, физическая подготовка, навыки обращения с холодным и огнестрельным оружием), а может просто с дури и наивности пойти, купить комплект костюма с камуфляжем, накинуть для пафоса шарфик дряхлый с дряхлым рюкзаком её деда и пойти в Зону, после чего лишь везение даст протянуть дней 1-3. То же, надеюсь, не открою тайну, касается и парней. Тоже наивных хватает, которые без подготовки через кордон проходят в Зону, а уже через несколько часов находят первое "приключение", которое с вероятностью ~90% заканчивается для них летальным исходом

Нуу... Как мы знаем, в графике в реальном времени много чего является костылём) Суть в том, что у screen-space-методик банально дофига ограничений. Их можно компенсировать всё же несколько гибридным подходом с данными из сцены, который хранятся не в буферах. По сути, почти все GI-решения, которые были вообще разработаны без использования трассировки лучей в пространстве сцены, как раз являются комбинациями пиксельных шейдеров и кэширования при составлении кадра нужных данных в пространстве. Я думаю, что AO можно тоже сделать хорошо трассировкой лучей в пространстве экрана, и там погрешность должна быть даже низкой вполне

Вообще, мы с Лохотроном внимательно поразглядывали разные наработки в билде, пристыковали другие факты, включая трейлеры с показанными там моментами, и пришли к выводу, что этот билд 100% относится к отдельной ветке, в которой тестируются лишь отдельные моменты. То есть, там не все имеющиеся наработки есть потому, что им в этой ветке и нечего делать. Возможность, что ветка появилась в 2020-ом или 2021-ом году с имеющимся на тот момент готовым ландшафтом, и после этого на ней стали просто отрабатывать отдельные моменты, не внося в само окружение и не только заметных изменений

Почему "консольный"?

Ну тут и технология готовая и заточенная под такое уже есть изначально. Минус одна большая проблема, как минимум. Да и инструментарий движка из коробки вкупе с современными ПО для разных задач дают тонну возможностей как для повышения качества, так или для ускорения работы в том или ином направлении. Но даже так у них что-то всё печально. Да, картинка современная требует много работы, и инструментарий возможностями для ускорения процесса не способен прям компенсировать это и на 50% (сухой факт), но всё же... Лет-то прошло с начала продакшна сколько (полагаю, минимум 3 года точно есть уже, но тут ещё и известные события могли сказаться хорошо так, что стоит учитывать). Хотя, думаю, стоит делать скидку ещё и на том, что какой-то процент ключевого состава художников, программистов и аниматоров мог быть не достаточно опытным, и этим людям нужно было учиться, "пристреливаться", экспериментировать и так далее. Да даже опытной команде приходится при сложной задаче какое-то время лишь заниматься тестами и экспериментами, параллельно ведя анализ результатов с обдумыванием или пересмотром той или иной вещи при том или ином проценте готовности. Факторов выше крыши

У них с производством "Metro Exodus" тоже было много проблем, но они смогли выкрутиться в относительно короткие сроки (будем честны, не без помощи целого ряда outsource-компаний). Но печально видеть то, что у GSC Game World повторяется отчасти история "S.T.A.L.K.E.R. 2" за 2010-2011 годы, что может сказаться и на финальном качестве продукта, если он доживёт до релиза (в первую очередь, такие затяжные проблемы сказываются психологически на продакшн-команде, не исключая и ключевых людей в её составе)

По поводу полигонов я не соглашусь. Все GPU в любом случае работают именно с треугольниками во время прогона графического пайплайна. И "Unreal Engine 4/5" те же при импорте ресурсов тут же проверяют полигоны на то, являются ли они треугольниками. Если нет, то движок быстренько сам разбивает поверхности на треугольники. Это несколько быстрее (ну сегодня разница незаметна уже), чем пытаться отдавать графическому API на обработку N-гоны, где N > 3. Художники просто сами привыкли работать именно с квадратными полигонами, ибо в этом есть смысл на данном этапе. И мало кто тут же отдаёт на экспорт в другое ПО модели с вручную оттраянгулированными (извиняюсь за кривой транслит) поверхностями, ибо ПО само уже доводит такие мелочи до нужного состояния. И откуда вообще взялось такое, что "UE" работает именно с квадратами?

Скорее всего. Внедрять оригинальный DLL бессмысленно, ибо он завязан сильно на функционале "X-Ray Engine". Тут реально только если в коде проекта "UE5" уже восстанавливать самостоятельно весь функционал

Сверху ещё перелопачивать все визуальные ресурсы, дорабатывать анимации, подтягивать режиссуру местами и много чего ещё... Серьёзно... Проще с нуля начать делать уже проект во всех его аспектах с проработкой каждого момента. Вот тогда действительно будет этот "redux" ваш. Так ещё нужно, чтобы атмосферу не запороли, что обычно в модах и происходит, особенно, когда пытаются подтягивать графическую составляющую

Это не... ОХХХ... Диван явно творит чудеса и рождает "экспертов во всём и вся"... Это чистый "Unreal Engine 5", для которого, как я лично поняла, Панда разработал плагин, умеющий читать файлы логики, 2D/3D-контента и так далее, которые использует "X-Ray Engine", а затем в коде самого проекта была прописана им основная логика, которая похожа на то, что сделано старой технической командой GSC

Ну для коммерции ни разу не приемлемо, если серьёзно. А под капотом лучше всё с нуля сделать