Blender тормозит: разбираем причины от вьюпорта до драйверов

Blender начинает тормозить постепенно: сначала чуть задумывается при вращении, потом подвисает на секунду при каждом клике, а к концу проекта работать становится невозможно. При этом железо то же самое, что и месяц назад.

Дальше по порядку, что именно тормозит, как отличить нагрузку на процессор от нагрузки на видеокарту, и что чинится настройками, а что только пересборкой сцены.

Сначала определить, что тормозит

Тормоза бывают разные, и лечатся они противоположными способами.

Вьюпорт дёргается при вращении сцены. Нагрузка на видеокарту или слишком много объектов для отрисовки.

Задержка после каждого действия. Пересчёт зависимостей на процессоре: модификаторы, ограничения, драйверы.

Подвисание при выделении объекта. Обычно огромное число элементов сетки в режиме редактирования.

Долгое открытие и сохранение файла. Упор в накопитель или в размер сцены.

Всё медленно, включая интерфейс. Нехватка оперативной памяти, система уходит в подкачку.

Открытый монитор нагрузки отвечает на вопрос за минуту: смотрите, что загружено во время тормозов.

Причина первая: модификаторы

Самая частая причина задержек при работе.

Модификаторы пересчитываются на каждое изменение сцены, и делает это процессор в один поток. Подразделение на тяжёлой модели или булева операция с миллионом полигонов подвешивают Blender при каждом движении.

Что делать. Отключить отображение тяжёлых модификаторов во вьюпорте, оставив их только для рендера: это отдельные переключатели в стеке. Снизить уровень подразделения для вьюпорта. Применить модификаторы, которые уже не будут меняться.

Отдельно про булевы операции: они пересчитываются при каждом изменении любого из операндов. На сложных моделях их применяют сразу, а не держат живыми.

Причина вторая: слишком много объектов

Тысяча отдельных объектов тормозит сильнее, чем один объект с тем же числом полигонов.

Причина в накладных расходах: каждый объект это отдельная запись в списке зависимостей и отдельный вызов отрисовки.

Что делать. Объединить то, что не нужно править по отдельности. Использовать связанные копии вместо независимых: они делят геометрию и считаются быстрее. Для массовых объектов использовать системы распределения вместо ручного размножения.

Практический признак этой причины: сцена тормозит, хотя суммарное число полигонов небольшое.

Причина третья: тяжёлые текстуры

Текстуры высокого разрешения занимают видеопамять, и когда она заканчивается, вьюпорт начинает подтормаживать постоянно.

Что делать. Проверить потребление видеопамяти. Снизить разрешение текстур для работы, вернув полное перед финальным рендером. Проверить, нет ли в сцене неиспользуемых изображений: они всё равно загружаются.

Отдельная деталь: текстуры в формате без сжатия занимают в разы больше. Для рабочих версий сцены это заметно, и подробнее о том, куда уходит память, есть в материале про требования к видеопамяти.

Причина четвёртая: режим отображения

Простая настройка, которая часто и есть причина.

Режим просмотра материалов и тем более предпросмотр рендера нагружают карту постоянно. Для моделирования они не нужны.

Работайте в режиме сплошной заливки и переключайтесь на материалы только когда нужно их оценить.

Дополнительно помогает отключение ненужных наложений: сетка, оси, контуры выделения на больших сценах тоже стоят кадров.

Причина пятая: физика и симуляции

Живая симуляция в сцене пересчитывается при каждом изменении кадра.

Если в сцене есть ткань, дым или частицы, и вы просто листаете таймлайн, каждый кадр запускает расчёт.

Что делать: запечь симуляцию в кэш. После запекания кадры читаются из кэша вместо пересчёта, и работа снова становится отзывчивой.

Для тяжёлых симуляций имеет смысл выносить их в отдельный файл и подключать результат в основную сцену как готовые данные.

Причина шестая: режим редактирования на плотной сетке

Объект в миллионы полигонов тормозит в режиме правки, даже если в объектном режиме всё нормально.

Причина: в режиме редактирования Blender держит структуру для работы с отдельными вершинами, и она тяжелее обычной.

Что делать. Скрывать части сетки, с которыми не работаете. Использовать скульптинг вместо полигонального редактирования там, где это уместно. Разбивать модель на части.

Причина седьмая: драйверы и настройки системы

Реже, но случается, и диагностируется по характерному признаку: тормозит всё одинаково, независимо от сцены.

Что проверить. Версия драйвера видеокарты: слишком старая или, наоборот, только что вышедшая. Режим энергосбережения: на ноутбуках он может ограничивать частоты. Выбор видеокарты в настройках Blender: на системах с двумя картами он иногда указывает на встроенную.

Последний пункт встречается чаще, чем кажется, и даёт драматическое падение производительности при исправном железе.

Причина восьмая: аддоны

Каждый включённый аддон добавляет обработчики событий, и часть из них выполняется постоянно.

Проверяется просто: запустить Blender с отключёнными аддонами и сравнить отзывчивость.

Практическое правило: держать включёнными только те, которыми пользуетесь. Аддон, установленный полгода назад для одной задачи, продолжает работать всё это время.

Причина девятая: автосохранение

Незаметная причина регулярных подвисаний.

Автосохранение тяжёлого файла на медленный накопитель подвешивает программу на несколько секунд, и происходит это по расписанию.

Что делать: увеличить интервал автосохранения на тяжёлых проектах либо убедиться, что временная папка находится на быстром накопителе.

Как проверить, в чём дело, за пять минут

Что делать с уже тяжёлой сценой

Если сцена разрослась и работать в ней невозможно, есть несколько путей.

Разделить на файлы. Окружение отдельно, персонажи отдельно, эффекты отдельно. Собирать вместе только для рендера через связывание.

Работать с упрощёнными версиями. Прокси-объекты вместо тяжёлых моделей, полная детализация подключается перед финальным просчётом.

Использовать коллекции. Скрывать целые группы объектов, с которыми сейчас не работаете. Скрытое не отрисовывается и не пересчитывается.

Все три приёма работают лучше, чем попытки ускорить сцену настройками, когда она уже стала слишком тяжёлой.

Настройки, которые стоит поменять один раз

Несколько параметров в настройках программы влияют на отзывчивость постоянно, и выставляются они один раз.

Выбор вычислительного устройства. Убедиться, что выбрана дискретная карта и правильный механизм ускорения. Ошибка здесь даёт кратное падение скорости при исправном железе.

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

Качество предпросмотра подразделения. Ограничение уровня для вьюпорта отдельно от рендера.

Количество отменяемых шагов. История действий хранится в памяти, и на тяжёлых сценах большая глубина отмены съедает гигабайты.

Интервал автосохранения. Увеличить для тяжёлых проектов, чтобы подвисания случались реже.

Профилактика

Привычки, которые не дают сцене превратиться в неподъёмную.

Применять модификаторы, когда они перестают быть нужными как живые.

Чистить неиспользуемые данные: изображения, материалы, объекты остаются в файле, даже когда не используются.

Держать разрешение текстур рабочим, а не максимальным.

Запекать симуляции сразу после настройки.

Разделять сцену на файлы до того, как она станет тяжёлой, а не после.

Когда дело всё-таки в железе

Признаки, что настройками уже не помочь.

Тормозит даже пустая сцена: проблема в системе или драйверах.

Постоянно занята вся видеопамять при умеренной сцене: карта слишком слабая для ваших задач.

Система уходит в подкачку при открытии проекта: не хватает оперативной памяти.

Отзывчивость падает при любом действии, а загружено одно ядро процессора: упор в однопоточную производительность, и здесь помогает только более быстрый процессор, о чём подробнее в материале про процессор для Blender.

Частые вопросы