×
Menu

Optimize .NIF file content for better FPS

Обобщенные примечания о том, что и как делать с ниф файлом, дабы повысить фпс в игре.
 
0. Использовать минимальное кол-во шейпов в модели и сокращать кол-во Нод.
Это пожалуй самый важный момент влияющий на фпс.
Именно, количество "физических" объектов в ниф файле.
Чем меньше, тем лучше!
Кол-во Нод, тоже имеет значение, хотя они и не имеют "физической" оболочки, но их наличие, все же, оказывает влияние на фпс.
По возможности, следует вовсе избегать использования дополнительных Нод в ниф файле.
Одна корневая нода (без нее никуда), а в ее детях находятся только шейпы.
Однако, не следует заниматься фанатизмом, сокращая кол-во объектов в ущерб Выразительности.
Помимо лишних затрат времени, это может превратиться в паранойю!
И не следует забывать, что после 2012го года видеокарты стали получать стабильно больше 2х ГБ памяти.
Т.е. мощность компенсирует избыток полигонов!
 
1. по возможности,  использовать только монотекстуры (ака текстурный Атласы).
Сиречь, все детали одной модели помещать в один файл текстуры.
Подобное действо автоматически сократит кол-во шейпов при текстурировании модели в МАХе.
Собственно, шейпы и создаются по текстурному признаку. Одна текстура = один шейп.
Еще на создание новых шейпов в МАХ влияет материал объекта.
Однако, Атласы весьма плохо работают на больших поверхностях...
Т.е. "атласить" уместно броню, оружие, существ. Но не текстуры зданий!
 
2. Сокращать кол-во шейпов и их свойств.
Делается это в нифскопе путем нехитрых действий.
В целом, чем меньше деталей в ниф файле, тем лучше.
Т.е. после экспорта новой модели из МАХ, ее следует обязательно проверить в нифскопе.
Разумеется, любые иные модели, можно оптимизировать таким образом.
Однако, всегда надо помнить, что выразительность модели должна стоять на первом месте!
И чрезмерное увлечение оптимизациями не всегда хорошо.
 
3. правильно применять флаги альфы.
Т.к. некоторые значения альфы оказывают крайне негативное влияние на фпс!
Модели без Альфы, показывают большее число ФПС, чем модели содержащие Альфу.
Если возможно, использовать только режим Тестирования, без смешивания.
 
4. Смотреть за кол-вом полигонов на модели.
На самом деле, МВ довольно легко переносит модели с очень большим кол-вом полигонов, но не стоит этим злоупотреблять.
20к полигонов на кольце, которое едва заметно в сцене - явный перебор.
Но те же 20к на качественной броне - нормально.
 
5. Учитывать игровой размер модели.
Это касается в основном строений.
Размер одной детали не должен превышать 2048 ед. Но лучше ограничится 1024.
Слишком большие модели, как и слишком большие полигоны, плохо влияют на фпс.
 
6. Оптимизировать коллизии.
Касается строений и активаторов.
Просчет столкновений является слабым местом МВ, а сложная геометрия колижена может привести его в ступор.
Т.е. не забывать создавать РутКолиженНоду для статиков и активаторов.
 
7. Использовать LOD.
Изменять уровни детализации моделей.
В т.ч. отключая контроллеры анимаций на удаленных от глаз ГГ объектах.
 
8. Использование Instancing Geometry.
Если позволяет ситуации, то использовать ссылку в разных triShape на один общую  triShapeData.
Это позволяет сократить повторы геометрии объектов.
Достаточно клонировать объекты в режимах Instance или Reference.
 
Например, такое удобно использовать в LODах.
Где, дальние уровни не используют анимацию и очищены от всего лишнего.
А ближние, используют все в полной мере.
Конечно это можно назвать "излишками", но в некоторых случаях особо тяжелых моделей, такое было бы вполне уместно.
Что самое интересно, это возможность применять этот метод прямо в 3д МАХ!
Т.е. экспорт общей шейпдаты для нескольких шейпов - возможен!
ТЕСэкспортер и ФФЕ умеют это делать. Нифтулз - нет.
 
При этом, в нифскопе, возможно повесить уникальные контроллеры анимаций и свойства на каждый шейп!
Отчасти поддержано и в МАХе, если использовать режим Reference. Если объект получит уникальные свойства, то и шейпдата станет уникальной.
Т.е. объекты могут проигрывать уникальные анимации используя общие данные геометрии.
Кроме объектов, общую дату, можно использовать и на частицах!
Кроме особо прогрессивного случая создания потока частиц на основе другой системы частиц.
В этому случае, придется использовать разные даты.
Общая "дата" для частиц, возможна только через нифскоп, МАХ не позволяет клонировать частицы в режимах Инстанс и Референс.
 
9. Не использовать большие текстуры без реальной необходимости.
Например небольшому кольцу вполне хватит текстуры 256х256.
Но для стены здания будет уместно применить 2048 и даже больше!
Чем выше разрешение текстур, тем быстрее будет заполняться память видео карты, что собственно и будет влиять на фпс.
Но надо учитывать, что при использовании монотекстуры с разными картами, ее размер увеличится на 4 и более.
Хотя видимая в игре деталь будет меньшего разрешения.
Отчего такие монотекстуры (атласы), не очень хороши для использования на больших поверхностях.
 
Также, монотекстуры (Атласы) имеют техническую особенность связанную с работой мип-уровней.
Отчего, может возникать излишний "шум" на некотором удалении от объекта в игре.
Т.е. текстура становится излишне резкой, либо наоборот - размытой.
Поскольку все детали находятся в одной текстуре, то на каждую из оных приходится меньше пикселей в ЛОДах текстуры.
Что и приводит к появлению артефактов на ближних дистанциях.
 
10. Использовать флаги компрессии в настройках шейпов.
См. здесь.
Теоретически, изменение флага, может ускорять загрузку модели с диска и как-то оптимизировать работу оной в памяти.
Насколько актуально для МВ, не известно.
Т.е. тестов достаточных для получения достоверного результата, не проводилось.
 
11. по возможности помещать в один файл текстуры все текстурные карты.
Нормали, Детайл, Дарк, Глоу - если они конечно вообще используются.
Такое возможно, при использовании на модели нескольких UV размещенных по разным каналам.
Впрочем, этот метод не слишком удобен и занимает больше времени при работе с моделью.
Да и пользоваться оным можно далеко не всегда.
Однако, если это возможно - то можно попробовать.
Это, еще больше сократит кол-во файлов на диске, что также, в теории, сделает прибавку к фпс при подгрузке текстур в память.
Также, такой метод, может иметь проблемы с созданием Атласа.
 
Экспериментально.
Сократить число нод в ниф файла можно за счет переноса их контроллеров, на отдельный узел.
Т.е. все контроллеры, можно убирать с их исходного объекта и помещать в отдельную цепочку контроллеров принадлежащую совсем иному узлу.
Это позволяет сокращать кол-во нод в ниф файле, что несколько сокращает его размер.
Подробности см. в разделе общих свойств контроллеров.
Однако, этот метод не автоматизирован и создавать очень длинные цепочки последовательно прописывая контроллеры друг за другом - долго и неудобно. Также могут получаться ошибки в указании целей.
Что может происходить, когда целевая Нода контроллера заменяется на шейп.
Т.е. банальные ошибки ввода номера могут получаться, что, закономерно, приведет к багам модели.
Однако, простые модели можно свободно оптимизировать таким методом.
 
Собственно это и есть основные рекомендации.
- Меньше шейпов и нод!
- Меньше файлов текстур на nif файл!
- Правильные подобранные свойства альфы!
- Разумное кол-во полигонов не слишком большого размера!
- Применение оптимизаций коллизий.
- Правильный подбор разрешения текстур.
- Удаление повторов свойств посредством Combine Properties.
- Загрузка объектов в LOD ноды.
- В особых случаях, где это позволяет геометрия, удаление повторов niTriShapeData.
Результатом подобных действий может стать существенное поднятие фпс в кадре!
 
Также, не стоит забывать о правильно дизайне локации!
Лучше создать много маленьких отдельных комнат, чем одно большое помещение в котором напихано все и сразу.
Т.е. чем меньше моделей в сцене, тем лучше для фпс.
На фпс, вместе с просчетом столкновение сильно влияет АИ ботов.
Отчего, чем меньше ботов в сцене, тем лучше.
Но выразительность и насыщенность локаций можно компенсировать за счет разнесения объектов из одной большой локации, во множество меньших.
Тоже касается и экстерьеров.
 
Примечание.
Все повторяющиеся свойства можно вешать на корень файла, или на ноду верхнего уровня.
Т.е. если несколько объектов имеют одинаковые свойства текстур, или материалов и пр., но сливать их в один по каким-то причинам невозможно.
Удобно скопировать их свойства на корень файла и удалить с самих объектов.
Это упросит последующее редактирование оных свойств, а также немного сократит размер файла.
 
Еще вариант, создать отдельную пустую ноду, куда прописать вообще все свойства со всех объектов.
Это удобно при редактировании модели, не требуется каждый раз искать, где и какие настройки лежат.
При этом, на саму модель, в игре, это никак не повлияет.
Кроме свойств, в такие "технические" ноды можно размещать, как контроллеры, так и эффекты.
Все добавленное сюда, должно быть ссылками, а не копиями! Иначе теряется смысл этого действия.
Хорошо, если добавленные, сюда, объекты будут иметь понятные названия (т.е. имена)!
А после завершения всех настроек, такую ноду, можно удалить.
Здесь свойства нескольких систем частиц помещены на ноду верхнего уровня, что позволяет воздействовать на всех сразу.
Также все свойствам прописаны имена, по которым сразу видно, кто есть кто и на что влияет.
 
При этом!
Вложенные, в такие ноды, объекты могут иметь дополнительные уникальные свойства. Например текстур.
И они не будут перекрываться свойствами верхнего уровня.
 
Техническая нода, куда были помещены ссылки вообще на все свойства и контроллеры в файле.
Это удобно при отладке сложных файлов со множеством анимаций и свойств.
Хотя указание имен и прописывание занимает некоторое дополнительное время...
 

Примечание.
 
Текстурный атлас.
https://ru.wikipedia.org/wiki/Текстурный_атлас (С)
В компьютерной графике реального времени, тексту́рный а́тлас (англ. Texture atlas) — это изображение, содержащее набор (или «атлас») под-изображений, каждое из которых является текстурой для некоторого 2D или 3D объекта. Под-текстуры отображаются на объект, используя UV-преобразование, при этом координаты в атласе задают, какую часть изображения нужно использовать. В приложениях нередко используется множество маленьких текстур, причём переключение с одной текстуры на другую является относительно медленным процессом. Поэтому в подобных ситуациях бывает целесообразно применение одного большого изображения вместо множества маленьких.
Например, в играх с tile-графикой можно получить хороший выигрыш в скорости вывода картинки.
Атласы могут содержать как под-текстуры одинаковых размеров, так и под-текстуры отличающихся размеров (обычно, являющихся степенью двойки). Для составления атласов используются как программы-генераторы, так и ручное составление. При использовании MIP-текстурирования необходимо предусмотреть, что под-текстуры должны быть расставлены таким образом, чтобы не возникало ситуации, когда одна из них «залезает» на другую.
 
Примечание.
На основе всех этих данных был собран Morrowind Optimization Patch
https://www.nexusmods.com/morrowind/mods/45384
Существенно улучшающий производительность игры.
Обращайте внимание на этот плагин (в образовательных целях).
 
Примечание.
Проект Атлас.
https://www.nexusmods.com/morrowind/mods/45399
Еще один патч, созданный для повышения производительности игры.
Здесь, отдельные файлы текстур были собраны в единые монотекстуры.
Что позволило объединить шейпы некоторых моделей.
 
Hrnchamd писал:
Wrapping textures is the problem with atlases
Сиречь проблема атласов в излишней размытости, или наоборот, в излишней пикселизации.
Вероятно, атласы более уместны для небольших объектов, чем для больших поверхностей.
См. раздел ниже. Атлас Креатор.
 
Примечание.
Morrowind Texture Atlas Creator
https://www.nexusmods.com/morrowind/mods/47199
Утилита по авто созданию атласов!
Загружаем список текстур, все остальное она сделает сама.
 
Примечание.
В теории, можно было бы еще рекомендовать использовать niTriStrips вместо nitriShape т.к. это должно (согласно справке) значительно повышать фпс!
Но, к сожалению, техника создания стрипсов под МВ плохо изучена, хотя были найдены вполне работоспособные модели и найден плагин могущий из создавать.
Равно, в ряде тестов, Стрипсы приводили к прямо обратном - т.е. к существенному падению фпс.
Иные тесты вовсе не показывали влияния стрипсов на фпс в ту или иную сторону.
В ряде игр, стрипсы, применяются только на небольших объектах. Оружие, предметы.
Т.е. движок МВ, не очень хорошо работает со стрипсами и их использование оправдано только в экспериментальных целях.
 
Пичаль(
Увы, беседка подложила такую хорошую и жирную свинью в плане качества своих моделей, т.к. все начинающие модмейкеры начинают с копирования техник и общего визуального ряда оных.
Что породило любовь к "ванильному стилю" и тонны плохо  оптимизированных  мешей.
Впрочем, в использованной беседкой технике создания мешей есть свой плюс... они не отпугивают своей сложностью.
И позволяют плодить их тоннами в кратчайшие сроки.
Т.к. минимизируется время на создание текстуры и UV развертки.
Но это же мешает создавать что-то более качественное, в плане сложности и выразительности объектов.
Но если простота моделинга и текстуры можно списать на Визуальный Стиль игры - то отвратное качество исполнения и организации самих файлов, не может не вызывать глубокого огорчения.

Влияние кол-ва шейпов на фпс.
*скриншот взят с https://www.nexusmods.com/morrowind/images/
 
Хорошо показано влияние АИ на фпс.
 
Влияние шейпов на фпс в чистом виде.
Обратите внимание на кол-во полигонов!
Поскольку не требуется просчитывать столкновения, фпс в разы выше, чем в сцене с Ботами.
Влияния флага альфы на фпс.
237 флаг альфы  ->115 фпс.
4844 ->160
модель растений с несколькими шейпами!
Монотекстура грибов.
На выходе, получается единый шейп в модели.
Также, можно совмещать текстуры разных предметов в одном файле,
что еще больше сократит кол-во файлов текстур.
Балмора с текстурами проекта АТЛАС.
Одно здание = один шейп.
И 232 фпс в кадре!
О Стрипсах см. их раздел.
 
Утилита по созданию атласов да.
Ванильные модели и обычные текстуры.
Но разрешение экрана 2560...
И "атласированные" текстуры.
Наиболее заметно размазанные текстуры крыш кантонов.
Но есть былинный прирост фпс, если приглядеться, конечно.