@perture, да, я так и делаю обычно - меняю данные шейпа. Но иногда копирую и скин. В общем то, это эквивалентные операции. А вот точно два скина моделей 0 и 1 тела одинаковые?
samir979, Зачем вам ванильные манекены, если вы поставили реплейсер LB? Ведь у вас же теперь и одежда вся LB и она не оденется на ванильные манекены. Впрочем, это дело ваше. В моде, который заменил вам ванильные манекены, изменён, скорее всего, ванильный манекен. Значит, его надо откатить обратно. Я бы это сделал с помощью TES5Edit в пару кликов мышки. Кажется, можно отменить изменения и редактором, но я не знаю как, за ненадобностью мне этой опции :). Можно просто тупо открыть редактором ванильный манекен (без загрузки мода), записать настройки и повторить их в этом моде.
Столкнулся со странным явлением. Делаю броню и там у меня есть 2 варианта - с юбкой и без. Броня на базе стеклянной с эффектами прозрачности и преломления. Это требует двух идентичных по данным нитришейпа, которые различаются только настройками отображения текстуры. Из экономии размера файлов появляется соблазн использовать в обоих нитришейпах один и тот же NiTriShapeData и, соответственно, один и тот же BSDDismemberSkinInsnance для него. Так вот, для кирасы без юбки (и для других элементов брони) это проходит на ура, всё работает. А вот для кирасы с юбкой происходит вылет на рабочий стол при одевании. Это лечится созданием и использованием дубликата BSDDismemberSkinInsnance. Т.е. по-прежнему можно использовать в двух нитришейпах один и тот же NiTriShapeData, но BSDDismemberSkinInsnance в них должны быть разделены, хотя они и совершенно одинаковые. Это увеличивает размер файла. Две модели различаются только набором костей (юбка и рукава). Закавыка - хочу понять, почему в одном случае можно объединять данные и скины, в другом скины должны быть раздельными?
Cardboarddog, anton, видимо я недостаточно подробно описал свою проблему. Попробую разъяснить. Есть две отдельные модели:
1.) Кираса, состоящая из двух нитришейпов. Два потому, что один отвечает за текстурирование модели, а второй за преломление лучей в прозрачных участках. (На самом деле, сложнее, там у меня три нитришейпа. Ещё один - маска для обеспечении разницы блеска металлических и стеклянных деталей, но дело не в этом третьем шейпе.) Эти два нитришейпа имеют совершенно идентичную форму и должны двигаться совершенно одинаково. Поэтому они оба имеют идентичные таблицы вертексов треугольников, нормалей и текстурных координат, т.е. одинаковые NiTriShapeData. А так как двигаться они должны одинаково, то и скины их (BSDDismemberSkinInsnance) тоже идентичны. 2.) Кираса с юбкой и рукавами. Юбка и рукава находятся в одном шейпе с кирасой, но нитришейпа опять два. И, точно так же, как и в первом случае, эти нитришейпы имеют одинаковые NiTriShapeData и BSDDismemberSkinInsnance.
Оба случая отличаются только тем, что нитришейпы второго больше и завязаны на большее число костей. В частности на кости юбки.
Когда два нитришейпа внутри одной модели имеют одинаковый BSLightingShaderProperty, то можно вместо двух использовать только один BSLightingShaderProperty, ссылаясь на него дважды (указывая один и тот же BSLightingShaderProperty в обоих нитришейпах). Это я проделывал несколько десятков раз и проблем не имел никогда. Но это мало влияет на размер файла, так как запись BSLightingShaderProperty содержит мало информации.
А вот когда два нитришейпа имеют одинаковые NiTriShapeData, то использование одного вместо двух одинаковых даёт уже большой эффект, так как таблицы NiTriShapeData содержат много информации и занимают много места. Использование ссылок на один и тот же NiTriShapeData вместо двух одинаковых NiTriShapeData, у меня тоже не вызывает проблем. Вот это уже экономит место значительно.
BSDDismemberSkinInsnance тоже занимает много места, так как тоже содержит большие таблицы. А вот ссылка на один и тот же BSDDismemberSkinInsnance вместо двух одинаковых BSDDismemberSkinInsnance уже может создавать проблемы. Когда-то раньше я уже пробовал, получил вылет и забросил. А тут попробовал снова - всё работает (кираса №1). На самом деле, так у меня сейчас работают сразу несколько элементов брони (штаны, пояс, наплечники и т.д.). Но вот для кирасы №2 у меня это не работает, получаю вылет на рабочий стол при использовании одного BSDDismemberSkinInsnance вместо двух одинаковых. Вот и хочу понять, в чём дело. Раз есть случаи, когда работает (и не один), то значит, этот приём возможен. Но тогда надо понять, почему вылетает кираса №2.
anton, обнаружился один глюк при использовании SkinInjector. При внедрении нового BSDDismemberSkinInsnance в НИФ-файл происходит "размножение" Children у NiNode. Не оправдано возрастает их число и там появляются дублирующие записи - повторяющиеся ссылки на одни и те же кости. На работоспособности НИФа это не сказывается и может быть исправлено вручную, но всё равно не порядок А утилита по выявлению пустых названий шейпов была бы очень полезна. Сейчас я выявляю их открывая диалог переименовывания. Тогда там обнаруживается пустая строка.
Jukoman, в игре за вид от первого лица и от третьего обычно отвечают разные модели. В одежде Лейи должно быть больше нитришейпов. Как минимум 2 - одёжка и тело.
Artem13, L_Forest, разработчики по-видимому делают так: сначала собирают интерьер по сетке, тогда всё стыкуется хорошо, а потом целые блоки пододвигают и поворачивают уже без сетки. Вот так и получаются дробные значения. Я стараюсь их не округлять. Ведь если фрагмент участка стены повёрнут на угол не кратный 90 градусов, то отдельные участки всё равно по сетке не стыкуются. Так что. если надо только 1-2 фрагмента поправить, просто сильно увеличиваю и минимизирую швы. Или швы можно прикрыть чем-нибудь. Любой подвинутый объект сразу считается изменённым и входит в мод, и он разбухает. Кроме того, это источник возможных конфликтов. Если в моде загруженном перед этим модом данный объект был удалён или заменён, а мы его подвинули, будет вылет на рабочий стол, так как наш мод не найдёт объекта, который в нём подвинут.
Multigone, если плагин привязали к мастер-файлу, то только по двум причинам: либо по глупости , либо в плагине используются объекты из мастер-файла. Надеюсь, что первый случай встречается редко , а во втором, нужно перед отвязыванием создать все необходимые объекты в плагине (сделать их работающие копии тех, что в мастер-файле). Пока речь идёт о предметах и персонажах, это не трудно. Хуже с квестами и диалогами... Но если плагин задействует квесты и диалоги из мастер-файла, то, может, и отвязывать не стоит. Ведь у автора мода был выбор - привязывать или нет и он выбрал привязку. Что-то знает?
Столкнулся со странным эффектом при создании LOD-ов деревьев для Тамриэля. Дело в том, что их ЛОДы оказались у меня ограничены ячейками -32 +32 по Х. Всё, что внутри - создаётся как надо, а для всех деревьев вне этого интервала ЛОДы создаются на внутренней границе ячеек -32 и +32, соответственно. Где-то возникло ограничение по оси Х, а я не пойму где.
Добавлено (18 Ноября 2014, 22:09) --------------------------------------------- anton, не удержался и проверил сразу. Прежде всего, очень удобно, что утилите можно подсовывать дерево каталогов. Я обнаглел и сразу сунул ей всю папку Meshes Небесного Замка, а это почти гигабайт моделей. Пыхтела утилита над этим добром порядка пол минуты. И выдала мне два файла - толстую и тонкую модификации одной одёжки. Посмотрел - так и есть - в НИФскопе там показывается название, но при попытке переименовать его обнаруживается, что в исходном файле названия нет совсем. Твоя утилита дала название DummyString_1. Так что вот, несмотря на все мои проверки, ошибки у меня оставались.
@perture, по моим наблюдениям, дублирование названий не создаёт никаких проблем. Но дело в том, что отсутствие названия ВЫГЛЯДИТ как дублирование названия. Если названия нет, то НИФскоп поставит туда некоторое из имеющихся у него в таблице. (Все, когда-либо дававшиеся этой модели названия, составляют её таблицу названий и сохраняются). Таким образом, происходит дублирование, т.е. повторение одного из уже имеющихся или существовавшего ранее. Наиболее вероятно использование корневого названия. Подумайте сами, ведь не существует другого способа получения дублирующих названий. Ведь если название будет давать сам мододел, то он даст уникальное, просто для своего удобства. Фальшивость названия выявляется при его редактировании. Если там реальное название, то оно будет показано в окне редактирования с возможностью изменения. Если же там на самом деле пусто, то в окне редактирования будет пустое поле. Вот пустое название и приводит к вылетам. Что интересно, иногда эти вылеты происходят с вероятностью ниже 100%.
Кстати, таблица сохранённых названий часто является причиной различия веса файлов двух одинаковых моделей (например, худой и толстой).
anton, может, добавить утилите ещё функцию чистки таблицы названий нодов? Удалять неиспользуемые названия. А то удалять лишние в конце списка легко, просто изменяя там число записей, а вот из середины - фиг
BlackTea, сначала надо обеспечить работоспособность редактора. Ему мешает что-то, что вы поставили в Скайрим. 1. Проверьте целостность кэша (файлов) стандартной Стимовской процедурой. Все родные дефектные файлы будут загружены заново. 2. Если первый пункт не помог, удаляйте установленные моды по одному, пока проблемы не исчезнут. 3. Проблемы могут и не исчезнуть, так как многие моды просто трудно удалить до конца и мусор от них может остаться. В этом случае, надо удалить все файлы и поставить Скайрим и редактор заново.
Arin, такое может быть, когда становится видной дефектная модель. Их хорошо бы проверить утилитой Антона. Ещё это может происходить, если в поле зрения попадает слишком много одинаковых нестатических объектов. Например, драгоценных камней, или выдвигающиеся штыри решётки (критическое число порядка 100).
Arin, получается, что зал симметричен, а вылеты - нет. Вылеты обязательно связаны с чем-то несимметричным. Надо найти причину. Я бы попробовал удалять стены. Просто для того, чтобы убедиться, что они не виноваты, либо найти там виновника. Чтобы потом не восстанавливать их, надо сохранить отдельно вариант с ними. Ещё очень важно тестировать с чистого сейва. Дело в том, что несимметричный объект может оставить следы в сейве и так проявлять себя, не смотря на то, что он был удалён. Антивирусу надо сказать, чтобы он игнорировал утилиты Антона. Эта утилита проверяет названия узлов моделей. В ветке по моделированию она совсем недавно обсуждалась. Можно сделать это и вручную НИФскопом. Надо попробовать переименовать названия нитришейпов. Переименовывать не надо, нужно только убедиться, что в поле редактирования названия не пустое место.
valambar, это из разряда ловушек. В Скайриме есть специальные локации для разработчиков, где сложены образцы как надо делать. Названия таких локаций начинаются с Warehouse, а та, что нужна, называется WarehouseAmbushes.
Ведь придётся описать в программе все блоки, способные иметь индексы имён и потом перелопачивать их. У меня же описаны всего лишь около 20 основных, с которыми мне приходилось работать. К тому же выгода маленькая, просто НИФ файл станет опрятнее выглядеть.
Может, такой подход поможет. Очистить этот список можно и вручную. Просто ставится его длина равной 1. Тогда там останется только название корневого нода. Все остальные станут пустыми, но НИФскоп будет показывать для них название корневого нода. Если теперь их все переименовать вручную, то получим чистый список. Разумеется, это очень муторно, а с большим количеством костей совсем в каторгу превращается. Что, если автоматически делать так же. Т.е. отделить функцию очистки списка от функции проверки. Сначала проверка так, как она у тебя реализована. В результате все потерянные узлы получают названия. А вот после этого уже не разбирая узлы по типу просто составить в утилите сквозной список их названий. Дальше очистить список НИФскопа и забить туда созданный список. Т.е. не проверять список НИФскопа на наличие его названий в модели, а создать ему новый. Вопрос только в том, не нарушится ли порядок названий в списке.
Это не очень нужно, просто так мой перфекционизм проявляется
@perture, давно хотел задать пару вопросов: 1. Зачем ставить в модели Vertex Colors белый для всех вертексов, устанавливая и шейдерный флаг SLSF2_Vertex_Colors? Это сильно отличается от случая, когда цвета вертексов и соответствующий флаг совсем не стоят? 2. Есть ли смысл ставить флаг 4097 для модели тела, если нормали там всё равно не используются?
@perture, спасибо. Эти вопросы возникли у меня из рассмотрения тел куда более известного модмейкера, чем я. Настолько авторитетного, что я должен был перепроверить эти факты, почему и спросил
BlackTea, редактор есть только один - тот, что изготовила Беседка и который устанавливается через Стим. Вопросы по всем остальным задавайте тем, кто их делал.
Для движка нужен массив куда он запишет оттенок, для этого и нужно создать белые вертекс колоры.
Оп! Интересный способ выделения памяти под массив Поистине, неисповедимы пути твои, Господи! А какой оттенок и зачем туда заносить? Белый цвет в VertexColors это 4 коэффициента, равные 1. Т.е. это значит, что никакие величины на эти единицы умножать не надо. Отсутствие соответствующего шейдерного флага говорит видеокарточке о том, что обрабатывать эти цвета не надо.
На самом деле, цвета вертексов это одна из оптимизирующих технологий. Дело в том, что хороший программист всегда оптимизирует свой код. Он не положит большую текстуру, где достаточно маленькой и не положит две, где достаточно одной. Так вот, цвета вертексов придуманы для того, чтобы использовать одну и ту же текстуру на многих объектах. Так как объекты имеют разную форму, то тени на них будут разные и их (тени) нельзя включить в одну текстуру. Это старая технология возникла на самой заре 3D-графики, когда винчестеры были ещё маленькими, а видеопамять очень дефицитной. Это позволяло положить в игрушку только одну текстуру вместо многих и в видеопамять грузить только одну текстуру вместо нескольких. Так В Скайриме устроены скалы. Там много разных скал и все они используют VertexColor и только одну текстуру. Интересно посмотреть, что там сделано с ЛОДами для них. Дело в том, что вид на дальних расстояниях есть не для всех скал, а только для некоторых и текстуры для видов на расстоянии намного меньше. Так вот, для ЛОДов первого уровня ещё допускается использование VertexColors и одной общей текстуры для скал. А для всех менее детализированных ЛОДов использование VertexColors уже не допускается (опять оптимизация скорости рисования) и используется десяток индивидуальных маленьких текстур. Тени нанесены уже на эти отдельные текстуры. Таким образом, использовать технологию VertexColors для тел имело бы смысл только в том случае, если бы в игре одна и та же текстура использовалась как для людей, так и (например) для лошадей и для зайцев. Тогда бы текстура была одна, а карта теней была бы вынесена в VertexColors моделей.
Arin, отдельные детали позволяют гибко изменять конфигурацию помещения и могут использоваться в разных помещениях. Кроме того, по-идее (по крайней при использовании технологии комнат-порталов) отрисовывается не всё помещение, а только те детали, которые находятся в поле зрения. Если же всё помещение будет одной моделью, то и рисоваться оно будет всё в любом случае.
Нет, по этой технологии рисуются только те объекты, что видны через портал. Т.е. только некоторые стены. В случае, если комната будет целой моделью, то и рисоваться она будет вся.
Aksyonov, если этот предмет сохранён (в сохранении) как не имеющий этой галки, то он будет падать. Можно сделать новый предмет, а старый убрать. Тогда в старом сохранении не будет нового предмета и галка будет работать. Только старый предмет надо не удалять, а убрать за стену. Иначе если другой мод обратится к этому предмету, будет вылет на рабочий стол.
Aksyonov, я видел в игре только два способа закрепления предметов. Использовал оба.
Первый, тот что описал VALKNUT, годится для предметов висящих совсем в воздухе, да и вообще где угодно. Так в игре сделан Древний Свиток. Висит статик, на нём активатор, на активаторе скрипт, убирающий статик и экипирующий персонажа нужным предметом. Взад персонаж никакими силами этот Свиток не повесит.
Второй, самый распространённый в игре для воткнутого везде оружия - просто поставленная галка Don't Havok. Работает исправно, но только если рядом нет предметов или персонажей, которые могут столкнуть наш предмет.
Мы Вконтакте
у NiNode. Не оправдано возрастает их число и там появляются дублирующие записи - повторяющиеся ссылки на одни и те же кости. На работоспособности НИФа это не сказывается и может быть исправлено вручную, но всё равно не порядок