SkyLoader

Ругается на версию АИ-сетки. В батнике компиляции АИ-сетки надо прописать версию игры, а именно ТЧ. Без этого компилятор по умолчанию компилирует под ЗП. Ну и я бы рекомендовал компилировать через меню компилятора. Там и версию можно выставить для всех режимов компиляции.

В версию 1.4 добавлен хотфикс компиляции АИ-сетки для ТЧ. Ссылки на версию 1.4a в шапке.

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

Можно добавить разделение на две модели при сохранении .obj через -saveobj_cform: отдельно обычная коллизия, отдельно raycast. В следующем обновлении тогда добавлю

Состоялся релиз версии 1.4:

Все-таки решил запилить карту под 8К: Ссылка Исходник в 12К

С выходом в ОБТ. Хорошо, что был выбран такой пак флоры. Как по мне, приятен глазу, и, в отличии от летнего, через такую флору видимость гораздо больше. Понятное дело, что сейчас ОБТ, но я надеюсь, не забудут про оптимизацию сцены через сектора, порталы и хомы. Потому что на данный момент видно, что геометрия в городе никак не отсекается, тем самым просаживая фпс. И да, действительно, без карты сложно ориентироваться, поэтому вот небольшой патч от меня: 4К карта локации для пда и миникарты: Ссылка Размеров 4К для данной локации все-равно оказалось мало, но как временное решение сойдет.

Я понял твою идею, только как быть в случаях, когда у пользователя имеется правленный сдк и игра, в которых есть, к примеру, новый блендер террейна с новым CLASS_ID? Компилятор о нём не знает. Сейчас он сможет определить флаг по thmке и ему абсолютно все-равно, что менялось на стороне шейдеров.

По поводу этого момента: Поступило предложение сделать зависимость поиска thm файлов от версии проекта уровня. Для ТЧ версии оставить только $textures$ (rawdata\textures), а для ЧН, ЗП только $game_textures$ (gamedata\textures). Чтобы не было непоняток, почему у текстуры и thm файла пошли различия. Изначально моя идея с поиском по двум путям заключалась в облегчении переноса контента с ЗП в ТЧ сдк, чтобы не надо было заново настраивать все текстуры, а настройки текстур сразу брались из геймдаты. Но, по итогу, это несет больше путаницы, чем пользы. Поэтому если это действительно излишняя фича, то в следующей версии могу убрать поиск по двум путям.

Ну вот как у меня выглядит на ванильной игре с текстурами, что ты скинул: При этом вода у нас отличается. У тебя или шейдеры другие или текстура воды в самой игре. Под водой действительно есть темные места, но это исключительно из-за самой текстуры и качества компиляции. Ряска слабо пропускает свет, и в игре ты не должен был что-то через неё видеть.

При загрузке объектов: В архиве её нет. Ты точно ту текстуру проверял? Дополнено 54 минуты спустя В принципе, и без этого есть вопросы: У тебя в объекте террейна есть несколько слоёв геометрии, имеющей одну и ту же текстуру террейна. Так делать нельзя, поскольку для террейна лайтмапы и хеми запекаются в саму текстуру террейна. Если развертки слоев будут совпадать, пойдет конфликт, который выльется в нечто подобное. Здесь нужно или править развертку террейна, исправляя конфликты, или дублировать текстуру террейна и назначить её на второй слой. Вариант с дублированием текстуры террейна:

1. Убедись, что компилятор экспортирует локацию в ТЧ формат (в логе должно быть прописано -version shoc) 2. Проверь текстуру воды в gamedata/textures. Она должна иметь прозрачность 3. Проверь, что thm файле воды стоит формат текстуры, поддерживающий альфу (например, DXT3, DXT5 или 8:8:8:8) 4. На всякий случай скопируй этот thm файл воды в соответствующие папки по путям gamedata/textures и rawdata/textures и перекомпиль

В шапке темы в спойлере про советы упомянута последовательность загрузки thm файлов: В теории, проблема запекания может заключаться в том, что в gamedata\textures есть thm'ка, в которой выбран формат текстуры без альфы, из-за чего при компиляции прозрачность воды не учитывается. Желательно приложить скриншот и лог. Так хотя бы можно увидеть, на каком объекте висит компиляция. Как сказали выше, часть расчетов у той фазы можно пропустить ключом -noise, также часть расчетов пропускается ключом -nostrip.

Да, для статики и неполной динамики нужен ключ -static Для травы этот параметр не нужен. Я поэтому и предложил перекачать версию 1.3, так как там это убрано, дабы не смущало. В дополнительных ключах это ставить не обязательно.

Лучше перекачать версию 1.3 из шапки, сделать билд оригинальным сдк и должно пойти. Может когда-нить Yara уберет новые параметры сцены (или хотя бы сместит их в конец структуры параметров) для совместимости с другими компиляторами, но пока использовать это вместе нельзя Нет, он не нужен Нет

Сдк от Yara? Я уже как-то упоминал, что в нём были добавлены правки по сглаживанию и параметрам сцены, из-за чего совместимость с оригинальными компиляторами отсутствует. Выглядит опасно. Пока еще никто не выкручивал Pixel per meter в 0 🙂

В связи с недавним откатом сайта повторяю посты с релизами версий. Версия 1.2: Версия 1.3: Данное обновление направлено на поддержку сборки ТЧ спавна. Теперь для ТЧ спавна достаточно воспользоваться только ключом -s, так как все фазы сборки левел графов, гейм графа и спавна объединены в одну задачу. Также в меню компилятора можно выбрать список уровней, которые будут присоединены к общему спавну. Второе нововведение для ТЧ спавна, это ключ -insert_graph. Он позволяет вшить все графы уровней в файл спавна, как это реализовано в ЗП. Это облегчит перенос спавна из рабочей директории сдк в директорию игры, поскольку не нужно переносить все файлы графов и таблиц связности АИ-сетки с графами, а лишь перенести один файл спавна. Однако такой формат спавна потребует изменения игрового движка, поэтому ниже приложена ссылка на коммит, который можно адаптировать под свою версию движка. https://github.com/SkyLoaderr/OGSR-Engine/commit/c756706c6b1fb826bfaf53a83cedea579b38b971

Модели рук точно будут изменены. Но некоторая конкретика касательно этого еще обсуждается.

Можно конечно убрать проверку, правда это не совсем безопасно. Помимо чанка со сглаживанием для обычной геометрии еще есть сглаживание для каждого MU объекта (в ЧН/ЗП), и оно не вынесено под отдельный чанк, а лежит вместе с данными о вершинах. Из-за этого можно получить неправильное чтение данных. Но опять же можно положиться чисто на наличие чанка и надеяться, что во входном формате имеется та же зависимость наличия сглаживания MU объектов от наличия чанка.

Выглядит как битый билд уровня. Можно перебилдить тем же сдк или другим. Если уровень билдился сдк от Yara, то так и должно быть. В том сдк был изменен формат проекта уровня, который не поддерживается обычными ТЧшными компиляторами.

Проверил на ТЧ версии МП АТП. Укрытия просчитываются и зависимость от ключа -draft работает. Для сравнения версия с просчетом укрытий: Версия без укрытий (на драфте): Скорее всего тебя смутило только время расчета, а не какие-то проблемы в игре. Во первых, из компиляции был вырезан рудимент в виде освещения АИ-нод. В ЗП компиляторе уже был вырезан расчет освещения нод, а в коде движка ТЧ я не заметил его использования в игре, поэтому эти просчеты также были убраны для ТЧ локаций. Ну и во вторых, компилятор использует все ядра ПК, что ускорило просчеты по сравнению с предыдущими компиляторами. В условиях параллельного выполнения задач в компиляторе это будет не просто сделать. На этот счет пока ничего сказать не могу.

Как я писал выше, в тот момент выполняется параллельно две фазы: build UV и расчеты Лодов. Уазик, который упомянут в логе, относится ко второй параллельной операции, не затрагивающей Build UV mapping. Да, в окне компилятора вперемешку выводится информация о состоянии выполнения двух фаз, из-за чего может возникнуть путаница. Если бы в уазике была проблема, тогда бы вылет был бы и на драфте. Значит развёртка под лайтмапы создалась, хорошо

У лод объектов нет разверки под лайтмапы, и, следовательно, они не участвуют в фазе Build UV mapping, на которой происходит ошибка. Я имел ввиду убирание обычных объектов статической геометрии.

Grade Судя по скриншоту можно сказать, что в тот момент происходило параллельное выполнение двух фаз: Build UV mapping и LIGHT: Starting MU. Первая фаза отвечает за формирование лайтмап развертки для геометрии уровня, а вторая за расчеты геометрии и освещения для MU (Lod) объектов. Так как вылет не возникает при драфт качестве, значит проблема происходит именно на Build UV mapping. Это также подтверждается ERRORом на скриншоте, который отвечает за лайтмап развертку. Один из вариантов решения, удалять части уровня в сдк, пока вылет не прекратится и потом по наличию вылета определить, на каком объекте крашится компиляция. Другой вариант, попробовать скомпилировать уровень этим компилятором: https://ap-pro.ru/forums/topic/3341-universalnye-kompilyatory-urovney-h64/ В нём был исправлен ряд вылетов, в том числе возникающих на фазе Build UV mapping. Может быть он поможет с вылетом или хотя бы с выводом ошибки в лог.

Да Можно будет добавить когда-нибудь. И тогда уж для компиляции нужно будет запрашивать не level.cform, а build.cform, как это сделано для детейлов и аи-сетки. Спавн вряд ли получится ускорить, а по геометрии может что-то будет, но не в ближайшее время.