Об оптимизациях NIF файлов
Обобщенные примечания о том, что и как делать с ниф файлом, дабы повысить фпс в игре.
Скриншоты и некоторые примечания по текстурным атласам, см. во вложенной статье, здесь.
0. Использовать минимальное кол-во шейпов в модели и сокращать кол-во Нод.
Это пожалуй, один из самых важных моментов влияющий на фпс.
(после шейдеров и разрешения текстур конечно)
Именно, количество "физических" объектов в ниф файле.
Чем меньше, тем лучше!
Кол-во Нод, тоже имеет значение, хотя они и не имеют "физической" оболочки, но их наличие, все же, оказывает влияние на фпс.
Т.е. игра занимается их просчетами и тем, на что оные ноды влияют еще.
По возможности, следует вовсе избегать использования дополнительных Нод в ниф файле.
Одна корневая нода (без нее никуда), а в ее детях находятся только шейпы.
Однако, не следует заниматься фанатизмом, сокращая кол-во объектов в ущерб Выразительности.
Помимо лишних затрат времени, это может превратиться в паранойю!
И не следует забывать, что после 2012го года видеокарты стали получать стабильно больше 2х ГБ памяти.
Т.е. мощность компенсирует избыток полигонов!
1. по возможности, использовать только монотекстуры (ака текстурный Атласы).
Сиречь, все детали одной модели
помещать в один файл текстуры.
Подобное действо автоматически сократит кол-во шейпов при текстурировании модели в МАХе.
Собственно, шейпы и создаются по текстурному признаку. Одна текстура = один шейп.
Однако, Атласы весьма плохо работают на больших поверхностях...
Т.е. "атласить" уместно броню, оружие, существ и мелкие предметы.
Но не текстуры зданий!
Которые могут и любят использовать текстурный тайлинг и зачастую требуют большого разрешения текстур!
2. Сокращать кол-во шейпов и их свойств.
В целом, чем меньше деталей в ниф файле, тем лучше.
Т.е. после экспорта новой модели из МАХ, ее следует обязательно проверить в нифскопе.
Разумеется, любые иные модели, можно оптимизировать таким образом.
Однако, всегда надо помнить, что выразительность модели должна стоять на первом месте!
И чрезмерное увлечение оптимизациями не всегда хорошо.
Т.к. некоторые значения альфы оказывают крайне негативное влияние на фпс!
Модели без Альфы, показывают большее число ФПС, чем модели содержащие Альфу.
4. Смотреть за кол-вом полигонов на модели.
На самом деле, МВ довольно легко переносит модели с очень большим кол-вом полигонов, но не стоит этим злоупотреблять.
20к полигонов на кольце, которое едва заметно в сцене - явный перебор.
Но те же 20к на качественной броне - нормально.
5. Учитывать игровой размер модели.
Это касается в основном строений.
Размер одной детали не должен превышать 2048 ед. Но лучше ограничится 1024.
Слишком большие модели, как и слишком большие полигоны, плохо влияют на фпс.
6. Оптимизировать коллизии.
Касается строений и активаторов.
Просчет столкновений является слабым местом МВ, а сложная геометрия колижена может привести его в ступор.
Изменять уровни детализации моделей.
В т.ч. отключая контроллеры анимаций на удаленных от глаз ГГ объектах.
Т.е. объект загруженный в ближайшие уровни может иметь ЮВ, Флип, или иную другую анимацию.
Но на удалении выше чем (примерно; 1024->2048 и точно после 4096) загрузить уровень которые уже не использует эти анимации.
Как вариант, в некоторых случаях, всю базовую сетку можно заменить на спрайт с "фотографией", ака скриншотом объекта.
Это позволяет сократить повторы геометрии объектов.
Достаточно клонировать объекты в режимах Instance или Reference.
Например, такое удобно использовать в
LODах.
Где, дальние уровни не используют анимацию и очищены от всего лишнего.
А ближние, используют все в полной мере.
Конечно это можно назвать "излишками", но в некоторых случаях особо тяжелых моделей, такое было бы вполне уместно.
Что самое интересно, это возможность применять этот метод прямо в 3д МАХ!
Т.е. экспорт общей шейпдаты для нескольких шейпов - возможен!
ТЕСэкспортер и ФФЕ умеют это делать. Нифтулз - нет.
Отчасти поддержано и в МАХе, если использовать режим Reference.
Если объект получит уникальные свойства, то и шейпдата станет уникальной.
В этому случае, придется использовать разные даты.
Общая "дата" для частиц, возможна только через нифскоп, МАХ не позволяет клонировать частицы в режимах Инстанс и Референс.
9. Не использовать большие текстуры без реальной необходимости.
Например небольшому кольцу вполне хватит текстуры 256х256, а искре "магии" в частицах и вовсе 64х64.
Но для стены здания будет уместно применить 2048 и даже больше!
Чем выше разрешение текстур, тем быстрее будет заполняться память видеокарты, что собственно и будет влиять на фпс.
Но надо учитывать, что при использовании монотекстуры с разными картами, ее размер увеличится на 4 и более.
Хотя видимая в игре деталь будет меньшего разрешения.
Отчего такие монотекстуры (атласы), не очень хороши для использования на больших поверхностях.
Также, монотекстуры (Атласы) имеют техническую особенность связанную с работой мип-уровней.
Отчего, может возникать излишний "шум" на некотором удалении от объекта в игре.
Т.е. текстура становится излишне резкой, либо наоборот - размытой.
Поскольку все детали находятся в одной текстуре, то на каждую из оных приходится меньше пикселей в ЛОДах текстуры.
Что и приводит к появлению артефактов на ближних дистанциях.
10. Использовать флаги компрессии в настройках шейпов.
Теоретически, изменение флага, может ускорять загрузку модели с диска и как-то оптимизировать работу оной в памяти.
Насколько актуально для МВ, не известно.
Т.е. тестов достаточных для получения достоверного результата, не проводилось.
11. помещать вообще все типы текстур одной модели в единый файл.
Нормали, Детайл, Дарк, Глоу - если они конечно вообще используются.
Впрочем, этот метод не слишком удобен и занимает больше времени при работе с моделью.
Да и пользоваться оным можно далеко не всегда.
Однако, если это возможно - то можно попробовать.
Это, еще больше сократит кол-во файлов на диске, что также, в теории, сделает прибавку к фпс при подгрузке текстур в память.
Также, такой метод, может иметь проблемы с созданием Атласа.
12. Один объект (ниф файл) = один набор текстур.
Например, не следует помещать текстуры всех мечей в игре в одну общую.
Т.к. оные будут загружены в память, чем займут в ней место, практически на постоянку.
С одной стороны, это вроде бы хорошо - игра быстрее покрасит любой иной меч попавший в сцену и меньше вызовов к диску.
Но с другой, большой файл текстуры занимает много места в памяти, которого не так чтобы хватает на всех.
Учитывая лимит на 4гб в особенности.
А если установлено много текстурных плагинов, то загрузить все текстуры сразу в память... понадобится точно больше чем 8гб видео памяти.
Отчего такой метод, в чем-то хорош, а в чем-то наоборот вреден.
Память заполняется только необходимыми в данный момент текстурами, но увеличивается кол-во запросов к диску.
Т.е. приходится учитывать интересы других потребителей, так сказать.
Радикально!
Создайте виртуальный диск в памяти, особенно, если оной больше чем 32 гб.
На ютубчике, можно найти довольно видео на эту тему.
И скопируйте на него всю вашу папку с игрой.
Теперь, запускайте прямо из памяти!
Таким образом получается устранить самое узкое место в производительности - обращение к жесткому диску.
Экспериментально.
Сократить число нод в ниф файла можно за счет переноса их
контроллеров, на отдельный
узел.
Т.е.
все контроллеры, можно убирать с их исходного объекта и помещать в отдельную цепочку контроллеров принадлежащую совсем иному узлу.
Это позволяет сокращать кол-во нод в ниф файле, что несколько сокращает его размер.
Однако, этот метод не автоматизирован и создавать очень длинные цепочки последовательно прописывая контроллеры друг за другом - долго и неудобно. Также могут получаться ошибки в указании целей.
Что может происходить, когда целевая Нода контроллера заменяется на шейп.
Т.е. банальные ошибки ввода номера могут получаться, что, закономерно, приведет к багам модели.
Однако, простые модели можно свободно оптимизировать таким методом.
Также, не стоит забывать о правильно дизайне локации!
Лучше создать много маленьких отдельных комнат, чем одно большое помещение в котором напихано все и сразу.
Т.е. чем меньше моделей в сцене, тем лучше для фпс.
На фпс, вместе с просчетом столкновение сильно влияет АИ ботов.
Отчего, чем меньше ботов в сцене, тем лучше.
Но выразительность и насыщенность локаций можно компенсировать за счет разнесения объектов из одной большой локации, во множество меньших.
Тоже касается и экстерьеров.
Примечание.
Хотите БОЛЬШОЙ БИТВЫ с десятком и более Неписей сразу?
- создайте пустой зал с минимум препятствий в виде тонких колон и наваленных "валунов".
По возможности, избегайте много ярусности и коридоров между этажами, это очень дурно влияет на АИ.
Которое все равно все видит, но проложить правильный путь до цели, через сложную геометрию, не возмогает.
И не забывайте про создание path greed!
Если хотите просто Красоты, то создайте ее!
Но не помещайте в локацию много Нпс и тем более, не пытайтесь устраивать там сражения!
Примечание об оптимизации модели в Нифскопе.
1.
зайти в меню Spell->Optimize->Combine Properties.Что удалит все повторяющиеся свойства материалов и текстур.
Это действие следует проводить всегда в финале полировки модели.
Не следует делать это в начале доработки ниф файла!
Но только после завершения всех прочих действий, если таковые конечно имели место быть.
2. если этого недостаточно, можно попробовать объединить несколько шейпов в один.
Работает только в случае одинаковой текстуры, по каким-то причинам разделенной на несколько шейпов.
Для этого в ручную прописать одинаковые текстурные и материальные свойства объединяемым шейпам.
Также проверить наличие Has Vertex Color в
triShapeData - в обоих случаях должно быть NO.
Шейпы должны находится в одной ноде!
ПКМ по этой ноде и
Combine Shapes - это соединит несколько шейпов в один.
*обратите внимание, для нифскопа 1.1.3 опция комбинирования шейпов не работает на корневой ноде.
*также не следует соединять сильно полигональные поверхности. Лимит на один шейп 65к треугольноков.
*если у одного шейпа, в шейпдате есть настройки цвета вертексов, а у другого нет, то слияния шейпов не произойдет!
Has Vertex color должен быть равен для всех шейпдат. Либо Yes, либо No.
3. можно сократить кол-во нод, если это возможно для конкретного файла.
Также, существует утилита Sniff.
Которая позволяет, как пакетно, так и по штучно, проводить различного рода оптимизации ниф файлов.
Т.е. для обновления массива файлов, это просто не заменимая вещь!
Примечание.
Все повторяющиеся свойства можно вешать на корень файла, или на ноду верхнего уровня.
Т.е. если несколько объектов имеют одинаковые свойства текстур, или материалов и пр., но сливать их в один по каким-то причинам невозможно.
Удобно скопировать их свойства на корень файла и удалить с самих объектов.
Это упросит последующее редактирование оных свойств, а также немного сократит размер файла.
Еще вариант, создать отдельную пустую ноду, куда прописать вообще все свойства со всех объектов.
Это удобно при редактировании модели, не требуется каждый раз искать, где и какие настройки лежат.
При этом, на саму модель, в игре, это никак не повлияет.
Кроме свойств, в такие "технические" ноды можно размещать, как контроллеры, так и эффекты.
Все добавленное сюда, должно быть ссылками, а не копиями! Иначе теряется смысл этого действия.
Хорошо, если добавленные, сюда, объекты будут иметь понятные названия (т.е. имена)!
А после завершения всех настроек, такую ноду, можно удалить.
|
|
|
|
Здесь свойства нескольких систем частиц помещены на ноду верхнего уровня, что позволяет воздействовать на всех сразу.
Также все свойствам прописаны имена, по которым сразу видно, кто есть кто и на что влияет.
При этом!
Вложенные, в такие ноды, объекты могут иметь дополнительные уникальные свойства. Например текстур.
И они не будут перекрываться свойствами верхнего уровня.
|
Техническая нода, куда были помещены ссылки вообще на все свойства и контроллеры в файле.
Это удобно при отладке сложных файлов со множеством анимаций и свойств.
Хотя указание имен и прописывание занимает некоторое дополнительное время...
|
Собственно если обобщить, то вкратце, будет как-то так!
- Меньше шейпов и нод в nif файле!
- Меньше файлов текстур на nif файл!
- Адекватный подбор разрешения текстур для объекта.
- Правильные подобранные свойства альфы!
- Разумное кол-во полигонов не слишком большого размера!
- Применение оптимизаций коллизий (для статичных объектов и активаторов, ББ у существ)
- Удаление все повторов свойств посредством Combine Properties.
- Загрузка объектов в LOD ноды.
- Где это позволяет геометрия, удаление повторов niTriShapeData, т.е. Instansing.
- Использование текстурных атласов, там где они уместны!
- Дизайн локаций!
- Создайте RAMdisk! и скопируйте туда всю папку с игрой. Если, конечно, игра весит не больше, чем вся доступная ОЗУ....
Результатом подобных действий может стать, большая плавность игры и существенное поднятие фпс!
Скриншоты и некоторые примечания по текстурным атласам, см. во вложенной статье, здесь.
