Pavel_Blend

Моделирование Terrain'а https://youtu.be/Z5yDT9H17J8 Моделирование здания https://youtu.be/gJbAHKQUkg0

Новый урок по формам костей: https://youtu.be/SyFx-JAxa-Q

Записал уроки по блендеру: Описание рига сталкера https://youtu.be/it1OXyoFiPk Описание плагина blender-xray https://youtu.be/xZ12xVqXZzE Описание тестового импорта/экспорта level.details https://youtu.be/u7Vyr02LiNE

из-за этого скорее всего и создаётся куча lmaps. Площадь всех lmaps увеличилась, вот и создалось больше dds текстур. выставь значение Pixel per meter в 10 или меньше и количество уменьшится.

@CuJIbBEP, если в блендере прям сильно-сильно тормозило, то скорее всего был выставлен режим визуализации Mulitexture. Нужно устанавливать в GLSL. Сейчас проверил на ЧАЭС из ТЧ. В режиме GLSL производительность на порядок выше.

, а у тебя какое значение установлено в опции Pixel per meter?

а ты в 3ds max или maya такой же уровень загружал? Меньше тормозило?

S.T.A.L.K.E.R. ltx compare Небольшая программа для сравнения двух ltx файлов. При сравнении не учитываются комментарии и порядок расположения параметров. Написана на Python. Для запуска нужно установить интерпретатор питона версии 3. Скачать: https://github.com/PavelBlend/Stalker_Ltx_Compare

@Romann, если ты с блендером ни разу не имел дело, то думаю, легче траву пересобрать в сдк. Времени меньше уйдёт. Так как в блендере нужно тебе будет изучить интрефейс, навигацию и т. д. если блендер установил в путь по-умолчанию, то в C:\program files\blender foundation\blender\2.78\scripts\addons. Есть ещё статья по установке: http://stalkerin.gameru.net/wiki/index.php?title=Blender_X-Ray_%D0%9F%D0%BB%D0%B0%D0%B3%D0%B8%D0%BD

@KD87, а для чего нужен модуль stkutils\file\ogf.pm? И где он используется? Он ведь разбирает формат ogf? Если да, то нормально ли он разбирает ogf из билдов? Последний конвертер (https://bitbucket.org/stalker/xray_re-tools/commits/branch/default) неправильно конвертирует некоторые модели из 1472 билда (и из других тоже). А этот модуль как разбирает? И вообще, как ты его писал: опираясь на с++ код конвертера бардака, и сделал 100% копию на перле или всё же есть отличия?

тогда будет сложно. Нужно прочитать какой нибудь учебник. Разобраться в интерфейсе, навигации. Так как в уроке я вряд ли буду объяснять все базовые вещи. можно и в 3д редакторе. В блендере есть режим рисования текстур в 3D окне. Можно прям рисовать по слотам, указывая нужные цвета мешей. И с помощью 3д редактора возможно изменять позицию слота по высоте и саму высоту слота.

@Дизель, я сейчас обясню, что хранит level.details: меши кустов, листьев и т. д. слоты с различными данными. Слот - это параллелепипед шириной 2 метра, длиной тоже 2. А высота у каждого параллелепипеда индивидуальна. Слот так же имеет координату Y (положение в пространстве по высоте). Слотами покрыт весь уровень (в один слой). Ну может и не весь. Смотря как в сдк настроено. Но обычно все слоты - это прямоугольная сетка, размером с уровень, где ячейка - это слот. Что хранит слот: hemi освещение. Один слот может иметь только одно значение hemi. То есть, если hemi перевести в изображение, то каждый пиксель - это будет слот. Вот пример (МП АТП): Глубина цвета 4 бита. тени от солнца (аналогично hemi). Пример: Цвет от статических источников света. Но почему то в игре не используется (например, на кордоне возле костра в деревне новичков трава не освещена в оранжевый цвет, хотя коэффициенты света в файле для этого места сохранены именно как оранжевые) Четыре идентификатора мешей 16 значений плотности (по 4 значения плотности на каждый меш в 4 углах слота) В игре трава будет появляться на тех визуальных поверхностях, которые находятся внутри слота (параллелепипеда). И не только на террейне. А на любых визуалах, которые попадают в слот. Например, в билде 1472 трава в мёртвом городе растёт даже на проводах. Это из-за того, что некоторые слоты слишком высокие (от земли до высоты столба с проводами). Чтобы такого не было, нужно в сдк в Snap List добавлять только terrain. Движок читает траву не из карты деталей (terrain\terrain_level_det.dds), а из данных слотов. Карта деталей используется только для генерации в сдк.

@ed_rez, 2.78a (то есть последняя)

@sneik, этот плагин даёт возможность полностью редактировать траву: можно добавить новые кусты или удалить их убрать и посадить тоже можно можно изменить плотность травы менять положение слотов редактировать освещение Наверное нужно будет записывать видеоурок, так как врядли кто-то будет этим импортёром пользоваться. Не сразу все смогут понять как сделать все эти операции.

@Romann, есть для blender'а плагин, который импортирует и экспортирует level.details с сохранением освещения, плотности и номеров мешей (короче полный импорт/экспорт). Если знаешь блендер, то вот ссылка на плагин: https://github.com/PavelBlend/blender-xray/tree/experimental/support-details-slots Как им пользоваться, напишу потом. Чтобы отредактировать level.details в блендере нужно в меню выбрать File > Import > XRay details Выставить такие настройки: Load Slots = True, Save Slots = True, Format = TGA, и прописать путь куда сохранять tga Потом выбираем нужный level.details и жмём Import dm/details После импорта сохранятся изображения: details hemi - хеми details lights - свет details shadows - тени details meshes № - идентификаторы мешей травы (4 изображения) details meshes pallete - пригодится для редактирования травы в фотошопе. Содержит цвета травы (первый пиксель - меш №1, второй - меш №2, третий - меш №3 и т. д. (всего 64). 64 - отсутствие травы (чёрный цвет) После редактирования в фотошопе можно экспортировать: для этого нужно выбрать пустышку level.details и нажать File > Export > XRay Level details

У меня появилось предположение: компилятор разделяет большие полигоны, чтобы их можно было плотнее расположить на картах освещения. Естественно чем меньше полигоны, тем ближе они могут быть расположены друг к другу без перекрытия соседних. Я сейчас попробую скомпилировать уровень, и проверить меши с шейдером def_shaders/def_vertex. У них нет карт освещения, поэтому они не должны подразделяться. Проверил. Всё равно подразделяет. Может это и для того, чтобы вершинное освещение было более плавным?

А для чего компилятор геометрии подразделяет большие полигоны на кучу маленьких? Вот скриншот:

Какие шейдеры нужно назначить материалу, чтобы не было таких багов?: https://img-fotki.yandex.ru/get/50526/94012145.1/0_5a40bb_109959ee_orig Материал полосы разметки дороги не реагирует на свет фонарика. На месте прозрачности тени слишком тёмные. Полоса разметки - это полигон, который чуть выше самой дороги (висит в воздухе). Разметка выглядит нормально, если на неё не падает тень и не падает свет фонарика.

Скрипт для быстрой конвертации файлов с помощью конвертера Бардака: S.T.A.L.K.E.R. Batch Converter (Версия 0.03 за 08.07.2015) Скачать: https://github.com/PavelBlend/Stalker_Batch_Converter

А какие шейдеры (из папки gamedata\shaders\r1\) отвечают за карты освещения (тень от солнца, hemi освещение и статические источники света) на статике?

@Mcbeat7, нет. Вот команда: @start bins\compilers_x64\xrLC.exe -f test_sg Использую x64 компиляторы от KD.

А как тогда сделать такое сглаживание: https://img-fotki.yandex.ru/get/59115/94012145.1/0_598449_c66c8082_orig Это цельный меш. Если я его экспортирую в сдк 0.4 и скомпилирую, то острые рёбра (на скриншоте они помечены голубым цветом) станут мягкими, так как там угол довольно тупой. Чтобы всё таки сохранить остроту тех рёбер (используя только xrLC от ТЧ) придётся вершины разъединить (отделить окно от стены). Но это костыльно. Поэтому единственное решение - это компилить на xrLC от ЗП.

Это сработает только для ЗП компилятора. Компилятор от ТЧ просто игнорируют сглаживание, заданное в 3д редакторе, и использует Normal smooth angle. Может в xrLC от ТЧ GSC отключили код, который отвечает за сохранение нормального сглаживания? Никто в исходниках xrLC подобного не находил? мне нужно без переделывания геометрии сохранить сглаживание. И не обязательно именно этот меш. Этот меш я сделал чисто для тестирования. Как-то костыльно разделять меши домов, деревьев и т. д. Как не редактируй сглаживание, компилятор всё равно его проигнорирует. Хоть все рёбра будут Harden Edge, уровень будет сглаженным согласно Normal smooth angle. А что разработчики глобальных модов (типа OGSE, Lost World и т. д.) в таких случаях делают? Тоже используют ЗП компиляторы? Т. е. GSC компилировали все уровни со сглаживанием 75? Возникает вопрос: зачем тогда они настраивали сглаживание на мешах в 3д редакторе? Я смотрел исходные object файлы из слива исходников. Так у них сглаживание нормально настроено через 3д редактор. Только непонятно: это сглаживание было задействовано при компиляции или xrLC его проигнорировал?

Уменьшил значение "Normal smooth angle", но компилятору всё равно. Он нормальное сглаживание игнорирует и использует "Normal smooth angle". Лучше тогда уже использовать компиляторы из ЗП, а потом портировать уровень в ТЧ. Так как xrLC от ЗП нормально сохраняет сглаживание из 3д редактора.

Как заставить xrLC от SDK 0.4 сохранять сглаживание геометрии, которое было задано в 3d редакторе. Я скомпилировал тестовую локацию на максимальных настройках. Но сглаживание не сохранилось. Вместо этого компилятор использует "Normal smooth angle". Вот скриншот: https://img-fotki.yandex.ru/get/194778/94012145.1/0_597926_87a0dadf_orig