Согласна, это не единственно правильный путь. Это один из множества возможных сценариев использования GPU-сервера - наряду с локальными фермами, Flamenco и распределённым CPU-рендером.
Согласна: если сцене хватает 8 ГБ видеопамяти, брать GPU на 24 ГБ нет смысла - это был пример доступной конфигурации, а не рекомендация "брать всегда такую". В облаке конфигурация подбирается под конкретную задачу и время рендера.
"16 ГБ CPU" - моя ошибка в формулировке, имелось в виду 16 vCPU.
Смысл примера в статье - показать модель использования облака (включил - отрендерил - выключил), а не оптимальный объём видеопамяти для конкретной сцены
Я не достигала уровня профессионального моделлера, но у меня есть практический опыт работы с тяжёлыми сценами, пусть и с типичными ошибками новичка. Я моделировала на старом ноутбуке ASUS сцены с завышенной полигональностью (несколько уровней TurboSmooth, дело было в 3ds Max), большим количеством объектов в сцене, текстурами высокого разрешения, светом. И при всём этом во вьюпорте у меня не возникало критичных задержек - навигация оставалась комфортной даже в относительно тяжёлых и плохо оптимизированных сценах. А вот на рендере начинался "самый сок": сутки рендера и выше :)
Я не утверждаю, что так должны работать новички или что это лучшая практика. Я привожу этот опыт как факт: даже тяжёлые сцены могут быть терпимы в моделинге и навигации, тогда как рендер - это другой уровень требований к ресурсам.
По поводу предложения отключить видеокарту: не очень понимаю, зачем мне это делать для навигации в Blender. В моих условиях задержек в навигации нет.
Сцена, о которой идёт речь, на самом деле не такая уж большая, и мой компьютер её тянет - несмотря на то, что сборке уже около 7 лет. Кстати, изначально я хотела использовать для статьи сцену с анимацией Sprite Fright Showreel - она была бы более показательной для сравнения. Но моя видеокарта на компьютере просто не смогла её обработать. А сама часть сцены в навигации не составила задержек.
Так что мой тезис был не "ресурсы не нужны вообще", а про разницу требований между процессом моделирования и быстрым финальным рендером - особенно в контексте статьи.
Это инструмент, если уже есть своя инфраструктура. В статье же речь о другом уровне: когда инфраструктуры нет или она нерегулярно используется, то дешевле ее арендовать на какое-то время и заплатить только за то время, когда она будет использоваться для высоконагруженных задач как рендер. Для самого процесса моделирования много ресурсов не надо, таких как на быстрый рендер.
Можно. Если есть постоянная загрузка и бюджет. Но в большинстве рендер это эпизодический сценарий. В статье я как раз про сценарий, где нагрузка нерегулярная. В таких случаях облако обойдется дешевле, его можно арендовать по часам, а не постоянно.
Согласна, это не единственно правильный путь. Это один из множества возможных сценариев использования GPU-сервера - наряду с локальными фермами, Flamenco и распределённым CPU-рендером.
Согласна: если сцене хватает 8 ГБ видеопамяти, брать GPU на 24 ГБ нет смысла - это был пример доступной конфигурации, а не рекомендация "брать всегда такую". В облаке конфигурация подбирается под конкретную задачу и время рендера.
"16 ГБ CPU" - моя ошибка в формулировке, имелось в виду 16 vCPU.
Смысл примера в статье - показать модель использования облака (включил - отрендерил - выключил), а не оптимальный объём видеопамяти для конкретной сцены
Я не достигала уровня профессионального моделлера, но у меня есть практический опыт работы с тяжёлыми сценами, пусть и с типичными ошибками новичка. Я моделировала на старом ноутбуке ASUS сцены с завышенной полигональностью (несколько уровней TurboSmooth, дело было в 3ds Max), большим количеством объектов в сцене, текстурами высокого разрешения, светом. И при всём этом во вьюпорте у меня не возникало критичных задержек - навигация оставалась комфортной даже в относительно тяжёлых и плохо оптимизированных сценах. А вот на рендере начинался "самый сок": сутки рендера и выше :)
Я не утверждаю, что так должны работать новички или что это лучшая практика. Я привожу этот опыт как факт: даже тяжёлые сцены могут быть терпимы в моделинге и навигации, тогда как рендер - это другой уровень требований к ресурсам.
По поводу предложения отключить видеокарту: не очень понимаю, зачем мне это делать для навигации в Blender. В моих условиях задержек в навигации нет.
Сцена, о которой идёт речь, на самом деле не такая уж большая, и мой компьютер её тянет - несмотря на то, что сборке уже около 7 лет. Кстати, изначально я хотела использовать для статьи сцену с анимацией Sprite Fright Showreel - она была бы более показательной для сравнения. Но моя видеокарта на компьютере просто не смогла её обработать. А сама часть сцены в навигации не составила задержек.
Так что мой тезис был не "ресурсы не нужны вообще", а про разницу требований между процессом моделирования и быстрым финальным рендером - особенно в контексте статьи.
В конфигурации NVIDIA A5000 24 Гб, 16 Гб CPU, 64 Гб RAM, 256 Гб NVMe - 57,02 руб/час
Это инструмент, если уже есть своя инфраструктура. В статье же речь о другом уровне: когда инфраструктуры нет или она нерегулярно используется, то дешевле ее арендовать на какое-то время и заплатить только за то время, когда она будет использоваться для высоконагруженных задач как рендер. Для самого процесса моделирования много ресурсов не надо, таких как на быстрый рендер.
Можно. Если есть постоянная загрузка и бюджет. Но в большинстве рендер это эпизодический сценарий. В статье я как раз про сценарий, где нагрузка нерегулярная. В таких случаях облако обойдется дешевле, его можно арендовать по часам, а не постоянно.