#houdini #vex #hda #std #todayilearned

Не особо популярные возможности использования AttribWrangle взятые из стандартной библиотеки SideFX HDA которые можно так же использовать в своей работе или хотя бы взять на заметку. Картинки пронумерованы поэтому пойдём по пунктам:

TD;LR:

1. Чтение данных из второго входа и запись в атрибут Detail выходной геометрии.
2. Вычисление результатов на месте без создания промежуточной копии геометрии.
3. Создавайте атрибуты только в том случае, если их имена соответствуют шаблону.
4. Обработка ошибок на VEX, так же и в графе.
5. Референс снипетов кода в другие снипеты.

А теперь подробно:

1. Это довольно распространённый приём во всей библиотеки, где основная суть прочитать данные (атрибуты) со второго входа и записать их на Detail выходной геометрии. Однако это так же может использоваться как ещё один способ создания и новой геометрии, избегая создания ещё одного цикла в конце снипета чтобы удалить входящую геометрию, т.е вместо такого:

for(int i = 0; i < nprimitives(0); ++i)
    addpoint(0, vector(prim(0, "P", i)));

for(int i = 0; i < nprimitives(0); ++i)
    removeprim(0, i, 1);

можно будет просто написать

for(int i = 0; i < nprimitives(1); ++i)
    addpoint(0, vector(prim(1, "P", i)));

Добавили чуть оптимизации и меньше написали!

2. Compute In Place. При компиляции Attribute VOP может работать с входящей геометрией на месте, не создавая ее копию. Это может ускорить обработку, так как создается на одну копию меньше, но требует, чтобы код VEX не связывал для записи любые атрибуты, которые считываются из первого входа.
Вы можете записывать в любые атрибуты, только НЕ в те, из которых вы читаете, так как он не создаст копию геометрии, поэтому не сможет прочитать оригинальные значения, если они будут перезаписаны.
При попытка сделать запись вида @P = point(0, "P", @ptnum); будет выброшена ошибка вида Error: Attempt to read from actively streamed attribute P.

Эта особенность так же активно эксплуатируется во всей библиотеки там где можно и не нужно. И наибольшую выгоду от использования можно почувствовать если использовать её именно в блоке компиляции на большом количестве геометрии (>10 лямов). Некоторые люди отмечали внушительный 3-4х кратный прирост при обработке, но в других сценариях польза может быть более изотерична и не так выражена.

Здесь вопрос оптимизации отрытый и более тонкий (много где включено по-умолчанию в ассетах).

3. Шаблон по умолчанию позволяет создать любой атрибут. Вы можете ограничить создаваемые атрибуты, заменив * на список разрешенных имен.
Стандартная библиотека смотрит это как на своего рода иммутабельность атрибутов, те которые явно экспортируются те и используются, все остальные только для чтения. Это предотвращает ситуации когда вы случайно хотите поменять значение в атрибуте который менять нежелательно. В таком случае компилятор скажет: Error: Read-only expression on left side of assignment (1)).

4. Обработка ошибок в VEX 💣 представлена разными функциями: warning,error. error cообщает о пользовательском предупреждении VEX во время выполнения. При этом используется тот же синтаксис строки формата, что и в printf. Так же нередко используется и одноимённая нода Error которая так же может полезна когда вы хотите дать обратную связь сразу если входные данные невалидны со своим сообщением. Приятней видеть всё таки понятные ошибки вида: Ты не видишь бл*ть!? Атрибута нет! вместо id not found.
(На этом скрине так же видно, что автор вообще не экспортирует никакие атрибуты явно показывая, что тут не происходит создания новых атрибутов, поэтому параметр Attributes to Create пуст)

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

На этом пока всё 🙂

https://imgur.com/a/fTRUtbq

#houdin #apex #cop #whatsnew #release

APEX isn't JUST for rigging!!!

Да, начиная с H20.5 в APEX можно теперь собирать дебажить COP граф. Что можно с этим сделать в APEX?

Пока немного, COP может генерировать граф APEX, который был скомпилирован и выводит его в виде геометрии, а не как результат целенаправленной обработки COP во вьюере.
Это в основном для отладки или эзотерического использования, например для генерации slap-comp-файлов формата bgeo или bgeo.sc, простыми словами, возможность применять одинаковый пре-комп к разными USD файлам.

Например, husk --slap-comp geo/defocus.bgeo geo/test.usdnc, а не копировать из сцены slap-comp каждый раз в новую сцену. Этот параметр может встречаться несколько раз, и каждая операция выполняется последовательно.
Это так же может быть запущенно непосредственно с ROP ноды в Solaris.

Нооо, поскольку COP это бета, всё чего я добился это:

55225: Fatal error: Segmentation fault (sent by pid 0)
-- TRACEBACK BEGIN --
...
-- TRACEBACK END --

Видимо надо подождать ещё 🙂

#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.

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