Оптимизация Live2D проекта
Сталкивались ли вы с такой ситуацией, что модель очень долго экспортируется или вообще не экспортируется с ошибкой в логе? А бывало у вашего витубера так, что на стриме при включении игры модель начинает подлагивать? Может, вы даже не можете закончить работу над проектом из-за того, что ПК не справляется с нагрузкой, хотя раньше всё было в порядке? И при этом докупить ОЗУ, обновить железо сейчас нет возможности, а модель доделать и использовать надо…
Если да, то данный материал для вас. А если вам ранее не приходилось испытывать подобные затруднения, прочитав эту увлекательную и полезную статью вы узнаете о том, на что в своём проекте обратить внимание и как не столкнуться с такими проблемами в дальнейшем.
Сразу скажу, что выполнение данных рекомендаций не может гарантировать избавление ото всех проблем, но может улучшить ситуацию. (Почти) всё описанное далее — моё личное мнение, основанное на многолетней работе с программой. Не везде оно совпадает с мнением других риггеров, но вынести что-то полезное для себя всё равно можно.
Стоит отметить, что может быть сложно перелопатить практически готовый проект и применить все рекомендации, особенно в короткий временной промежуток, поэтому следовать им стоит с начала разработки модели.
Основной раздел,
в котором собраны самые важные технические моменты.
Размер и количество текстурных атласов
Самая частая причина фризов, подгрузок и мучительного экспорта, о которой либо просто не знают, либо которую намеренно игнорируют с мыслями «Да что мне будет!», это неправильная работа с атласами.
Обычно, когда я говорю об этом, мне не верят. И я, к сожалению, никогда не смогу убедить кого-то силой, объяснив механизмы, стоящие за этой проблемой, так как я не разработчик. Моё смутное представление о том, что происходит с программой, примерно такое:
Объём памяти не бесконечен. И если несколько маленьких атласов подгрузить по очереди не так сложно, то один большой переполняет лимит, и программа перестаёт справляться.
Возьмём в качестве живого примера последнее обращение и сравним показатель использования памяти, находящийся в правом нижнем углу программы.
На первом скриншоте был открыт оригинальный файл риггера, на втором открыт файл с переделанными мною атласами.
Файл один и тот же, а вот нагрузка уже разная. И таких примеров множество, но перечислять все нет смысла. Просто подытожу:
Лучше сделать больше текстурных атласов размером не более 4096*4096, чем меньше по количеству, но большего размера. Это влияет на время подгрузки модели в Live2D, на работу в целом и на время экспорта.
При запуске модели в VTube Studio на телефоне большой атлас может вообще крашнуть приложение.
Однако, есть информация, что использование одной текстуры размером 8192*8192 лучше, чем четырёх 4096*4096 из-за того, что на подрузку тоже выделяются ресурсы.
Что ж, это спорный момент, и вам придётся оценить лично, что лучше подходит проекту. Возможно, есть некий баланс между количеством подгрузок и размером атласов. Я всё же склоняюсь к использованию нескольких 4096*4096.
Ограничение памяти
Наверняка вы замечали, что после продолжительной работы Live2D словно начинает подвисать. Сначала немного, потом это становится совершенно невыносимо. Вы перезапускаете проект, и всё становится снова просто и легко до поры до времени.
Давайте с этим тоже разберёмся, хотя это скорее относится к базовым настройкам самой программы, а не к оптимизации проекта.
В определённом файле можно отредактировать параметр, отвечающий за максимальное количество памяти, которым может пользоваться Live2D. По дефолту стоит всего 4000. А нам этого мало. Поэтому:
- Находим папку, где установлен Live2D. Обычно путь до неё выглядит примерно так: C:\Program Files\Live2D Cubism X.X, где X это версия программы.
- Находим там файл CubismEditorX.bat и открываем текстовым редактором.
- В зависимости от того, сколько у вас установлено ОЗУ, указываем вместо set MAX_MEMORY=4000 другое число и сохраняем.
Разработчики рекомендуют при наличии 16 Гб дать программе не более 14.
Если вы укажете слишком большое значение, редактор может не запуститься. В таком случае необходимо вписать 1/3 от имеющегося количества памяти.
Более подробно изучить вопрос можно по этой ссылке.
Warp Deformer divisions
Если вы смело нажали на галочку «Больше не показывать», когда в очередной раз Live2D сообщил о том, что деформеры с сеткой больше 9*9 делений это зло, а потом и вовсе забыли об этом предупреждении, как о страшном сне, то я вам напомню, что в том окошке написано.
«Might impact performance…» — задумчиво смакуете вы заморскую фразу.
«А сделаю-ка я Warp Deformer 20*30!»
После этого в проекте начался сущий кошмар.
Шутки шутками, а после сотни-другой таких деформеров ваш проект действительно будет открываться по несколько часов (реальный случай) и начнёт серьёзно забивать память. Про экспорт в такой ситуации бывает иногда даже говорить не приходится, потому что до него не доходит. И чем меньше у вас ресурсов, тем раньше это произойдёт. Поэтому так важно соблюсти баланс между технической и эстетической сторонами.
Естественно, чем меньше делений, тем меньше свободы. А при существенных искажениях может появиться угловатость. Но давайте не будем впадать в крайности. Я не предлагаю с условных 30 делений сейчас же перейти на указанные в диалоговом окне 9. Моя рекомендация заключается скорее в том, чтобы усложнять сетку деформера только при возникшей потребности. Показалось, что искажается не так, как хочется? Вот тогда плюсуем деление или несколько и смотрим, нравится результат или нет. Не стоит также использовать огромное количество делений на частях, которые не двигаются и/или там, где деталь можно исказить меньшим количеством сегментов. Это нерационально.
Вне деформера = вне закона
Разработчики не рекомендуют позволять деформеру-ребёнку выходить за пределы деформера-родителя. И можно понять, почему: хоть на память этот момент и не влияет, но нагрузка просчитывается по формуле m + 4 + 2*n, где m — точки в пределах деформера, а n — количество вышедших.
Получается, что если у нас 40 вершин, и одна выходит за пределы, то нагрузка вырастает на 13%, а если выходит десять, то уже на 35%.
Так что советую включить автоматическую подсветку вышедших за границы родительского деформера вершин (Highlight Vertices Which Stick Out From the Parent Deformer), которую можно найти в верхнем меню Show.
Выглядит её работа так:
Подсвеченные точки легче увидеть, а значит, и исправить их положение.
Объекты и параметры
Если вы часто видите следующее окошко во время работы, возможно, стоит задуматься: «Всё ли я правильно делаю в своей жизни?»
Разберёмся, что там написано. К сожалению, не лучший перевод с японского на английский, поэтому переведём нормально на русский с учётом реальности.
Одному объекту только что было назначено 4 параметра.
Максимальное количество параметров, которое рекомендуется назначать одному объекту — 3.
Назначение параметров, распределённое равномерно между деформерами согласно иерархии позволяет достичь лучшей производительности, более эффективного редактирования, а также избежать ошибок.
Теперь для тех, кто всё-таки задумался о жизни или кто слабо ориентируется в программе, поясню, что будет, если назначить ключи одному объекту на 3 параметра или более.
Представим, что вы ставите на все нужные параметры по три ключа. Для первого параметра придётся заригать три состояния. Со вторым уже девять. Поставив ключи на третий параметр — двадцать семь. Вместе с четвёртым это восемьдесят одно. Количество работы растёт в геометрической прогрессии.
Вывод: злоупотреблять возможностью ставить ключи на все параметры подряд не стоит. Лучше распределить их более-менее равномерно согласно иерархии.
Extended Interpolation
Рассматривая интересующий нас вопрос оптимизации дополнительной интерполяции, можно найти такие комментарии по этому поводу в документации:
Extended interpolation performs interpolation calculation at the timing when the parameters are manipulated, automatically generates keys on the orbit, and emulates linear interpolation at runtime.
(Interpolation calculations at runtime can affect performance).
Please note that when dealing with extended interpolation in the SDK, there is little effect on performance during execution, but there is a slowdown when loading the model.
Так что дать могу такие рекомендации:
- Учитывайте, что во время работы линковка двух параметров для просмотра рига может значительно нагрузить ПК, так как будет производиться в несколько раз больше вычислений.
- Если нет ощутимой разницы, количество делений стоит уменьшить.
- Следует проверить, не добавили ли вы случайно дополнительную интерполяцию туда, где не хотели её использовать.
Onion skin
Вы спокойно работали и вдруг не можете практически ничего сделать, потому что программа еле реагирует на любые ваши действия? Собака может быть зарыта не в оптимизации самого проекта, а в том, что вы случайно включили Onion skin. В сложном проекте, да ещё с забитой памятью включение этой функции чревато жёсткими подвисаниями. А если вы никогда ранее ею не пользовались и даже не знали о её существовании, сложившаяся ситуация может вогнать вас в ступор.
Поэтому посмотрите на панель ниже рабочей области и проверьте, не нужно ли отжать там эту кнопку:
Дополнительный раздел,
в котором перечислены второстепенные, но не менее важные пункты.
Заполненность текстурного атласа
Давайте вспомним начало основного раздела, и вы зададите себе вопрос: «А зачем мне вообще столько атласов или зачем они мне такие огромные?» Я отвечу за вас: «За исключением случаев, когда сам по себе артмеш реально большой и превышает текущий размер атласа, можно сказать, затем, что все артмеши на один лист не поместились!» Тут мы с вами и остановимся.
Сколько риггеров делают атласы сами, а не пользуются автоматической генерацией? Я не знаю, у меня нет статистики, хотя по ощущениям довольно мало. Но лично я чаще делаю атласы самостоятельно. Это может показаться невероятно скучной и монотонной работой, особенно, если вы только закончили делать риг и желаете поскорее проверить экспортированную версию, а атлас до этого создан не был. Приходится рассматривать расстановку артмешей на атласе как один из существенных этапов работы над проектом. Но почему же стоит уделить время этому занятию?
Функция Automatic layout, как бы её не улучшали разработчики, вряд ли сможет расположить артмеши так же эффективно, как можете сделать это вы сами. И это действительно важно, ведь чем меньше атласов и пустых областей на них, тем лучше.
Рассмотрим разницу на примере:
Лишние артмеши и деформеры не нужны
Почему не стоит плодить сущности?
Во-первых, любой слой сам по себе это нагрузка, информация, которую программам нужно подгружать и использовать. А у каждого слоя, превращённого в артмеш, есть полигоны, состоящие из трёх вершин. В особо неудачных случаях общее количество вершин в проекте из-за лишних слоёв увеличивается многократно. И пусть само по себе количество слоёв и вершин не особенно сильно нагружает ПК (на этом моменте Spine аниматоры схватились за сердце), представьте, как нагрузит это вас лично. Вместо того, чтобы заригать один слой, вам придётся ригать несколько. А ещё они наверняка будут расползаться, что создаст много головной боли. Деформеры же грузят проект сильнее артмешей, о чём было сказано ранее.
Во-вторых, чем больше слоёв и деформеров, тем становится сложнее ориентироваться в проекте, легче потеряться, запутаться и забыть, где что находится. Согласитесь, проще пролистать сотню объектов, чем в несколько раз больше.
В-третьих, каждый лишний слой занимает драгоценное место на атласе.
Попробуем разобраться, откуда растут ноги у всех этих излишеств.
Одним из наиболее вероятных вариантов для слоёв является чрезмерная предусмотрительность художника, по незнанию или же по доброте душевной делящего модель на миллиард слоёв, которые аниматор даже не ожидает увидеть. Далее может быть разное развитие событий: художник/риггер всё-таки объединяет слои так, как нужно, чтобы не было лишних, и все счастливы, или риггер работает с файлом as is (как есть). Минусы очевидны, если вы внимательно прочитали несколько предыдущих абзацев.
Также здесь следует упомянуть, что парные идентичные элементы (глаза, руки, ноги, крылья, рога и пр.), которые можно во время работы над ригом скопировать-вставить, лучше оставить в .psd файле в единственном экземпляре.
Другой причиной может быть то, что риггер по своей воле работает с несколькими артмешами вместо одного, так как недооценивает возможности по искажению сетки. Что тут можно посоветовать? Постарайтесь заранее продумать, что, где и как должно двигаться, объедините части объекта в единое целое, сделайте хорошую сетку и не бойтесь подвигать вершины. В случае неудачи можно без проблем откатиться и начать работать с большим количеством артмешей, а в случае успеха у вас в проекте будет на несколько лишних объектов меньше.
Теперь опишу пару несимпатичных мне практик, связанных с деформерами.
Некоторые риггеры используют деформеры в качестве папок для структуризации проекта. В иерархии такие деформеры у них используются только для хранения артмешей и/или других, более полезных деформеров. По сути это своего рода пустышки, у них нет ключей на параметрах. Возможно, это вопрос вкуса, но я не вижу в них практической ценности.
Следующая заключается в упредительном создании деформеров, которые могут понадобиться для рига, но которые в итоге никогда не используются и не удаляются. Очередные пустышки. Мой вам совет: решайте проблемы по мере поступления, а деформеры создавайте по мере необходимости.
Также разработчики, чтобы облегчить пользователям жизнь, добавили функцию для автоматического выделения всех пустых деформеров в проекте: File — Model Statistics — Select — Select Empty Deformers. Выбрали? Удаляем.
Доработка артмеша
Automatic Mesh generator это прекрасный инструмент, который значительно упрощает жизнь. Однако, во время его использования не избежать появления лишних точек у артмешей. Поэтому старайтесь настраивать генерацию под задачи, упрощать то, что можно упростить, и при необходимости редактировать артмеш после генерации вручную.
Если же вы изначально делаете его своими руками, то следует обратить внимание на скученность и объективную необходимость каждой из вершин, которую вы ставите.
Этот пункт не столь важен конкретно с технической точки зрения, но может серьёзно облегчить работу, а также улучшить качество модели.
Качество отображения текстур
Если ваш проект всё ещё заставляет компьютер усиленно скрипеть шестерёнками, а качество артмешей модели должно остаться как в исходнике, попробуйте воспользоваться опцией Show - Display Quality(Display of Model Image).
Обычно текстуры отображаются в качестве 1/1 (Full Scale), но есть и другие варианты, которые могут на время облегчить процесс и при этом не повлияют на итоговый результат.
После выбора размера не забудьте изменить тип отображения на Model Image. Также желательно перезапустить программу, чтобы изменения вступили в силу.
Порядок
В заключение хочется написать о внутренностях.
Часто случается так, что при разработке модели появляются новые элементы и заменяются старые. Все эти доработки могут превратить проект в громоздкого Франкенштейна, которому будет нелегко поменять составляющие из-за неразберихи. Кроме того, любой такой апдейт меняет вес проекта.
Поэтому следует держать во вкладке Project порядок. Добиться этого можно придерживаясь лишь пары правил.
Первое: пользуйтесь импортом с умом. Если вам нужно заменить слой или несколько, стоит сделать это в .psd и реимпортировать исправленный вариант. Не бойтесь, ваш риг не потеряется и не сломается!
Второе: своевременно и полностью избавляйтесь от неиспользуемых компонентов. Почему я говорю «полностью»? Потому что даже после удаления объекта с рабочей области его всё ещё можно найти и достать из импортированного .psd. Периодически во время работы Live2D, конечно, предлагает убрать лишние файлы, но вы и сами сейчас научитесь это делать не хуже него, если раньше не научились. Ведь, как говорится, на программу надейся, а сам не плошай.
После удаления объекта с рабочей области открываем вкладку Project, раскрываем Model Image, находим папку с удалённым объектом, кликаем по нему ПКМ, выбираем Delete model images, потом при необходимости нажимаем ПКМ по папке (если она осталась пустой) и выбираем Delete group. Теперь раскрываем Source Image, видим ненужный .psd, кликаем ПКМ по нему, и нажимаем в зависимости от задачи Delete Unused Layers, Delete Empty Layer Group и Delete. Если объектов в .psd было несколько и вы удалили часть, тогда удаляем только неиспользуемые слои и пустые группы, а если удалено было всё, то и сам файл можно убрать.
Вот и всё, стало легче дышать.
Поддержать сообщество и порадовать админа можно донатом или подпиской на boosty.