В чём рендерить

не используя заоблачное железо и платный софт. Скорее всего стоит посмотреть в сторону Blender, Godot либо webgl-решений.

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

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

Запускал и записывал это всё на таком вот железе: ноутбук HP, процессор AMD A10 (4 ядра по 2Ghz), память 4Gb, Radeon HD8670m (dual graphics), Windows 8.1

Далее отдельно по каждому инструменту:

У Блендера всё было хорошо ещё лет 15+ назад. Другое дело, что многие узнали о нём относительно недавно - год, два тому назад. Но разговор сейчас не о том насколько Блендер популярен, а за то, что по сути можно использовать любую его версию, не только последние (таким образом можно подобрать версию Blender даже для довольно старого железа).

Одной из эталонных версий является 2.79b, последняя со старым интерфейсом, до последующего перехода на якобы модно-молодёжный интерфейс в 2.80. Оба варианта интерфейсов имеют как свои плюсы так и минусы, но в целом 2.79 производительнее и менее требователен к железу, поэтому я продолжаю его использовать несмотря на новые версии. В нём правда нет рендера eevee, но это даже не минус, потому как к eevee всё-равно нужен отдельный подход и настолько же "честно" просчитать картинку как cycles, она не способна. Cycles, в свою очередь, всю эту свою красоту вычисляет очень долго, поэтому когда речь идёт об отдельной картинке, то он вне конкуренции. А вот для анимации, особенно продолжительных, уже целесообразнее использование eevee, тем более что для движущейся картинки не так важна высокая степень детализации каждого кадра.

Cycles

Ролик начинается как раз с рендера в Blender 2.79 с использованием cycles. Размер картинки 1280 на 720, но с качеством 80%. 128 или 256 неоптимизированных сэмплов, без шумоподавления. В целом это меньшее качество, чем одиночный кадр для превьюшки этой статьи, который снят в 1980 на 1024 и большим сэмплингом.

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

Всего кадров было 120. Вычисление всех заняло на моём девайсе где-то около 8-9 часов. Собственно, можно было выставить более оптимальные параметры и получить результат не сильно хуже. Например, снимать в 834 на 480, 64 сэмпла, и не 120 кадров а 60.

Eevee

Следующий вариант я рендерил в Блендере 2.90. Это была последняя стабильно запускающаяся у меня версия, потому как 2.91, например, не работала когда скачал её первый раз, а потом я и не пробовал снова. С тем же успехом можно было взять 2.83, по картинке вышло бы примерно то же самое, но, вероятно, чуть помедленнее.

На этот раз было уже 1280 на 720 с качеством 100% и 256 сэмплов (хотя сэмплирование в eevee - это далеко не то же самое, что в cycles). 120 кадров отрисовались примерно минут за 20. Ну и шум не образуется при таком методе рендера.

Визуализация рабочей области

В конце видео добавил вид на сценку внутри свежескачанного Blender 2.92, который в отличие от версии 2.91 запустился у меня сразу без проблем.

Как видно - 3д пакет уже в окне предварительной визуализации способен выдавать неплохую картинку, хотя она более упрощена. Теоретически можно поотключать интерфейс и захватывать картинку прямо отсюда, если вам зачем-то это нужно. Cycles такое не вытянет, медленно перерисовывает кадр, но в eevee возможно - кадр обновляется довольно быстро. Просто обычно этого не требуется, потому как лучше отрендерить нормальным образом или задать настройки самого рендера пониже, как для окна предпросмотра.

Из забавного. На картинке выше представлен один кадр, отрисованный в Blender 2.92 с использованием cycles. Сами шейдеры при этом взяты такие же, как были настроены для сцены в eevee. Кадр рисовался 10 минут, таким образом на все 120 ушло бы 20 часов. То есть cycles в 2.79 справился раза в два быстрее при чуть более низком выставленном проценте качества.

Дело оказалось в настройке Use open shading language, при включённой опции рендер кадра длился на 4 минуты дольше. При её отключении и выставлении 80 процентного качества среднее время рендера показало уже 5 минут, что уже больше похоже на время затраченное cycles в старой версии. В целом это я к тому, что между старым и новым cycles разница может быть не такой существенной.

Перейдём к игровым движкам. В целом их способы рендера похожи на eevee. Godot - наиболее доступный из нетребовательных движков, опенсурс, не требует регистраций и совсем мало весит. К тому же в нём есть не только продвинутые pbr-шейдеры, но и прочие полезные опции для 3д - экранные отражения и тени, глубина резкости, эффекты свечения, тонировка и автоэкспозиция, запекание света и так далее. То есть собрать визуал уровня eevee - не так уж сложно.

Правда большая часть этого великолепия будет работать только при выборе более требовательного рендера GLES 3, его и следует использовать для графики, если это возможно. GLES 2, тем не менее, может пригодится как более шустрый и простой вариант для визуализации анимаций, если GLES3 не поддерживается или работает слишком медленно.

Другая полезная вещь в Godot - встроенный аниматор, оперировать которым даже проще чем в Blender (зато в последнем больше разнообразного контроля и дополнительных возможностей). Да, он не заменит кости, но и без этого очень мощный и простой инструмент, которого часто так не хватает продвинутым движкам.

В отличие от Blender'а в игровом движке картинка рисуется в реальном времени, к тому же придётся чем-то её дополнительно захватывать (OBS, например; я для захвата видео из Godot в данном случае использовал ShareX). Опять же, обычно нельзя создавать какие-то детализированные модели прямо внутри движка, хотя в случае Godot помимо обычных примитивов, можно использовать специальные примитивы с поддержкой булевых операций, что несколько расширяет возможности.

Как и в случае с Blender у Godot есть более старые версии, хотя разница между требованиями не такая большая, если говорить о 3д. По крайней мере на текущий момент актуальна по сути любая из 3-их версий, хотя те что поновее имеют больше правок в мелочах. Более того, они останутся в некотором роде актуальными и после выхода 4-й версии, использующей другой рендер. Я сейчас пользуюсь версией 3.2.3, есть более новая 3.2.4.

Кстати, если уж говорить конкретно о визуализации, то на сборках Godot 4 делать рендеры можно было уже где-то с лета 2020-го. И хотя сами эти сборки ограниченной функциональности, но для того чтобы просто отрисовать и получить более красивую картинку, чем gles3 этого уже было достаточно.

WebGL

Ещё один вариант - решения, использующие webgl рендер. Все их плюсы и минусы в основном сводятся к тому, что они работают в браузере. Сюда можно отнести такие вещи как PlayCanvas, Three.js, Babylon.js, CocosCreator3d (хотя он более многостаночный, чем только webgl) и тому подобное.

Я пользуюсь PlayCanvas'ом, и по сравнению с GLES3 рендером в Godot местный webGL 2.0 выдаёт картинку примерно сравнимого уровня. Но в целом, конечно, графических опций здесь поменьше, хотя что-то из постэффектов можно подключить скриптами.

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

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

Отдельные отрендеренные кадры я склеивал опять же в Blender (в 2.79), используя его внутренний инструмент редактирования роликов и последовательностей изображений. Здесь как раз и требовалось сшить вместе не только отдельные кадры, но и ролики записанные вне Blender'а. Получилась одна большая последовательность из 5627 кадров, которая тоже какое-то незначительное время рендерилась.

Правда без дополнительных программ всё-таки не обошлось, потому как итоговый файл весил около 850 Мб и заливать такое на ютуб относительно долго. Поэтому дополнительно прогнал видео через ShotCut, пережав в 44 Мб без особых потерь в картинке. Собственно, если бы я не забросил на общий таймлайн цельные ролики, а использовал бы вместо них такие же последовательности картинок, то ещё на выходе из Блендера вес уже был бы более оптимальный.

#blender #godot #3d #рендер #webgl #playcanvas #графика