Перейти к содержанию

Unfainthful

Сталкеры
  • Публикаций

    90
  • Зарегистрирован

  • Посещение

  • Победитель дней

    1

Сообщения, опубликованные Unfainthful


  1. 1 час назад, SkyLoader сказал:

    Сколько времени они занимают?

    Недавно писали про те, что на Embree, это они? Хорошо, конечно, что есть доработки работы с ядрами, но также там есть различные отключения оптимизации геометрии в угоду времени компиляции. Я против такого подхода. Лучше пусть локация дольше компилится у автора, чем отсутствие оптимизации потом повлияет на игру у всех. 

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

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

    Вот такая локаimage.png.fe90cb282bcdc17ccbfbcf3e529b8bdd.png

    Build UW mapping\Implict lighting = 4-6часов \ 14 часовimage.png.e7aae82baad9215204329e67372818c0.png
    Общее

    i9-13900k \ 32Gb DDR5

    Вот про эти вот компиляторы говорю

    Макс умеет импортировать материалы для СДК X-Ray. Но там свои приколы есть. Имеющиеся плагины от Den Stash очень долго импортируют группы сглаживания ЧН и ЗП типа (второго типа). Я так никого и не нашёл, кто смог бы помочь с этим делом. там счёт на модель машины будет идти около 20-30 минут.

    Я не ставил ключ -notesselation. Но про 16 тайлов буду иметь ввиду. Но хотелось бы расширения больше чем 16 тайлов на шэл.

    Касательно качества компиляции. Я совершенно не против, если будет возможность существенно улучшить просчёт параметров для лучшего эффекта, даже если это многократно увеличит время компиляции. 
    Пусть это будет ключами на выбор компилирующего.
     

    Цитата

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

    Я забыл про эту штуку. Да. Очень бы хотелось иметь возможность дать компилятору проверить все thm и соответствия, а потом уже закрыться компилятору, сохранив весь список в лог. По одной текстуре не очень круто перебирать.


  2. 5 минут назад, SkyLoader сказал:

    Решил для информации собрать фидбек по компилятору. Есть у кого какие баги, критические проблемы, пожелания по оптимизации фаз/интерфейсу/удобству пользования?

    Багов, критических проблем - нету.

    Пожелания есть по ускорению стадий Build UW mapping\Implict lighting
    Также тут чел выложил допиленные компиляторы от пандовского СДК. Говорит что научил их лучше работать с P и e ядрами. Хотя могу сказать, что и сейчас компилятор 13900к стабильно на все ядра грузит.

    Пожелание - есть опция для экспорта коллизии. Было бы круто иметь опцию для обратного экспорта изменённой коллизии с её дальнейшим использованием. 
    Как мы все знаем, коллизия очень и очень хорошо кушает производительность. Возможность её ручной доработки пусть даже машинными средствами - отлично скажется на ФПС.
    1756757280_.thumb.jpg.544085fdee5759c20be384f4a614bc85.jpg
    А. Была одна штука. Я думаю, это может быть связано с оптимизацией развёртки компилятором.
    В общем.. Длинное ЖД полотно. (несколько км длиной) Местами с него напрочь сдуло текстуру, при том что в Максе всё ок.
    Там из-за множественного импорта-экспорта наверняка отдетачило каждый полигон в отдельный шэл. А компилятор, видать не сумел обратно собрать.

    А так - ещё раз спасибо за компиляторы! Крутые!))


  3. 17 часов назад, Pepel сказал:

    @SkyLoader, дорогой, не мог бы ты выпустить новую версию своего компилятора? Я просто подзае**ся 4раза перезапускать экзешник и поочереди компилировать = геометрию, траву, ии, спавн... Нельзя сделать где-нибудь кнопочку с помощью которой можно было бы сразу всё включать и автоматом запускать езешник игры?

    Кнопочку - нет. Но ты можешь написать всё это в батник и запустить его.


  4. 2 минуты назад, SkyLoader сказал:

    Привет, попробуй разбить геометрию на несколько отдельных мешей и поправь им развертку, чтобы UV координаты были ближе к нулевым. Лишние вершины потом все-равно должны будут сшиться компилятором. Галку оптимизации развёртки не советую трогать, так как в игровой геометрии развёртка хранится в упакованном и оптимизированном виде.

    А ты можешь нам описать как работает оптимизатор развертки у компилятора? 

    Понимание этого явно упростит решение подобных проблем. Ведь в основном это касается именно узких и длинных шэлов развертки.
    Т.к. то что хоть как-то ближе к прямоугольнику/квадрату - беспроблемное


  5. 8 часов назад, Yara сказал:

    Нашёл проверку на неё в \engine\utils\xrLC\OGF_Face.cpp (void OGF::Optimize), но тут как всегда сомнения, может это нужная фаза при компиле. Вот Скай может более точно сказать.

    Тогда ждём что нам @SkyLoader на это дело скажет)


  6. 6 минут назад, Yara сказал:

    пока решение - использовать def_vertex или default, но нужно делить развёртку объекта на части:

    изначальная и раздельная

    В итоге - растягивает там где у тебя развёртка цельная, или наоборот?

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


  7. 1 час назад, imcrazyhoudini сказал:

    Компиляция на SSD происходит быстрее чем на харде? Если да, то примерно насколько?

    Вычисления хранятся в ОЗУ. Разница между HDD\SSD может быть только в скорости загрузки и обработки текстур и затем - лайтмапов. 

    Если у тебя в локе используется 50 гигов текстур в виде нескольких тысяч комплектов, то загрузка с SSD будет на пару-другую минут быстрее.

    • Мастер! 1
    • Спасибо 1

  8. В 16.01.2024 в 08:34, Diesel сказал:

    это в большей степени твоя заслуга, что без косяков. Бывает такой геом, что даже Скай офигеет.

    Ну да. Геометрию нужно смотреть и хорошенько проверять перед компилом, в 3д Редакторе.

    Вернее.. Сделал/выдрал геометрию. Закинул в 3д редактор. Там всё настроил - правильно экспортировал в СДК. 
    В СДК настроил шейдеры/материалы = хорошая картинка после компила.

    Если ничего не закосячил на одном из этапов.


  9. 44 минуты назад, DevilSatalker сказал:

    мей дей подскажите что нужно и как правильно прописать ключи для финальной зборки локации на ЗП

    У меня вот такой набор. Всё отлично собирает. Без косяков по теням и без битых групп сглаживания.

    Но -skipthm не желательно для чистовой сборки использовать.
    image.png.ff04d8d7ee55b72f7be8262afadefb61.png


  10. 42 минуты назад, imcrazyhoudini сказал:

    Можно ли не рекомпилить полностью локу из-за этого бага, а просто -cform сделать?:
    ss-imcrazyhoudini-12-13-23-17-27-54-lv01

    Просто поднять чуток санбокс надо.

    -cform правит только коллизию. А у тебя видимая геометрия попала... Компилируй заново)

    • Спасибо 1

  11. 43 минуты назад, DarkSnowder сказал:

    народ, из-за чего при компиляции лайтмапа на террейне результат вот таким оказывается

    terrain_giza и terrain_giza_lm - текстура от правого верхнего и до левого нижнего явно имеет черту неравномерного запекания статики (одна часть явно темнее/светлее) другой. НА других компиляторах такого не было, да и на других террейнах тоже.

    Добавь ключ "hemi_bias 10" 

    Там в faq посмотри точное написание ключа. 


  12. 12 часов назад, Ostrov igr lego сказал:

    Can't find any graphs! Check log

    Это значит что компилятор не нашёл ни единого game.graph.

    1. Ставить их нужно после того как сгенерировал в ЛЕ АИ сетку. Заметил что если делать в обратку, то бывает такой вылет.
    2. Их должно быть не меньше 4 на каждой локации. + граф для перехода, если ты его планировал.
    3. Ты мог ошибиться, прописывая уровень в конфиг [level] тогда компилятор также вываливает подобный прикол.

    • Спасибо 1

  13. 24 минуты назад, ZonaChe сказал:

    Prostomod Привет. Там с этим туннелем, вообще беда бедовая. Поправил как смог, в редакторе (бленд) смотрится нормально (убрал порядка 2к трисов), а вот у imcrazyhoudini та же хрень.

      Скрыть контент

    mrak.png0101.png0303.png

     

    Ну это потому что взяли декомпилированную геометрию. Такие простые модели быстрее заново сделать, чем править косяки.


  14. 1 час назад, imcrazyhoudini сказал:

    Подскажите, почему может возникать такой баг?:
    Компилил с -nosmg, но и с ним такой же результат.

    Потому что у модели сбиты группы сглаживания.
    Нужно загрузить её в 3д редактор, и настроить группы сглаживания. Если пользуешься 3Д максом, то экспорт для ЧН/ЗП производить вторым типом 


  15. 23 минуты назад, SkyLoader сказал:
    В 22.10.2023 в 16:21, Unfainthful сказал:

    а для MU моделей можно сделать возможность применения такого финта с шейдерами компиляции?

     У всех материалов этой модели заменен шейдер на _smg? 

    Нет, только у коры. Не вижу смысла применять шейдер доп сглаживания к материалам листвы.
    Да и при наличии возможности дополнения к шейдеру листвы _no_mu_shadow

    Было бы очень удобно, коль введено, не мучаться со сглаживанием у модели, и на кору дать сглаживание через шейдер (_smg), а на листву отсутствие затенения(-no_mu_shadow)


  16. 3 часа назад, DarkSnowder сказал:

    в общем ты оказался прав - дело было в текстурах. Сменил фотозону на текстур-пак к ОП2.2 от Vac33 и проблема решилась (видать детальные текстуры давали такие глюки с освещением)

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