Налаштування frameBuffer - ів для виведення пасів загалом і mia_material_x зокрема, Sigillarium

Відповідь дуже проста – досі ця здавалося б зручна система адекватно працює лише у презентаціях та туторах, але навіть у тестах середньої складності стають видно проблеми. Особисто я дуже часто користуюсь відмінним шейдеромmia_material_x, яким можна зробити переважну більшість необхідних матеріалів. І ось саме його навіть у вигляді спеціального _x_passes варіанта (який, до речі, трохи повільніше) нова система повноцінно не розпасовує. У самого шейдера є всі необхідні аутпути, які можна підключити до кастомних буферів і вивести як окремі паси, але тут і криється найбільша проблема цієї системи - просте додавання кастомного буфера, навіть порожнього, сповільнює рендер... іноді дуже значно (сцена, яка використовується наприклад у цій статті, уповільнюється з 7 хвилин до 57 хвилин).

Власне, у статті йтиметься про більш старий метод виведення пасів, який вирішує як проблему сумісності зmia_material_x, так і проблему швидкості.

Отже, найважливіша перевага, яка дає нам старий ручний метод – можливість виводити в паси все, що ми хочемо без такої сильної шкоди для швидкості рендеру. Платою за це і найбільшим недоліком є моторність сетапа, причому моторність з великої літери ... або може бути навіть так -МУТОРНІСТЬ 🙂

Процес і результат насправді немало залежить від:

Описуваний метод складається з трьох блоків:

шейдинг нетворк : буфер-шейдер з підключеними до нього даними, в даному випадку - аутпутиmia_material_x, набір рампів та інші технічні ноди. Завдання буфер-шейдера - взяти результат кожного з підключених нетворків і направити їх у певні фреймбуфери (за порядковим номером привикористанняctrl_buffers іsimplePasses або на ім'я у разіART_passes );
фреймбуффери : приймають вищезгадані потоки даних з буфер-шейдерів;
аутпути : на рендерКамері визначається які з фреймбуфферів треба з неї відрендерити і куди покласти результат.

Опишу кожен із цих блоків докладніше.

- шейдинг нетворк -

Ось так може виглядати шейдинг нетворк для п'яти різних матеріалів з налаштованим розпасовуванням:

Аутпутиmia_material_x та інших шейдерів треба встромляти в канали буфер-шейдерів в однаковій послідовності для всіх матеріалів, щоб різні дані не валилися в той самий пас. Наприклад, indirect_raw дані тут завжди підключені до п'ятого каналу.

Важливо, щоctrl_buffers іsimplePasses будуть писати свої канали по черзі в наявні фреймбуфери – якщо вимкнути/відконектувати якийсь канал – у підготовлений для нього фреймбуффер просто писатиметься наступний, що в результаті створить розсинхронізацію імен та даних.ART_passes дозволяє писати кожен канал у фреймбуффер з певним ім'ям, що вирішує цю проблему і дуже зручно.

Інтерфейс підключеногоsimplePasses :

ctrl_buffers обмежений 15 каналами (simplePasses/ART_passes таких обмежень не мають):

ART_passes у плані інтерфейсу відрізняється відsimplePasses тільки наявністю ще одного масиву, що містить імена фреймбуфферів для кожного каналу:

Для зручності створення буфер-шейдера та підключення до нього існуючогоmia_material_x можна написати скрипт на кшталт цього (у списку passes визначаємо назви аутпутів, які хочемо виводити, потім виділяємопотрібніmia_material_x і запускаємо скрипт):

- фреймбуффери -

Maya 2008 у renderSettings менталу у розділі Framebuffer>User Framebuffer має велику кнопку Open Editor, яка відкриває атрибути нодиmiDefaultOptions, де можна легко створити необхідну кількість фреймбуфферів. У 2009 цей інтерфейс захований, тому єдиний спосіб сетапа - створити нодуmentalrayUserBuffer і підключити її message до масиву frameBufferList нодиmiDefaultOptions.

Скриптом це зробити досить просто (кожен запуск створює новий фреймбуффер і підключає його до наступного індексу frameBufferList):

ІнтерфейсmentalrayUserBuffer нехитрий:

Можна вибрати бітність паса і робити його інтерполяцію. Якщо писати вOpenEXR формат, ім'я фреймбуффера визначить назву каналу exr (у 2008 це не працює, там будь-коли канали будуть називатися типу fb0, fb1, fb2…)

Є низка назв, які пишуться в дефолтні канали exr. Наприклад, якщо назвати фреймбуфер rgba – дані запишуться в основний RGBA канал файлу. Також можна використовувати depth, uv (які записуються як векторний моушен :)) і ймовірно якісь ще.

- аутпути -

Останній етап - налаштувати рендер камері аутпути, щоб при рендері з неї дані фреймбуфферов записалися в окремі файли (або в різні канали одного exr). Для цього служить інтерфейс на її шейпі mental ray & Output Shaders, що дозволяє створювати та підключати ноди mentalmentrayOutputPass :

Тут два варіанти - брати дані з дефолтного фреймбуффера (різні варіанти бітності beauty, а також depth, label, coverage і т.п. - у цьому випадку ім'я каналу exr буде братися з імені mentallyOutputPass ноди) абокористувача, який ми створили на минулому етапі (треба активуватиUse User Buffer і вибрати потрібний з меню, що випадає). Для запису файл активуємоFile Mode і задаємо формат і постфікс (до імені файлу, визначеного в renderSettings, буде додано знак _ і вказаний постфікс, і сам файл створиться в директорії, так само визначеної в renderSettings). Якщо значення поля постфікса у різних аутпутів одне й те саме, а тип файлів встановленийOpenEXR - створиться один exr-файл з пасами в додаткових каналах. Замість постфіксу можна написати абсолютний шлях, наприклад "C:/Temp/passes.0001.exr", тому що, на жаль, перший варіант погано іменує сіквенси, доводиться перейменовувати файли після рендеру, але можна написати експреш, який при апдейті таймлайну буде вписувати шлях та ім'я з поточним номером кадру, наприклад:

Його має сенс доопрацювати під себе (в останньому проекті у мене експрешень знаходив усі потрібні шляхи з налаштувань проекту, у них створював підпапки з назвою пасів (якщо їх ще не було), робив педінг, гарні імена і все це вводив в аутпути).

Користувальницькі фреймбуфери активуються на запит аутпута з камери, тобто. якщо на рендерКамері є увімкнений (галка renderable встановлена) аутпут, який бере дані з користувальницького фреймбуффера – цей фреймбуффер буде створений, якщо ні – незважаючи на його наявність та підключення доmiDefaultOptions, він буде пропущений. Тобто. якщо використовуєтьсяctrl_buffers абоsimplePasses, і якісь із вже налаштованих аутпутів відключаємо – знову є небезпека розсинхрону імен/даних. (У 2008, якщо фреймбуффер підключений доmiDefaultOptions, він буде створений по-любому, навіть якщо записувати його нікуди не треба - що виключає цю проблему).

– інше-

При verbose мінімум 4 (info messages) у лозі можна переглянути які фреймбуфери створені для поточного рендеру:

ГалкуContrast All Buffers у renderSettings часто має сенс відключити, інакше для кожного фреймбуффера будуть обчислюватися свої значення контрасту для підвищення семплінга, внаслідок чого швидкість рендеру може сильно впасти. При відключенні галки семплінг для всіх пасів буде визначатися основним фреймбуффером (color[0] дляsimplePasses, primarybuffer дляctrl_buffers, color_pass[0] дляART_passes ). Звичайно, паси будуть менш якісні, але зазвичай у тих місцях, де це не дуже потрібно. Якщо beauty містить достатньо деталей у всіх необхідних областях – у них і пасів проблем не буде (якщо в beauty якісь зони тонуть у пітьмі, наприклад, в пасах буде видно мінімальний семплінг).

Шейдери з прорахунком освітлення (типу lambert для пасу dust у тестовій сцені) або трейсом зазвичай виходить швидше відрахувати окремим проходом, тому що може уповільнити рендер розпасовування сильніше, ніж додатковий прорахунок - краще потестіти за фактом. Додаю тестову сцену з сетапом на основі simplepasses - без пасів просто beauty рендері 6m50s, а з 19ю пасами - 7m00s, тобто. уповільнення досить незначне. У ній є цей lambert (у сцені замість нього підключений incidence відsamplerInfo ) - якщо його підключити назад, час зростає приблизно до 13m30s, хоча сам він окремо може бути прорахований всього за 16 секунд.

Ну і як висновок - який же шейдер все-таки використовувати ...

ctrl_buffers як виявилося, має дивну проблему – при виведенні пасів через нього, весь наявний бамп стає нібито сильнішим – не такий як при рендері безпасів. Більше того, час рендеру збільшується в два рази (у нього є певна перевірка, що дозволяє уникнути деякі з хитрих сетапів, про які я згадав на початку, але в даному завдання нам це не потрібно, нам потрібна швидкість ;)). Ну і ще обмеження на 15 каналів… Тому, мабуть, його варто використати тільки якщо два інші проблемлять.
УsimplePasses таких проблем немає - час рендеру майже не змінюється (за вищевказаних умов відсутності додаткових калькуляцій) і пасів можна зробити скільки хочеться, тому, хоча він і менш зручний для сетапа, в цій ситуації набагато вигідніше.
ART_passes трохи повільніше (7m20s проти 7m00s уsimplePasses ), але дозволяє уникнути метушні з порядком каналів і фреймбуфферів (замут з розсинхроном), що дає можливість легко відключати непотрібні паси галочкоюrenderable в аутпутах, тому на мій погляд є найкращим вибором у розпасовуванніmia_material_x.