Блендер тормозит как исправить

Добрый день!

Хотел бы узнать почему тормозит Blender, и как оптимизировать его работу?
Тормозить он начал в тот момент, когда на сцене начало появляться много мелких деталей.
К примеру, когда расставлял пины на сокете CPU он вообще стал виснуть каждую секунду.
Опять же со сложными моделями, функция Ctrl+Z это целое ожидание.

Система:
CPU XEON E5-2620V3 2400
RAM 32Gb DDR4 2666 ECC REG SAMSUNG
VIDEO CARD 750 Ti 2g

Может быть это из-за старого харда?
По динамике, в момент зависания в основном грузить RAM на 19Gb в среднем.
Также, модели из SOLIDWORKS либо 3DS Max в OBJ грузит с трудом, ждать приходится около минуты-2х.
По моему мнению, используемые мной модели не такие уж и высококачественные и высоко-полигональные.
Мониторинг показывает стабильные цифры, ничего в 100 не долбит.

Можете попробовать рендерить окончательно, проверьте что вы в настройках используете движок CUDA и там включены в рендер и процессор и видеокарта. В настройках самой модели поставьте одинаковое кол-во сэмплов во вьюпорте (или меньше) что и при финальном рендере. Также перейдите в диспетчер задач, а именно во вкладку “Подробности”. Нажмите правой кнопкой мыши по процессу блендера, далее “Приоритет” поставьте “Высокий”. Остальные приложения при рендере будут жутко тормозить, но зато Windows будет уделять большую часть мощностей ПК блендеру. Также обновите драйвера видеокарты.

Почему тормозит Blender?

Хотел бы узнать почему тормозит Blender, и как оптимизировать его работу?
Тормозить он начал в тот момент, когда на сцене начало появляться много мелких деталей.
К примеру, когда расставлял пины на сокете CPU он вообще стал виснуть каждую секунду.
Опять же со сложными моделями, функция Ctrl+Z это целое ожидание.

Система:
CPU XEON E5-2620V3 2400
RAM 32Gb DDR4 2666 ECC REG SAMSUNG
VIDEO CARD 750 Ti 2g

Может быть это из-за старого харда?
По динамике, в момент зависания в основном грузить RAM на 19Gb в среднем.
Также, модели из SOLIDWORKS либо 3DS Max в OBJ грузит с трудом, ждать приходится около минуты-2х.
По моему мнению, используемые мной модели не такие уж и высококачественные и высоко-полигональные.
Мониторинг показывает стабильные цифры, ничего в 100 не долбит.

Приветствую!
Какой рендер используется во вьюпорте?

Тормоза будут проявляться от логических модификаторов мешей и эффектов теней/освещения/бликов/etc в настройках рендера. Также стоит проверить, включена ли CUDA.

С Ctrl+Z аналогичная проблема, на текущий момент так и не выяснил в чём причина.

Пробовал все стоковые движки.
Логически подумав, выбрал Workbench, все возможные улучшения картинки не накидывал, дабы просто построить сцену. CUDA не рассматривал, так как видеокарта говно.

Как давно вы занимаетесь дизайном в Blender?

Также у меня появляется вопрос, видел на просторах интернет-помойки, как «боги» blender делают фотореалистичные пикчи с тачками, ландшафтом, и остальным добром. Я же не пытаясь достичь такого, сегодня нагрузил РАМ на 30, просто, расставляя простецкие конденсаторы по материнской плате, на workbench. Не уж то 6 ядер 12 потоков и 32 озу это мало для Medium quality проектов? Уже появляются мысли, взять какой-нибудь DELL на Голдах и 256 озу.

Либо я что-то не отрегулировал, либо все люди, работающие на Blender используют суперкомпьютеры. Если у меня уже тормоза начинаются на стадии расстановки объектов.

Помимо Ctrl+Z, переходы а Edit тоже долго грузятся, впринцепи все, что не Лоу Поли от 20 объектов начинает макать в унитаз мою пекарню.

У меня довольно старая и слабенькая машинка:

Все кэши и рабочие файлы на самых дешёвых SSD по 120G

Занимаюсь в Blender чуть менее года, конечно занимался и задолго до этого ещё под Linux, но это было просто создание лоу-поли драфта с целью позирования для 2D.

Во вьюпорте я использую движок Eevee, он самый шустрый и без шумов при малом кол-ве сэмплов, на «больших» сценах всё жутко тормозит только при оформлении объёмного света и частиц, в режиме моделинга (свет и текстуры отключены) всё гладко, при условии, что все модели сцены уже упрощены (не стоит лепить, имхо, «каждую волосинку» на модели, многие вещи можно избежать альфа-каналами, нормалями и т. п.) и все модификаторы применены. Каждую модель я собираю в отдельных проектах, иначе машина просто не тянет вплоть до отвала драйвера видеокарты из-за проблем с памятью.

Для фотореализма уже на выходе используется движок Cycles (Eevee, на мой взгляд, очень плохо работает со светом). Для моей пеки это прямой портал в ад с суточными ожиданиями результата и это просто один кадр, а если нужна моушен-графика или, скажем, VFX? Тут нужно собирать или рабочую станцию (или же ферму из станций) из связки видеокарт и скорее-всего под Linux, для рендера на GPU, и большого объёма памяти, видеопамяти включительно (для вьюпорта), или же воспользоваться облачным решением. Это будет оправдано в коммерческом использовании, когда важна скорость реализации продукта. В противном случае, можно многое упростить или просто подождать (если для работы с графикой и видео выделена отдельная машина).

Источник

Улучшение производительности Cycles на Windows 10

Здесь, в Pixelary, мы пытаемся выжать каждый бит производительности из нашего оборудования. Одна из вещей, которую мы заметили, заключается в том, что при использовании CUDA рендеринга в Cycles Blender значительно быстрее в Linux, нежели в Windows. Что это дает?

Вышеупомянутый тест рендерился на одном графическом процессоре Titan X (Maxwell) с процессором AMD Ryzen 7. Но это не ограничение графической архитектуры Maxwell. Вот результат для 1080 Ti (поколение Pascal):

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

Мы не согласны с тем, что Windows 10 «просто медленнее». Мы решили найти решение.

Оказывается, при выполнении GPU-рендеринга в Windows 8 или выше, любая команда, используемая Blender, должна пройти через WDDM или модель драйвера дисплея Windows (Windows Display Driver Model). Этот уровень драйвера отвечает за обработку всех устройств отображения, но он часто создает значительные накладные расходы для вычислительных задач. Эта модель является основным компонентом Windows и не может быть просто отключена.

К счастью, у умных людей в Nvidia уже есть решение этой проблемы. Чтобы полностью пропустить WDDM, нам нужно установить GPU как «Tesla Compute Cluster», или TCC для краткости. Как только мы сделали это, графический процессор перестал отображаться как устройство отображения для Windows. Но он по прежнему доступен для всех CUDA приложений. Мы снова провели все тесты Blender, и вот результат:

С поддержкой TCC производительность в Windows точно такая же, как и в Linux!

Теперь плохая новость. TCC доступен только на графических процессорах GeForce Titan и Geforce Quadro, он недоступен для GeForce GTX. И это работает только в том случае, если у вас есть другой графический процессор для отображения (поскольку устройства TCC не могут использоваться для управления дисплеем). Но если вам нужно придерживаться среды Windows и имеется отдельный графический процессор, TCC может быть тем, что вам нужно, чтобы получить дополнительную 30% производительность.

Для рендеринга на устройствах AMD, использующих OpenCL, не существует этого несоответствия производительности.

Итак, теперь мы знаем, ПОЧЕМУ Windows работает медленнее, но мы все же хотели бы видеть способы обойти ограничение WDDM через более эффективные ядра или сокращенные количества вызовов к WDDM. Это гарантирует, что все пользователи Geforce, которые не могут включить TCC, по-прежнему получат выгоду от более быстрого рендеринга.

Источник

Тормозит Blender

Подскажите, пожалуйста в чем может быть проблема. При работе в Blender`е, а именно при масштабирование, перемешение, повороте объекта, блендер начинает подтормаживать очень существенно. Это происходит при одновременно запущенном vlc (т.к. уроки смотрю в этой программе), при выключении vlc, тормоза пропадают. Раньше с такой проблемой сталкивался при одновременном прослушивании музыки, то ли в амарок, то ли в климентине, не помню точно. Решилась проблема использованием альтернативного проигрывателя. Но сейчас не хочу менять видеоплеер, да и думаю что, это не совсем нормально. Скажите, пожалуйста, где и чего копать?

Характеристики бы ПК и его ПО. А то может у тебя нетбук 2008 года с кривущими драйверами и тогда вообще удивительно, что он там что-то перемещает, да еще и видео крутит 🙂

Ноутбук lenovo ideapad y430, внутри:Intel Core 2 Duo T6600 2.2 ГГц,8 Гб, GeForce GT 130M 512Мб,Ubuntu Mate 15.10. Драйвер видеокарты 340.93.
Что-нибудь еще?

Установил второй видеоплеер SMPlayer, тормозов нет).

Полагаю проблема решена 🙂

Позвольте тут отписаться что бы не плодить темы.

При 50к поликов очень заметно тормозит вьюпорт, ФПС очень сильно падает (до 5-10). Все это под Linux, на венде вроде все нормально.

Характеристики:
Проц – Q8400
Видео – Nvidia 9800GT с дровами версии 340.96
ОЗУ – 8Г
Винт SSD
Система – Arch Lunux x64.

Кто что может посоветовать по оптимизации Blender на Linux?

У меня на Kubuntu всё нормально. Дрова точно нормально встали и последние? Вроде, староваты.

А вот как убедиться что дрова нормально встали? NVIDIA X Server Setting вроде вызывается. Вот выхлоп glxinfo | grep OpenGL

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.1
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.1.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Может еще какой выхлоп показать?

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

Может снести все что связано с видео и заново накатить, не знаю.

Дрова из репов обновляются, свежее уже нет, видяха старенькая.

Источник

Вопросы производительности¶

Оптимизация производительности визуализации¶

«Кто над чайником стоит, у того он не кипит» – старая поговорка, но вы можете задаться вопросом, почему визуализация занимает так много времени до своего завершения, или ещё того хуже, падает на половине пути! Ну, во время визуализации происходит много вещей и большинство из них вы можете ускорить, либо включить в сложную визуализацию, чтобы дождаться её завершения. Кроме того, можно отрисовать очень сложную сцену на посредственном ПК, если проявить некоторую смекалку. Вот список вещей из «горячей десятки», которые следует или не следует делать, чтобы ускорить визуализацию или избежать падения во время визуализации. Некоторые параметры могут снизить качество визуализации, но в случае с черновыми визуализациями вы можете не беспокоиться об этом.

Если вы получаете сообщение «Malloc returns nil» («Malloc вернул ноль»), на чистом английском это означает, что аллокатор памяти попытался запросить для Blender больше физической памяти, но вернулся с пустыми руками. Это значит, что у вас не достаточно памяти для визуализации сцены, и Blender не может продолжить работу. Чтобы всё-таки завершить визуализацию, вам нужно будет воспользоваться одним или несколькими советами с этой страницы.

Усовершенствования оборудования¶

• Установите больше системной памяти.
• Обновите ваш центральный процессор до многоядерного/многопроцессорного.
• Обновите свои драйвера OpenGL.
• Поставьте более быструю память, вплоть до предела, который поддерживает ваша материнская плата.
• Используйте или настройте ферму визуализации, используя все имеющиеся компьютеры в вашем доме, либо воспользуйтесь готовой фермой визуализации.

Конфигурация операционной системы¶

• Увеличьте приоритет процесса Blender в вашей ОС.
• Увеличьте область подкачки, используемую ОС для подкачки памяти, также называемой размером файла подкачки виртуальной памяти, вплоть до размера вашей физической памяти.
• Используйте системный монитор для проверки того, что никакие другие процессы не используют значимое количество ресурсов процессора или оперативной памяти и закройте их в случае необходимости.
• Визуализация в фоновом режиме (из командной строки) сохранит немного дополнительной памяти.

Параметры Blender’а¶

• Увеличьте параметр «Ограничение кэша в памяти» в настройках Blender на вкладке «Система» в разделе «OpenGL».
• Переключитесь на ортографическую камеру и визуализируйте «части» сцены в отдельные изображения, а затем соберите их вместе в GIMP. Здесь работает старый трюк с созданием собственной панорамы с реальной камеры, когда вы делаете несколько фотографий очень широкой (закат на пляже) сцены: делаете один снимок, поворачиваетесь направо, делаете другой, потом ещё раз и так далее; и когда вы сделаете все эти фотографии, вы накладываете их друг на друга для получения очень широкого изображения ландшафта. Сделайте то же самое в Blender’е: визуализируйте один снимок в файл, направьте камеру на другую область сцены и сделайте второй снимок. Каждый снимок будет меньшей площади и, таким образом, содержать меньше полигонов/граней. Убедитесь, что, когда вы устанавливаете камеру, вы перекрываете кусочек предыдущего снимка, чтобы потом вы смогли их сопоставить. Если вы не хотите использовать GIMP, вы можете использовать для сопоставления узлы композитора Blender’а, в частности, узел «Перемещение».
• Minimize the render window (and the Blender window, if the UV/Image editor is used). ATI users report dramatic speed-up on a per-frame basis, which adds up over the frame range.
• Используйте скрипт Big Render для визуализации частей общего изображения, а затем объедините их вместе.

Сцена и определённые объекты¶

1. Remove lamps, or move them to unrendered layers, or group them into layers.
2. Отключите тени от каких-нибудь ламп, для отбрасывания теней используйте только одну или две основных лампы-солнца. Несколько дающих тени ламп будут отрисовываться быстрее, чем если бы каждая лампа давала тень.
3. Используйте буферные тени вместо теней от трассировки лучей.
4. Запекайте свои тени при помощи запекания полной визуализации на неподвижные поверхности. Используйте получившуюся текстуру для полисетки и отключите тени для её материала.
5. Упростите полисетки (удалите полигоны). Чем больше вершин находится в камере, тем больше времени требуется на визуализацию.
6. Удалите двойные вершины или используйте функцию редактирования полисетки модификатора «Аппроксимация».
7. Удалите модификаторы «Подразделение поверхности» и «Мультиразрешение».
8. Удалите задние грани полисеток (невидимую геометрию).
9. Визуализируйте за раз только несколько объектов; в начале вашего проекта отрисуйте фоновые объекты и наборы объектов, которые не будут меняться и всегда будут на фоне.
10. Поместите строения на отдельный слой, и скройте их от визуализации через слои визуализации. Затем объедините их с остальным изображением на этапе композитинга.
11. Сделайте камеру статичной, чтобы лучше выполнить две вышеуказанные идеи.
12. Избегайте использования ламп-областей.
13. Отключите затенение для материалов.
14. Запеките AO и текстуры, а затем отключите затенение для соответствующих материалов.
15. Уменьшите расстояние отсечения для ламп-прожекторов.
16. Уменьшите расстояние отсечения для камеры.
17. Отключите AO окружающей среды.
18. Отключите подповерхностное рассеивание материала.
19. Используйте текстуры меньшего размера. Изображение размерами 256×256 занимает всего 1% от памяти, требуемой для 2k-изображения и часто в конечной визуализации вообще не происходит потери качества.
20. Уменьшите количество подразделений в модификаторе «Подразделение поверхности». Каждый уровень подразделения учетверяет (4x) количество граней по сравнению с предыдущим уровнем.
21. Уменьшите мультиразрешение.
22. Сделайте маску с отрисованными фоновыми объектами, например, зданиями, и поместите в сцену плоскость с этим изображением вместо самих объектов. Это позволит уменьшить количество вершин/граней.
23. If you have lots of linked instances of an object, use DupliFaces, as these are instanced. If you have 100 of them, Blender will only store the geometry for one. (Instances themselves take a small amount of memory).

Параметры визуализации¶

Многопроходный композитинг¶

Другой стратегией, которую можно использовать для решения проблемы длительной (повторной) визуализации, является структурирование с нуля вашего рабочего процесса, заключающееся в агрессивном использовании композитинга, который описан в разделе «Пост-обработка». При использовании этого подхода вы разбиваете каждую картинку на компоненты, которые могут быть визуализированы отдельно, а затем объединяете эти отдельно отрисованные элементы в готовый фильм. К примеру:

• If the camera is not moving, then neither is the background: only a single frame is needed. (The same is true of any non-moving object within the frame). These individual elements, having been generated once, can be reused as many times as necessary over as many frames as necessary.
• И тени, и блики могут быть захвачены отдельно от освещаемых или затеняемых объектов, поэтому их интенсивность, цвет и силу эффекта можно скорректировать позже без прибегания к повторной визуализации.
• Начните с использования источников света, не отбрасывающих тень (расчёты теней сильнее всего бьют по производительности). Затем используйте источники света «только с тенями» (которые отбрасывают тень, но не излучают свет) для создания теней только там, где вы думаете, что они действительно необходимы (очень часто бывает так, что лишь немногие из теней, которые могут существовать в сцене, нужны на самом деле, а остальные так и вообще просто незаметны).
• Запутанных ситуаций с освещением можно избежать, обрабатывая каждый объект отдельно от остальных, с последующим объединением фрагментов и «подправкой» результата.

Это очень знакомая идея. Например, в современной звукозаписи всегда используется «мульти-трековый» подход. Отдельные компоненты песни записываются отдельно и изолированно, а затем «сводятся» вместе. «Окончательное сведение» затем проходит через этапы дополнительной обработки, называемой мастеринг, для производства готового продукта (на самом деле, возможности и дизайн современного программного обеспечения для обработки звука прямо аналогичны «узловому» композитору Blender’а).

У такого подхода есть убедительные преимущества:

• If something is «not quite right», you do not necessarily have to start over from scratch.
• In practice, the deadline-killer is re-rendering, which ordinarily must be done (in its entirety) just because «„one little thing“ about the shot is wrong». Compositing helps to avoid this, because (ideally…) only the specific parts that are found to be in error must be repeated (or, maybe, the error can be blocked out with a «garbage matte» and a corrected version can be inserted in its place).
• Sometimes you might find that it is almost what you wanted, but now you would like to add this and maybe take away that. A compositing-based approach enables you to do just that, and furthermore, to do so non-destructively. In other words, having generated the «addition» (or the «mask») as a separate channel of information, you can now fine-tune its influence in the overall «mix», or even change your mind and remove it altogether, all without permanently altering anything.
• By and large, these stages work two-dimensionally, manipulating what is by that time «a raster bitmap with R, G, B, Alpha and Z-depth information», so they are consistently fast.
• Поскольку каждая отдельная задача визуализации была упрощена, компьютер может выполнять их, используя гораздо меньше ресурсов.
• Задачи могут быть распределены среди нескольких разных компьютеров.
• «After all, the scene does not actually have to be physically perfect, to be convincing». A compositing-based approach lets you take full advantage of this. You can focus your attention (and Blender’s) upon those specific aspects of the scene which will actually make a noticeable difference. It is possible to save a considerable amount of time by consciously choosing to exclude less-important aspects which (although «technically correct») probably will not be noticed.

Of course, this approach is not without its own set of trade-offs. You must devise a workable asset management system for keeping track of exactly what material you have, where it is, whether it is up-to-date, and exactly how to re-create it. You must understand and use the «library linking» features of Blender to allow you to refer to objects, nodes, materials, textures and scenes in a carefully-organized collection of other files. You need to have a very clear notion, in advance, of exactly what the finished shot must consist of and what the task breakdown must be. You must be a scrupulous note-taker and record-keeper. But sometimes this is the best way, if not the only way, to accomplish a substantial production.

© Copyright : This page is licensed under a CC-BY-SA 4.0 Int. License.

Источник

Тормозит Blender

Подскажите, пожалуйста в чем может быть проблема. При работе в Blender`е, а именно при масштабирование, перемешение, повороте объекта, блендер начинает подтормаживать очень существенно. Это происходит при одновременно запущенном vlc (т.к. уроки смотрю в этой программе), при выключении vlc, тормоза пропадают. Раньше с такой проблемой сталкивался при одновременном прослушивании музыки, то ли в амарок, то ли в климентине, не помню точно. Решилась проблема использованием альтернативного проигрывателя. Но сейчас не хочу менять видеоплеер, да и думаю что, это не совсем нормально. Скажите, пожалуйста, где и чего копать?

Характеристики бы ПК и его ПО. А то может у тебя нетбук 2008 года с кривущими драйверами и тогда вообще удивительно, что он там что-то перемещает, да еще и видео крутит 🙂

Ноутбук lenovo ideapad y430, внутри:Intel Core 2 Duo T6600 2.2 ГГц,8 Гб, GeForce GT 130M 512Мб,Ubuntu Mate 15.10. Драйвер видеокарты 340.93.
Что-нибудь еще?

Установил второй видеоплеер SMPlayer, тормозов нет).

Полагаю проблема решена 🙂

Позвольте тут отписаться что бы не плодить темы.

При 50к поликов очень заметно тормозит вьюпорт, ФПС очень сильно падает (до 5-10). Все это под Linux, на венде вроде все нормально.

Характеристики:
Проц — Q8400
Видео — Nvidia 9800GT с дровами версии 340.96
ОЗУ — 8Г
Винт SSD
Система — Arch Lunux x64.

Кто что может посоветовать по оптимизации Blender на Linux?

У меня на Kubuntu всё нормально. Дрова точно нормально встали и последние? Вроде, староваты.

А вот как убедиться что дрова нормально встали? NVIDIA X Server Setting вроде вызывается. Вот выхлоп glxinfo | grep OpenGL

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.1
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.1.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Может еще какой выхлоп показать?

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

Может снести все что связано с видео и заново накатить, не знаю.

Дрова из репов обновляются, свежее уже нет, видяха старенькая.

Источник

Почему тормозит Blender?

Хотел бы узнать почему тормозит Blender, и как оптимизировать его работу?
Тормозить он начал в тот момент, когда на сцене начало появляться много мелких деталей.
К примеру, когда расставлял пины на сокете CPU он вообще стал виснуть каждую секунду.
Опять же со сложными моделями, функция Ctrl+Z это целое ожидание.

Система:
CPU XEON E5-2620V3 2400
RAM 32Gb DDR4 2666 ECC REG SAMSUNG
VIDEO CARD 750 Ti 2g

Может быть это из-за старого харда?
По динамике, в момент зависания в основном грузить RAM на 19Gb в среднем.
Также, модели из SOLIDWORKS либо 3DS Max в OBJ грузит с трудом, ждать приходится около минуты-2х.
По моему мнению, используемые мной модели не такие уж и высококачественные и высоко-полигональные.
Мониторинг показывает стабильные цифры, ничего в 100 не долбит.

• Вопрос задан более года назад
• 4233 просмотра

Приветствую!
Какой рендер используется во вьюпорте?

Тормоза будут проявляться от логических модификаторов мешей и эффектов теней/освещения/бликов/etc в настройках рендера. Также стоит проверить, включена ли CUDA.

С Ctrl+Z аналогичная проблема, на текущий момент так и не выяснил в чём причина.

Пробовал все стоковые движки.
Логически подумав, выбрал Workbench, все возможные улучшения картинки не накидывал, дабы просто построить сцену. CUDA не рассматривал, так как видеокарта говно.

Как давно вы занимаетесь дизайном в Blender?

Также у меня появляется вопрос, видел на просторах интернет-помойки, как «боги» blender делают фотореалистичные пикчи с тачками, ландшафтом, и остальным добром. Я же не пытаясь достичь такого, сегодня нагрузил РАМ на 30, просто, расставляя простецкие конденсаторы по материнской плате, на workbench. Не уж то 6 ядер 12 потоков и 32 озу это мало для Medium quality проектов? Уже появляются мысли, взять какой-нибудь DELL на Голдах и 256 озу.

Либо я что-то не отрегулировал, либо все люди, работающие на Blender используют суперкомпьютеры. Если у меня уже тормоза начинаются на стадии расстановки объектов.

Помимо Ctrl+Z, переходы а Edit тоже долго грузятся, впринцепи все, что не Лоу Поли от 20 объектов начинает макать в унитаз мою пекарню.

У меня довольно старая и слабенькая машинка:

Все кэши и рабочие файлы на самых дешёвых SSD по 120G

Занимаюсь в Blender чуть менее года, конечно занимался и задолго до этого ещё под Linux, но это было просто создание лоу-поли драфта с целью позирования для 2D.

Во вьюпорте я использую движок Eevee, он самый шустрый и без шумов при малом кол-ве сэмплов, на «больших» сценах всё жутко тормозит только при оформлении объёмного света и частиц, в режиме моделинга (свет и текстуры отключены) всё гладко, при условии, что все модели сцены уже упрощены (не стоит лепить, имхо, «каждую волосинку» на модели, многие вещи можно избежать альфа-каналами, нормалями и т. п.) и все модификаторы применены. Каждую модель я собираю в отдельных проектах, иначе машина просто не тянет вплоть до отвала драйвера видеокарты из-за проблем с памятью.

Для фотореализма уже на выходе используется движок Cycles (Eevee, на мой взгляд, очень плохо работает со светом). Для моей пеки это прямой портал в ад с суточными ожиданиями результата и это просто один кадр, а если нужна моушен-графика или, скажем, VFX? Тут нужно собирать или рабочую станцию (или же ферму из станций) из связки видеокарт и скорее-всего под Linux, для рендера на GPU, и большого объёма памяти, видеопамяти включительно (для вьюпорта), или же воспользоваться облачным решением. Это будет оправдано в коммерческом использовании, когда важна скорость реализации продукта. В противном случае, можно многое упростить или просто подождать (если для работы с графикой и видео выделена отдельная машина).

Источник