#asfw #materialx #openpbr

MaterialX Virtual Town Hall 2024

Про новый стандарт OpenPBR Surface и релиз MateriaX 1.39 с тайм-кодами.

Если коротко то референсная имплементация есть уже в MaterialX 1.39, в Adobe Substance тюнится, Arnold (3ds Max, Maya, Katana), Omniverse уже есть, в Houdini будет в следующем релизе.

- Intro

New Features:
- Energy-preserving Oren-Nayar
- New fuzz model
- Coat darkening
- Dispersion scale
- More expenssive layer ordering
- Art-directable metal model
- Other user-friendly tweaks

- Future Work

MaterialX Updated:
- Pixar (OpenUSD & Hydra)
- Omniverse
- LookdevX in Maya
- V-Ray
- Houdini

Вообще на их канале вышло много свежего видео про разные опенсорсные разработки (видеоплееры, рендер-менеджер, форматы изображений).

Это. Просто. Интересно.

#houdini #meme

Здесь нечего пояснять 🤡

#houdini #todayilearned #hnoscript #path

Пишем рендер на один уровень выше относительно HIP файла. А если бы надо было на два уровня выше? 👀

#houdin #event #sidefx

Adventures in MPM-land: the Fine Art of Balancing Numbers
Mastering the Elements: The New MPM Solver

Возможно наконец-то что-то в этих докладах расскажут про MPM солвер и приоткроют завесу "как правильно его готовить? и что там с дестаркшеном, пацаны? как деформить RBD?"

Так же интересно будет глянуть доклад From Bodies to Branches, Unconventional Instancing on FX's Shōgun от непревзойдённых мастеров качественного графона - ILP. Брэйкдаун по этому проекту был крутой.

А так же этот доклад Solving Plants in Houdini, описание звучит достаточно интересно.

Используя OpenCL для ускорения GPU, наша система построена на архитектуре APEX в Houdini, которая поддерживает частичную и отложенную оценку, обеспечивая быструю интерактивную обратную связь. Это позволяет художникам создавать сложную, натуралистичную растительность с беспрецедентным контролем и скоростью.

https://www.sidefx.com/houdini-hive/hive-horizon-2024/

#houdini #forum

Мда 😕,перегнули палку ребята с критикой в адрес H20.5. Она и раньше конечно была, но обычно это единичные протесты в какой-то теме. Сейчас же несколько юзеров просто превратили гостевую форума в арену для конфликта создавая целые топики о том, что H20.5 нестабильна.

Жаль, теперь и тикет не найдёшь чтобы в поддержку можно было обратиться по похожей проблеме. В одиночку будешь бороться со своими проблемами и поддержкой отвечая на базовые вопросы: "а вы пробовали переустановить драйвера видеокарты" или "попробуйте забэкапить пользовательскую директорию houdiniX.Y". "Извините, я не могу воспроизвести эту проблему."

Лучшее, что могу посоветовать при обращении в поддержку это делайте запись экрана через OBS своих действий даже если видео длится больше 5 минут и в идеале на ванильном H. Как показала практика это намного эффективнее чем переписка. Единственное исключение если ваша сцена 100% падает при открытии с сегфолтом то её можно без видео отправить.

https://www.sidefx.com/forum/topic/97551/

#houdini #meme #solaris

У Solaris есть своя изюминка 🙂

#houdini #cop #taichi #julia #opencl

Сегодня на форуме обсуждали такой вопрос: какая могла бы быть возможная альтернатива другому языку в COP вместо OpenCL?
Поскольку многие отмечали, что OpenCL сложный и небезопасный язык для использования художниками.

"На данный момент в новом COP (Copernicus) есть два языка программирования для пользовательской логики. Первый - это старый надежный VEX, но он не работает на GPU. Другими словами, если вы используете VEX в COPernicus, вы, по сути, понижаете его производительность до уровня старого COP2. В некоторых случаях это нормально, но если текстура имеет размер 4k или больше, то бог с вами."

Сам автор трэда предложил такой язык как Taichi. Taichi Lang - это императивный язык параллельного программирования с открытым исходным кодом для высокопроизводительных численных вычислений на CPU или GPU. Ссылка не него в конце поста.

Но другой пользователь вспомнил про такой язык как Julia.
"Я думаю, что Julia - лучший язык программирования на данный момент, поскольку он настолько близок к математике, что хорошо работает с LLM потому что в нем не так много технической многословности. Это JIT-компилируемый язык с API на языке C. "

Возможно это тоже о чём-то мало скажет. Но тут я вспомнил, что уже видел одно воплощение Julia в Houdini наравне с VEX в виде сниппета которое работает с геометрией в SOP.

Легче ли на нём писать для артиста? Мне показалось, что нет 🙂 Нужна ещё одна абстракция над этим языком. 😜

https://github.com/pedohorse/yuria
Думаю, что оно даже под H20.5 соберётся сейчас.

И следом идёт показательная статья о том какую производительность показывает Julia в H по сравнению с VEX и удобно ли на нём было бы писать. Хотя бы интересно изучить.

https://www.patreon.com/posts/julia-61740179

Taichi:
https://github.com/taichi-dev/taichi

#gaffer #presentation #lighting

Приятно видеть, что Gaffer стали чаще демонстрировать в продакшене пусть и большинство не на больших проектах, однако сдвиги всё равно есть в этом направлении. Это небольшая демонстрация инструментов для рендеринга нескольких тысяч шотов.

Большинство пользовательских загрузчиков (лоадеров) в Gaffer представляют собой ноду сцены с кодом на Python, указывающим путь до ассета или каких-то других данных. Ассеты в таких системах обычно обновляются и синхронизируются через внешнюю платформу для управления проектами типа FTrack или Shotgun где в процессе создаются промежуточные кэши чтобы загрузка была отложенной и можно было фоном обновлять базу данных.

Волшебной палочки нет, весь успех производства это грамотно выстроенный и написанный пайлайн. ЧТД.

https://www.youtube.com/watch?v=jtjDbAHbPuE&ab_channel=rupertthorpe

#houdini #radialmenu #python #noscript #network #todayileaned

В H20.5 внутри стандартных пресетов Radial Menu оставили забавный пример печатающий в stdout информацию о событиях при взаимодействии с нодой.

В примере c нажатой клавишей Shift на входах, выходах, вайрах ноды или пустом месте в графе можем вызывать какое-то событие в Radial Menu, круг в меню пустой потому что мы никак не наполнили его элементами.
В идеале конечно сюда поместить какие-то полезные варианты работы в графе при создании Output у ноды, например вызов скрипта или обработка нод в графе, но сходу ничего не смог придумать и тупо сделал просто создание Null из имени ноды выше.

Другой пример чуть более наглядный который позволяет динамически создавать Radial Menu на основании имеющихся лайтов в LOP и выбирать из пунктов меню нужный. В идеале его совместить ещё с инструментом который будет прыгать по нодам при выборе лайта и было бы вообще хорошо.

#houdini #lpe #karma

TL;DR: Забавный баг LPE Karma (Mantra?) если так не было задумано конечно 🙂

В доке по использованию LPE написано следующее:
Unshadowed lighting contributions can be expressed by prefixing the expression with "unoccluded;". For example, unoccluded;C<RD>.+L

Это значит, что мы можем перед выражением дополнительно использовать префикс чтобы из рендера можно было вычесть вклад теней и нам для этого предлагается использовать unoccluded.

Всего один префикс? Что нам это даёт? Немного, поэтому попробуем ещё поискать "ключевые" слова.

Парсер рассматривает выражение unoccluded;C<RD>.+L как две подстроки до разделителя (точки с запятой) и после и оказалось, что парсер в префиксе ищет минимально совпадающую подстроку в своём подмножестве, т.е варианты: unocclude, unocc, uno, u тоже подойдут включая и пустую строку поэтому мы можем переписать эквивалентно предыдущую запись как ;C<RD>.+L или u;C<RD>.+L и это будет так же работать как и раньше.

Такая форма записи ;fucking;parsing;string;C<RD>.+L кстати тоже будет работать как и предыдущие две.

Простым перебором от a...z окажется, что мы можем использовать ещё один символ который влияет на AOV в рендере и им окажется s, т.е. это наверняка shadow. Противоположность первому варианту это получение вклада только теней в AOV от прямого и непрямого освещения, например s;C.*.

Но я честно говоря хотелось найти что-то ещё интересное, сломанное, недокументированное..

#houdini #opencl #copernicus

Это ты решил с наскока изучить OpenCL в COPernicus и установил Tile Size в -1...

#houdini #hda #pythonstate #instances

А что?! Выглядит любопытно достаточно.

B-System - это редактор SOP экземпляров, подобный ноде Copy To Points с интегрированным редактором, который позволяет добавлять, удалять и перемещать фрагменты непосредственно во вьюпорте.

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

- Палитра для выбора экземпляров прямо во вьюпорте, а также рабочий процесс для определения сборок и их повторного использования для создания детальных композиций из экземпляров.

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

https://youtu.be/M6UfgjYinjk

Gumroad:
https://ae43ae43.gumroad.com/

#houdini #vex #basic

Притворяемся безопасным языком программирования.

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

И один из таких примеров это работа с массивом, а именно доступ к элементам массива. В VEX используется оператор [] для доступа значения по его позиции в массиве. Однако если не знать про особенность, что границы массива проверяются уже в рантайме (время выполения) и чтение за пределами границ вернет 0 или "" для int[], string[] это может преподнести неприятные сюрпризы.

Например когда нам лень проверять границы массива перед доступом к элементу,

for(int i = 0; i < 1000; ++i){
    if(array[i] == ""){
        ...
    }
}

В таком случае мы не знаем когда функция войдёт в тело условия когда был найден пустой элемент или вышли за границы массива?
Что явно не одно и тоже. Простое исправления условия решило бы проблему: isvalidindex(array, i) && array[i] == ""

VEX предлагает нам использовать некоторые функции для поиска элементов в массиве это find и getcomp тоже самое, что оператор array[index] только это функция, здесь разницы нет.

Однако в перегрузки функции find для скалярных версий возвращают -len(haystack)-1 чтобы указать на отсутствие совпадений и поиск будет не константным, а за линейное время в худшем случае.

for(int i = 0; i < i; ++i){
    int idx = find(array, "");
    if(idx < 0){
        ...
    }
}

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

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

#define GET(type) \
function ##type get(##type array[]; int idx){ \
    if(!isvalidindex(array, idx)){ \
        error("index out of bounds: the len is \
        %d but the index is %d", len(array), idx); \
    } \
    return array[idx]; \
}

GET(int)
GET(float)
GET(string)

int xs[] = {0, 1, 2};
float fs[] = {1.3, 2.3, 3.4};
string ss[] = {"red", "green", "blue"};

i@integer = get(xs, 1);
i@integer2 = get(xs, 100); // Error!

f@flt = get(fs, 0);
s@str = get(ss, -10); // Error!

Для "красоты" завернём эту функцию в макрос чтобы можно было генерировать перегрузку функций по типу возвращаемого значения и не дублировать код. В идеале конечно перенести код в библиотеку и подключать просто хидер чтобы вызывать функцию get по мере необходимости когда нам нужно или не нужно проверять границы массива. Эту функцию можно рассматривать как более строгий вариант функции getcomp.

В документации есть сноска, что возможно в будущем текущее поведение индексации могут сделать строже, что это вполне станет ошибкой или предупреждением, а пока так.

#houdini #caching #timdepends

Когда Houdini наконец-то дождался, что ты разобрался со всеми лишними time dependends вещами в сцене...

#houdini #copernicus #copstance #hda #otl #rnd

Вышла версия COPstance для контекста COPernicus в Houdini. Это те же самые ноды, что были в старой версии плагина COP2, но теперь они полностью написаны с использованием нод COPernicus

Но существуют некоторые исключения. Например, узел FX-Map слишком сложен, чтобы его можно было реплицировать используя только ноды COPernicus. Поэтому доступен только узел Quadrant. Но, используя этот узел и SOP Import, вы можете попытаться воспроизвести нужные вам паттерны (хотя это будет немного сложнее, чем если бы у вас был полнофункциональный узел FX-Map).
Также на данный момент нет нод Fluid, Simple Perlin, Slope Blur, Tile и Tile Generator.

Теперь поговорим об основных преимуществах версии плагина для COPernius. Во-первых, поскольку он полностью написан с использованием узлов COPernicus то теперь это полноценная библиотека ассетов (в формате OTLLC). Это позволяет сделать плагин не только для Windows (как это было в версии для контекста COP2), но и полностью кроссплатформенным.
Также, поскольку это OTLLC-файл, к сожалению, для этой версии (по понятным причинам) нет пробной версии плагина. Вы получите доступ к файлу Digital Asset Library сразу после покупки плагина. Старая версия по-прежнему будет доступна на сайте, и вы сможете оценить функциональность узлов плагина COP2 на ней.

https://copsubstance.com