Ghost-2142

Я, конечно, не уверен, но если верить "интернетам", то алый по цветовой палитре "HSV" равен 8,100,100: Сталкерский редактор партиклов вполне справляется с точной настройкой данного цвета: Если текстура будет приведена в надлежащий вид, то отображаться она будет как алая. В моём случае текстура из оригинала, поэтому она имеет оранжевый оттенок: А вообще, можно поступить проще. Можно заранее перекрасить в любом граф. редакторе текстуру в нужный оттенок, и тогда вообще не придётся лезть в редактор партиклов. Что касается костра, то он там программным путём по дефолту не окрашивается в какой-либо оттенок.

А проблемы есть. И заключаются они не только в плагине, но и в СДК игры. Я провёл немало бессонных ночей за изучением системы экспорта нормалей моделей сталкерским плагином, наблюдая, как ведут себя модели после импорта в майку через OBJ, FBX, игровой формат и последующего экспорта плагином сталкера. И выявилась одна интересная штуковина. Обычно формат OBJ хранит нормали модели в заблокированном (залоченном) виде. И после попытки экспортировать модель в .object и снова импортировать модель в майку мы увидим просто-напросто слетевшее сглаживание. Но восстановить его достаточно просто, переносом сглаживания с оригинальной модели на модель, побывавшую в формате СДК. Если же мы импортировали в майку модель через FBX, то такой поломки не будет. Так или иначе, снова экспортировав\импортировав модель, мы обнаружим, что со сглаживанием всё в порядке. Или не совсем... Иногда моделлеры делают сглаживание на лоу-поли моделях следующим образом: скрин 1 скрин 2 На картах нормалей же это выглядит так: скрин 1 скрин 2 И всё бы ничего, если бы не одно НО: как сталкерский плагин, так и СДК, не умеют работать с таким сглаживанием, и как бы мы ни старались, на выходе в игровом формате мы получим следующее: скриншот Разумеется, после такого оригинальная карта нормалей попросту не подойдёт к модели. Не знаю, насколько это в тему, но если экспортировать модель скриптами макса, то сглаживание сохранится. Однако оно снова собьётся при прогонке модели через СДК. Замкнутый круг в общем. Есть как минимум 2 способа исправить ситуацию. Первый, и самый очевидный - сменить модель. Если же это нам не подходит, то придётся попробовать себя в качестве моделлера и "перезапечь" нормали. Но это уже, как говорится, совсем другая история. Все манипуляции с моделью проводились в майе 2017. На более ранних версиях не тестировалось.

@ed_rez, это не прокатит. Ведь цель - перенести помимо модели ещё и анимации. Тем более из ТЧ в ЗП. Там ведь скелеты рук и оружия идут по отдельности. @ptichkin, в первую очередь нужно знать, на каких руках сделаны анимации в варианте для ТЧ. Если там руки из оригинального ТЧ, либо КСС+ЧН, то перенести на ЗП без глубоких знаний в анимировании ну никак не получится, т.к. там разные скелеты рук, к тому же в ЗП руки от разных костюмов взаимозаменяемы, что не даёт использовать для данного оружия руки, отличные от остальных по скелету. Придётся прибегнуть к способу аттача двух скелетов друг к другу и снятия анимаций подобно "мокапу", если нет опыта в анимировании, то лучше за это даже не браться. Если же анимации руках ЗП, то перенести их будет проще, нужно будет разделить скелеты рук и оружия (в данном случае ножа), и экспортировать анимации для них по отдельности. Ну а дальше уже дело за настройкой в СДК. Стоит отметить, что если на анимациях в ТЧ используются руки ЗП, то, скорее всего, они уже когда-то были перенесены из ЗП в ТЧ, и есть шанс, что можно найти эти же самые анимации в оригинальном виде, то есть под Зов Припяти, тем самым облегчить свои труды.

@ptichkin, приветствую. Данная ошибка заключается в том, что сталкерский плагин может экспортировать не более одного меша, привязанного к одному скелету. Т.е. данный худ должен быть одним единым мешем. Чтобы избавиться от сей проблемы, нужно объединить все меши в один общий (Рабочая среда "Modeling" -> Mesh -> Combine), при этом не забыв в настройках "комбайна" поставить галочку у "Combine Skinning": скриншот В противном случае при экспорте произойдёт похожая ошибка, только вместо "multiple meshes" будет "multiple skin clusters".

@killersan6 Скриптовая отдача при стрельбе? Глянь это: https://yadi.sk/d/njcqN0zo3LFhMR

Вроде он самый.

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

@vadyan Досконально прочекал весь свой худ. Оказалось, что правильная ориентация джоинтам пальцев рук была выставлена обыкновенной ротацией джоинтов. На оружии же я делал кастомные оси вращения, и, судя по всему, зря. Вот это я и хотел выяснить. Значит способ, которым я исправлял ориенты костей на мировые, был единственным верным. Анимации таки пришлось адаптировать к новому скелету и бинд-позе. Что ж, впредь буду учитывать, что плагин сталкера и сам сталкер этого не поддерживает, спасибо за информацию.

@rex44 Фриз чего? Джоинтов? Вряд ли тут сие поможет, потому что они по дефолту не имеют трансформаций, да и это не позволяет сделать скин-кластер, к которому присоединены джоинты. Сбивается ориентация джоинтов, причём именно тех, что были созданы непосредственно в майе. Костыльно я решил проблему: создал дубликаты модели худа и скелета, привязал их друг к другу, скопировал привязку из оригинала, на оригинальном скелете сбросил привязку. Затем на оригинальном скелете исправил джоинт-ориенты на мировые, снова привязал меш к скелету, и скопировал оригинальную привязку с дубликата опять на оригинал. Дубликаты стёр, экспортировал модель, и всё стало в норме. Вот только анимации всё равно пришлось править и заново экспортировать. Но почему майка некорректно экспортирует кастомные оси вращения джоинтов, созданных непосредственно в ней, я не пойму до сих пор. Никогда ранее с таким не сталкивался.Вопрос о причине и способе исправления пока остаётся открытым.

Всем хай. Ребяты которые знающие, тут такая проблема нарисовалась, касательно экспорта .object'ов. Имеется худ некоторого оружия. Скелет рук был импортирован уже готовым, для оружия делался непосредственно в майке. Локальная ориентация джоинтов на пальцах рук соответствует той, что должна быть: скриншот У оружия тоже есть джоинты, имеющие собственные джоинт-ориенты, отличные от мировых: скриншот После экспорта в .object у джоинтов оружия полностью слетают джоинт-ориенты (принимают мировую ориентацию): скриншот Это в свою очередь вызывает смещение джоинтов, дочерних по отношению к испорченным, вследствие чего анимации, сделанные для этого оружия, также воспроизводятся с косяками. При этом с пальцами на руках такого нет, всё в норме. Наблюдался ли ранее такой баг с джоинт-ориентами при экспорте для стулкера, и можно ли как-то обойти этот момент? Быть может, дело в плагине? Майка имеет версию 2017, если что. Заранее спасибо.

@aka_sektor, стало быть, так и есть. Просто у меня все статичные объекты локаций, которые я когда-либо редактировал, были исходниками, а те объекты, что были когда-то тронуты конвертёром - динамические (НПС, худы оружия и т.п.). На основе этого и был первоначальный вывод.

@aka_sektor, тип сглаживания #1 сделан специально для динамики, #2 - для статики. Может и ошибаюсь, но у меня зачастую так было.

@ed_rez, есть у меня знакомый, который буквально недавно опробовал 18-ый. Говорит, что по сравнению с предыдущими версиями он лучше во всём. Быстродействие на порядок выше, также удобнее работать с UVW-редактором, и глюков меньше. Но от себя могу добавить, что один и тот же макс на разных машинках может вести себя абсолютно по-разному. У кого-то определённая версия может быть весьма стабильна, при этом у другого она может часто лагать и вылетать, и это при схожих ТТХ железа. Тут вариант один — проверять самостоятельно и на своём железе, так сказать "брать с поличным", надёжнее будет.

@Plotnik, само по себе число в 8000 частиц в одном эффекте - весьма страшная цифра, независимо от размера текстуры, которая будет отрисовываться 8000 раз. Процессор просто не справляется с обработкой каждой, поскольку ему приходится рассчитывать координаты каждой частицы в пространстве. Отсюда и столь сильные лаги. Я делал партиклы, в которых появлялось 4000+ частиц на несколько секунд. Казалось бы, всего лишь на пару секунд, но тем не менее, имел место быть резкий скачок fps в сторону понижения, и довольно-таки ощутимый. Советую, как вариант, создать текстурное полотно со скоплением снежинок на нём, и в партикле выводить уже не 8000 частиц, а на порядок меньше, тем самым нагрузка распределится между процессором и видеокартой. Часть нагрузки будет переброшена на видеокарту, которой понадобится отрисовывать текстуры, а часть останется на процессоре, и тогда, быть может, производительность будет несколько выше. Но я не уверен в этом на 100%, нужно тестировать. К тому же пропадёт часть рандомности движения снежинок, что сказывается на красоте. Тут годятся в помощь уже рандомные текстуры.

Держи: https://yadi.sk/d/j6EjpPeS33q9hj

Лично у меня не возникало проблем с импортом в СДК перепакованных файлов particles.xr. Бывало, за день раз 8-10 распаковывал\запаковывал файл, и безо всяких проблем открывал его в СДК. Может быть, дело в самом СДК - я использую СДК 0.4 от Юршата, собранный из исходников. Судя по всему, он не требует никаких изменений перед импортом в него редактированного файла. Может, полезнее будет использовать именно его в этом плане. Единственный минус - там по дефолту, в отличие от ПЫСовского СДК, сбиты настройки хоткеев. Горячие клавиши воспроизведения\остановки лучше вынести на удобные кнопки клавиатуры.

@Fagot., приветствую. Есть такой партикл, зовётся a_ufp_particles\cigarette_dust. Он мне, кажись, из одной из солянок достался. В оригинале имеет цвет пурпурно-синий, чисто под атмосферу, а также лимит в 3 минуты. У меня имеется 4 варианта: 3-х минутный и бесконечный пурпурные, а также такие же, только обесцвеченные, серые. Для работы нужен свой шейдер, поэтому прилагаю shaders.xr, подходящий к данным партиклам. Текстура вроде бы используется из оригинальных текстур дыма ТЧ. Ссылка: https://yadi.sk/d/VuKnM6S832ggH3

@Fagot., путь к самому эффекту не считывается с папки, в которой он лежал при запаковке. Если открыть .pe файл блокнотом\текстовым редактором, то можно увидеть, что его путь\название прописаны в самом нём. Если запаковать такой particles.xr, а потом снова распаковать, то файл эффекта естественно пропадёт, т.к. его название не совпадает с тем, что записано в самом файле. Самый лучший способ исправить ситуацию - открыть particles.xr в редакторе партиклов, и самостоятельно "превратить" данный эффект в пустышку, удалив все экшены (действия эффекта), поправив сурс эффекта (там много параметров, требующих обнуления) и поставив текстуру-пустышку как основную. P.S. многие допускают ошибку, когда в распакованный файл партиклов кладут одинаковые файлы с разными названиями - именно из-за этого СДК потом ругается на дублирующиеся партикл-эффекты\группы, сам с таким сталкивался.

@Romann, в сети недавно появилось это, может сгодится?

@ed_rez, так я аналогично делал, только видео из редактора снимал, то есть из майки. Её же утилитами, чтобы иметь точную раскадровку. Но самый первый звук я делал даже не по видео (можно сказать, чуть ли не "на глаз", не буду говорить как), что видно по видео. Потом всё делалось с точностью до миллисекунд (десятых долей секунды вернее), уже по видео. Каюсь, накосячил, но тем не менее, в конечном варианте, думаю, всё отлично с синхронизацией, и не буду шелестеть особо и оправдываться, а то меня и так слишком много

@ed_rez, да звук в техническом плане был неправильным, то есть время между переводом затворной рамы в заднюю мёртвую точку (до упора назад, я не могу выразиться) и моментом её отпускания было слишком много времени, потом звук вставки магазина был персонально ускорен, и конец анимации\звука был ускорен. В общем ремастеринг был. Тем не менее, возьму на заметку, у меня Audition пылится без дела, а в Audacity нет смены скорости без смены высоты тона, насколько я знаю.