2д там тоже естт, от руки текстуру рисовала

ой, все что было до отдаления огонь, а потом текстуры не оч, дед не оч и такое себе, видно, что сделано так, что бы было (

Да капец, не успеваю ничего, а еще надо так много всего делать

Делой

Где скульпты по концептам Лисы?

Сейчас надо к конкурсу успеть

Отмазался 😏

Да да
Так все старики говорят

1 лайк и я запощу очередное полотно в основной канал

👍

Я тебя услышал

Дин, а где ты работаешь?

Я хочу выиграть

Сегодняшняя рубрика #dev_news будет про композитинг.

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

В первом варианте древо нод выполняется для каждого тайла заново, пускай и в многопоточности. Более того: если результат операции («output» ноды) считывают несколько нод, расчеты пикселя ведутся столько раз, сколько этих нод. При этом в буфере хранится все древо нод до самого конца, что для сложных/длинных нод дает большое пиковое потребление памяти.
Во втором — вначале записывается результат одной операции в буфер, прежде чем начать выполнять следующую. Закончил все записи и чтение результатов операции? Очистил буфер. В таком случае на память влияет не длина нод, а количество ответвлений.

Чтобы добиться этого, вначале композитор проходится по древу вхолостую, во время чего он подсчитывает, сколько раз результат каждой операции считывается. Позже это используется уже в «рабочем» режиме. Сделал операцию, записал в буфер чтобы не пересчитывать. Результат ноды использовался 5 раз, и в холостом проходе тоже 5 раз? Всё, можно избавляться от буфера.


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

Когда?
Работа над всем этим активно ведется уже порядка полугода, т.к. помимо всего прочего необходимо каждую ноду переделать под полнокадровый подход. По большому счету осталось конвертировать только одну ноду, но там работы чуть больше, чем с другими. Разработчики сейчас собирают фидбек об этих изменениях, чтобы при необходимости внести изменения, пока железо горячо.

Сейчас в альфа версии 3.0 под галкой экспериментальной функции этим уже можно воспользоваться. Будет ли это не в экспериментальном режиме в декабре при релизе 3.0? Навряд ли. Но 3.1 — уже шанс приличный.

Есть ли ощутимые результаты уже сейчас?
По словам очевидцев, есть. Композитор в среднем выдает результат на 20-30% быстрее. Потребление памяти должно быть тоже значительно ниже, однако конкретных цифр я не помню.
Дополнительные оптимизации возможны, но пока упор ведется на то, чтобы все работало корректно.

Что дальше?
После полнокадрового режима конкретных планов нет. Есть идеи еще с прошлого года, когда это только начиналось обсуждаться и были некоторые наработки на коленках, но в каком порядке, виде и будет ли вообще еще не решено. Но для любопытных вот парочка самых интересных:

— Кеширование результатов нод с помощью специальной ноды. Сейчас такое возможно только с аддоном, но с полнокадровой системой это можно реализовать и в самом Блендере.

— Поддержка ГПУ для (не всех) нод. Нормальная, а не как сейчас. Результат может быть лучше в несколько раз как в плане скорости, так и в плане памяти (т.к. используется память видеокарты помимо оперативной). Но поддержка кода — проблема.

Для самых отважных, готовых осилить еще бОльшую стену текста, да еще и на английском, можете ознакомиться с изначальным предложением разработчика, который этим занимается:
https://developer.blender.org/T81650

На удаленке

на студию?

👀 Читать то сколько

Ага

а название есть?)))