Vector Infamous

Понятно, без комментариев.

Такое у меня было только с декалями, когда наложение происходило на сложную геометрию и планар генерировался SDK с безумной топологией. А так всегда хватало xView/STL Check в 3ds max и финальный осмотр при билде уровня. Зависит же ещё от того, кто как моделит и как умеет.

Конфодебилам привет, остальным соболезную.

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

Это алгоритм, как освещенность проецируется на текстуру и как её развертка создается. Насколько я знаю, его никто не решался трогать в компилерах. Так что подмена компилеров ничего не даст. Это самые обычные швы, которые есть у любой развертки, только эта развертка генерируется компилятором. Из-за геометрии, расположения/настройки лайтов, их количества в конкретном пространстве, подобные артефакты либо становятся заметными, либо удачно маскируются. Для достижения лучшего результата тебе нужно больше с этим работать, чтобы появился опыт. Это пока все, что я могу сказать, в данном моменте основная часть зависит от твоих рук.

Данные развертки под лайтмапы (и под хеми, вообще, под все, что запекается в xrLC). Соответственно на юви-шеллах есть швы, алгоритм не всегда просчитывает так-как хочет юзер и соответственно получаются такие артефакты. Этого не избежать, когда все моделится также угловато, как делали это пысы, просто старались работать с лайтами так, чтобы такое не происходило. 100 фуззи лайтов и большей рендж для такого помещения. Как бы это не звучало: смотреть, что там у Пысов было и экспериментировать. Дополнительно освещать проблемные места, если очень сильно надо. Если перед экспортом проверять геометрию, то и инвалидов не будет.

Ой все, я почему-то перестал внимательно читать посты. Да.

Субъективщина. До слива сорцов ЗП, компилил на 4 ГБ ОЗУ, на х32, постоянно облегчал сцены, чтобы проходить по памяти. При появлении х64 версии компилера, проблема решилась сама собой. Ну а немного потом, я обновил память и забыл про нехватку памяти на иксрее впринципе. Какие-то всратые модели могут быть причиной падения компилера, но не следствием. Также как и не стоит забывать про простую нехватку памяти на физическом уровне. Дополнено 1 минуту спустя Я не заметил ссылку сразу, да там, просто некорректно настроенный лайт.

Хоть спросите для начала, какими компиляторами он компилит, может там х32. Дополнено 6 минуты спустя Поздравляю, из-за неправильно настроенного лайта вылезли классические проблемы с дефлекторами.

Точно причина в хеми?

Кто угодно, но только не пысы.

Varvar Верцингеторикс, перелогинься.

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

"Листая старенький айпад":

Stepan_sovok1917, сейчас проверил на оригинале ЗП, потому что в своей среде остался только Blinn-Phong: Слева Blinn <-> Phong 0.75 / Справа Metal <-> OrenNayar 0.35 Если вкратце говорить, то она должна менять характер и интенсивность отражения, в ТЧ во всяком случае это так и работало, где параметры в нужном режиме записывались в textures.ltx. На ЗП похоже оно окончательно не работает.

Потому что ты продемонстрировал тоже самое. Тем более выше я уже писал, о нужде в подборе других вариантов.

Stepan_sovok1917, модели освещения, при другом освещении сцены должно быть лучше видно различия. Только на самом деле никакого особого смысла ставить, что-то кроме Блинна-Фонга там нет.

MUL_2X(B^D) поменять на MUL. За работу шейдера в игре отвечает скриптовый шейдер в соответствующей папке. P.S.: wallmark юзается на обычных декалях, вроде следов попадания пуль и каплей крови от ранения. Им тип бленда менять на MUL и другие не стоит, могут быть проблемы с отображением уже в игре. Потому что разные типы визуализации декалей, подразумевая разные этапы наложения на какую-либо поверхность. Очень вкратце: Для статики имеет смысл только LEVEL блендеры, потому что EDITOR для SDK, INTERNAL и некоторые LEVEL (типа (lmap+env+const)*base, Implicit и вроде ещё парочки) устарели ещё во времена сборок на ТЧ и могут не работать как надо на релизе ЗП. Все их названия состоят из ключевых слов, которые доходчиво описывают что они делают с чем: base - базовая поверхность; diffuse - вершинное освещение; lmap - лайтмапы; env - карта окружения (кубмапа); detail - с детальной текстурой поверх base; Implicit - проецирование света на текстуру (всеми знакомые запеченные тени на террейне, если что, по факту такое можно с чем угодно делать). Ну и обратить внимание на скобки, * и ^. Они там написаны не для красоты, а напрямую указывают математическую работу шейдера, как оно должно (или должно было) высчитывать все параметры.

Приоритет отрисовки моделей на экране, по сути послойно. 0 - в самую последнюю очередь 1 - за объектами 2 - на уровне с объектами 3 - впереди объектов Strict sorting (StrictB2F) нужен для минимализации конфликтов отрисовок при приоритетах 2-3, но на практике не всегда помогает. Примеры? Там слишком скудный функционал, чтобы гайды по нему вообще писались. Шейдеры как таковые там не правятся, а их шаблоны, и то самое важное записано вручную в исходном коде блендеров, которые создаются в SE. Людей за всю историю моддинга, в SE, в основном волновало только как правильно сделать шейдеры террейна, отсюда и такое знание о работе этой программы.

Как администратор Zone Chronicles, говорю, что такое поведение у нас не в почете.

Stepan_sovok1917 , хеми может отбрасывать тени. За глобальную подсветку отвечает хемисфера, которая создается во время сборки уровня (от каждой вершины хемисферы пускается луч, от которого отбрасывается тень на сцене + джиттеринг, что и создает эффект рассеянного света). Дополнительные источники предназначены для регулирования эффекта в нужных местах и из-за того, что лучи идут от одной точки, тень получается явная. Для того, чтобы избавиться от явных теней от источников хеми, достаточно в них выставить Fuzzy и настроить так, как это нужно.

Stepan_sovok1917, какой тип назначен у рядомстоящего лайта? Скорее всего это $hemi.

Крим, очистить кастом дату объекта и переконвертировать.

Я бы добавил ещё, что нет смысла даже и менять им цвет, достаточно даже одного параметра Brightness. Если не нужно контролировать то, что будет твориться на холстах - можно оставить на нулях. Тем более пропадет пересчет лайтмап, что может дать прирост в скорости компиляции.