#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

#houdini #cuda #gpu #hdk #rnd

Интересный, опенсорсный проект.

Этот проект используется автором для изучения флюидной динами и ускорения GPU с помощью Cuda в Houdini.

HNanoAdvect - адвекция любых флотовых полей на GPU.
HNanoAdvectVelocity - адвектит любое векторное поле на GPU.
HNanoFromGrid - генерирует VDB из точек на GPU.

Преобразование из OpenVDB в NanoVDB требует больших затрат времени, около 150 мс на каждый активный воксель при 6M на 1080ti. Чтобы избежать этих преобразований, идея состоит в том, чтобы загружать только исходные данные в каждом фрэйме которые обычно являются небольшими VDB, и добавлять эти исходные VDB к существующим данным в GPU. Затем мы можем решить какую сетку мы хотим строить в Houdini на каждом фрэйме (обычно это денсити). Эта сетка должна быть преобразована из NanoVDB в OpenVDB.

Можно скомлировать под H20.5.

https://github.com/ZephirFXEC/HNanoSolver

#houdini #noscripts #python #network #ui

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

Простая и понятная реализация. Хотя кажется странным, что мы не можем просто попросить у нетворка айтем который находится под курсором вроде itemUnderCursor(), но жаль такого метода нет.

editor = kwargs["pane"]
if type(editor) == hou.NetworkEditor:
    rect = editor.visibleBounds()
    rect_data = editor.networkItemsInBox(editor.posToScreen(rect.min()), 
editor.posToScreen(rect.max()), for_select=True)
    if rect_data:
        cursor_pos = editor.cursorPosition()
        min_dist_to_cursor = 9999
        cursor_node = None

        for item, item_type, _ in rect_data:
            if item_type == "node":
                node_center = item.position() + item.size() / 2
                dist = node_center.distanceTo(cursor_pos)
                if dist < min_dist_to_cursor:
                    min_dist_to_cursor = dist
                    cursor_node = item

        if cursor_node is not None:
            # SET NODE AS CURRENT
            editor.setCurrentNode(cursor_node)
            
            # ENABLE DISPLAY FLAG IF THE NODE HAS IT
            if hasattr(cursor_node, "setDisplayFlag"):
                cursor_node.setDisplayFlag(True)

            # ENABLE RENDER FLAG IF THE NODE HAS IT
            if hasattr(cursor_node, "setRenderFlag"):
                cursor_node.setRenderFlag(True)

https://www.youtube.com/watch?v=jKVH3WaI9Rc&ab_channel=ModelerforHoudini

#houdini #gaffer #noscripts #python #ui

В Gaffer я могу дропать геометрию из вьюпорта и пути из графа сцены прямо на ноду, а не на параметр ноды (хотя это тоже можно). Это действие позволяет автоматически создать специальную ноду PathFilter которая умеет фильтровать подключаемые пути сбоку от ноды.
Мне показалось удобным дропать пути на ноду и захотелось повторить в Houdini.

Печально, что это недокументированная часть Houdini и большую часть времени потратишь на изучение сорсов чем на написание кода.

Плагин должен реализовать всего 3 функции, которые будут вызываться нетворком при перетаскивании элемента: dropTest,dropGetChoices,dropAccept.
Подробные комменты см в коде.

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

Референсные реализации: $HFS/houdini/noscripts/scene

GitHub:
https://github.com/alexwheezy/python/tree/master/houdini/scenegraphtree_dragdrop

#houdini #mpm #changelogs

Но посмотрим как оно в реальности будет 🙂

#houdini #mpm #testing #changelogs

TL;DR: Ускорили, но на прогресс нужно смотреть в длинной дистанции

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

Тесты проводились в дефолтных настройках пресетов в диапазоне на 50 кадров и на "горячую" чтобы исключить компиляцию ядер заново для каждого прогона (кстати Houdini кэширует этот момент чтобы в следующем запуске мы не ждали долгую компиляцию снова всякий раз и будет хранить кэши в $HOUDINI_TEMP_DIR/OCL_CodeCache), а так же чтобы в кэшах и регистрах процессора уже находились какие-то данные и инструкции и чтобы Houdini мог уже преалоцировать себе большой буфер видеопамяти и можно было смотреть только на статистику самого солвера. Данные были сняты с Performance Monitor и были усреднены для 3х проходов каждого теста.

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

HOUDINI_OCL_MEMORY_POOL_SIZE=0.5
HOUDINI_OCL_CACHE_SIZE=8192

Результаты тестирования:

Build             20.5.360       20.5.361
                Avg.Time/sec   Avg.Time/sec   Ad.Speedup
MPM Preset
Landslide:          47.4          25.1          1.89x
Pancakes:           60.5          35.3          1.71x
Softbody:           7.76          5.0           1.55x
Building Collapse:  88.2          30.3          2.91x
Jello Party:        28.5          17.6          1.61x
Metal Tearing:      318.2         292.7         1.10x
Rolling Snowball:   79.1          35.9          2.20x
Sand Instances:     38.5          31.7          1.21x
Spinning Tire:      25.7          16.4          1.56x
Water Glass:        12.2          11.6          1.05x

Ускорили? Да! В некоторых тестах более значительно, в некоторых не так ярко, однако улучшения по производительности всё равно чувствуются.

И звание самый шумный тест получил Building Collapse, очень сильно новый апдейт разгонял СО, что-то давно я не слышал такой шум вентиляторов 🙂, но при этом всём я не видел чтобы на GPU было выше 65 градусов. Наблюдения в некоторых тестах, например в Pancakes показывало, что солвер не всегда использует только GPU, но он так же активно ещё подключает процессор в многопотоке, а в других больше в виде однопоточной нагрузки.
А самый тяжёлый тест по-прежнему Metal Tearing, но я не разбирался в устройстве этого рецепта только смотрел на цифры (что он там делает?).
Возможно это всё повод сделать внеочередное обновление 👀.

У тестового стенда не было какого-то особенного разгона кроме установки XMP профилей на RAM и слегка подкрученного CPU Core Voltage.

System:
manjaro Kernel: 6.6.47-1-MANJARO arch: x86_64 bits: 64
WM: awesome v: 4.3-1654-g8b1f8958b-dirty

Machine:
ASUS ROG CROSSHAIR VIII HERO (WI-FI) v: Rev X.0x
AMD Ryzen 9 5950X, Be Quiet Dark Rock Pro 4
ROG Strix NVIDIA GeForce RTX 3070 Ti, driver: 550.107.02
128Gb DDR4 Kingston HyperX Fury, XMP 3200MHz
Samsung SSD 980 1TB size: 931.51 GiB

#houdini #geo #pighead

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

💥Список часто встречающихся тэгов на канале.

В принципе пора бы уже это сделать чтобы вам было проще ориентироваться если вы ищете что-то тут конкретное и тематическое:

General:
#houdini #vfx #fx #whatsnew #release

Solvers:
#mpm #microsolvers

Rigging:
#apex #kinefx #rig

HDA, OTLs:
#assets #otls #hda

Rendering:
#arnold #htoa #openmoonray #renderman
#lop #solaris #karma #render #lighting

USD, MaterialX:
#usd #hydra #pixar #materialx

Documentation:
#docs #help #doxygen

OpenVDB:
#openvdb

TOP, PDG, Task Managers:
#top #pdg #lifeblood

OpenCL:
#opencl

HScript
#hnoscript

VEX:
#vex #quiz #std

Python:
#python #noscripts #tools

COP, Copernicus:
#cop

R&D:
#rnd #pipeline #prism #siggraph #github #rust #hdk

Learning:
#todayilearned #tutorials #ui

Gaffer:
#gaffer

Maya:
#maya

Other:
#meme
#nuke #katana #mari
#converter #app
#vulkan #opengl #gl
#keynote
#notes

Некоторые категории успешно пересекаются поэтому, что не нашли в одной можно найти по-другому запросу.

#houdini #usd #solaris #hdk

Вышел интересный доклад на тему оптимизации производительности Solaris. Который более сжато пересказывает информацию из документации HDK и не так сухо.

Доклад больше ориентирован на:
- разработчиков пишущих новые LOP ноды
- TD's, желающих оптимизировать свои инструменты и рабочие процессы
- любопытных людей

Я пропущу всю техническую часть про С++ классы и устройство самого Solaris поскольку это интересно, но не для артистов и поэтому остановлюсь сразу на рекомендациях архитектора как улучшить свои рабочие процессы при работе с USD.

Making Fast LOP Networks

- Изменение ноды приводит к рекурсивному "загрязнению" всех его выходных данных:
- Сохраняйте часто редактируемые ноды в нижней части графа
- Избегайте временной зависимости от как можно большего числа нод

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

- Многие ноды в длинной цепочке часто можно разделить на несколько более коротких цепочек в сочетании с Merge LOP:
- Изменение ноды в более короткой цепочке готовит меньше нод
- Merge LOP быстрее всего выполняется в режиме Separate Layers

- В LOP предпочитайте Python вместо VEX. VEX отлично и быстро работает с геометрией, но в LOP мы работаем чаще с другими сущностями.
- Используйте чаще профилирование, чтобы отделить время оценки шаблонов prim от времени составления сцены и т.д.

Effective Primitive Patterns

Избегайте обхода всей стадии, когда это возможно:
- Используйте /foo/bar/** & xyz, когда это возможно, потому что /foo/bar/** обрезает обход для всех примов за пределами /foo/bar. Шаблоны оцениваются слева направо.

- Используйте %kind() там, где это возможно. Иерархия видов останавливается задолго до достижения листьев графа сцены, и поэтому позволяет упростить и ускорить поиск.

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

- По возможности избегайте VEXpressions.

- Рассмотрите возможность написания собственных автоколлекций.

https://vimeo.com/1012053710