#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

#houdini #meme

Если ты считаешь себя Тру Гудиньщиком в RU сегменте то ты знаешь как согласуются вместе эти вещи.
Но ты можешь попробовать угадать сам, здесь повсюду разбросаны подсказки и кстати я покрыл изображение дополнительно фосфором так, что в ночи при лунном освещении ты сможешь тоже кое-что увидеть, но а если ты сдаёшься вот так сразу то конечно всегда сможешь прочитать ответ: ты максер!

#houdini #opencl #cop #github

Не удивлён, что кому-то пришло в голову сделать это классическое задание по написанию Ray Tracer'a на каком-то ЯП и так уж получилось, что на OpenCL и внутри COP который работает молниеносно.

Однако это хороший пример того чтобы показать, что работать с COP OpenCL не ультра сложно и можно взять какой-то код на C и его распараллелить в кернеле не особо напрягаясь.
Во всём коде от OpenCL специфичного кода это разве, что заведение параметров через bind, различные касты и определения типов в стиле float3,4, а так же приходится оборачивать основной код в KERNEL шаблон (который генерирует общую форму создания kernel функции, глобальных параметров, начальных условий и т.д) и использовать обработку каждого индекса в буфере независимо:

float2 pindex = (float2){ (float)@ixy.x, (float)@ixy.y};
float2 res = (float2){ (float)@res.x, (float)@res.y};

В остальном это классический код на C.

GitHub:
https://github.com/richardcope/cops-ray-tracer

#houdini #gaffer #lifeblood #opensource

Честно говоря, последнее время мне совершенно нечего нового рассказать о Houdini. Sad but true.

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

Поэтому чтобы избежать участи очередного новостного канала-агрегатора который собирает ассеты, ссылки со всего гитхаба, ютуба и т.д., я буду смещать фокус от Houdini в сторону других опенсорсных приложений и проектов которые мне кажутся достойными внимания и да, в том числе среди них будут: Lifeblood, Gaffer, рендер-менеджеры и другие. А где мы ещё посмотрим на Cycles без Blender?

#gaffer #basic #introduction #opensource

Не знал, что у Trixter Film оказывается такой полезный канал и помимо шоурилов, брэйкдаунов они начали выкладывать и образовательный, уникальный контент. Неожиданно 2 дня назад выложили пару свежих ролика по введению в Gaffer.

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

Я Gaffer никогда не использовал полноценно в реальном производстве, изучал исключительно для себя поскольку люблю такое, хотя мысли и попытки были однажды его применить на проекте "Легенда о Коловрате", однако я уже смутно помню детали такого выбора, возможно, что в Houdini мы упёрлись в какое-то мыслимое ограничение которое было уже реализовано там. На тот момент программу версии ~0.25-0.5 нужно было самостоятельно собирать из исходников (для Windows версия программы появилась относительно недавно), она часто падала с ошибками сегментации памяти SegFault и нельзя было нормально трансформить объекты используя хэндлы во вьюпорте, но из года в год это не останавливало смотреть за прогрессом программы. С годами продукт стал и становится намного лучше и стабильнее и очень хорошо, что начинает появляться обучающий материал.

GitHub:
https://github.com/GafferHQ/gaffer

https://youtu.be/qJWtai73TB8?si=zrguJNU7cjRbQEl4
https://youtu.be/aKUMRKPbdZI?si=FaOxWlfB9VmT3XbV

#houdini #python #custom #desktop

Network Context Desktop Mapping

Мне такое было не сложно делать руками, но однако есть люди кто решил, что неплохо было бы автоматизировать смену рабочих столов в зависимости от контекста. Например, если я нахожусь в нетворке SOP, я бы хотел, чтобы Houdini автоматически переключался на рабочий стол A. Если я затем погружаюсь в нетворк COPernicus, я бы хотел, чтобы автоматически происходила смена на рабочий стол B и так далее.

Автор использует хардкод в виде словаря для маппинга:

# network context mapping to desktops
editor_desktop_map: dict = {'Object' : 'Build', 
                            'Sop'    : 'Modeling', 
                            'Vop'    : 'Labs', 
                            'Dop'    : 'Technical', 
                            'CopNet' : 'Image'}

Его нужно будет поднастроить под свои нужды.

#python #whatsnew

TL;DR: в Python разблокировали GIL?

Не про красивые пиксели на экране, но однако не смог мимо этой новости пройти.

Сегодня релизнулся Python 3.13 - это последний стабильный выпуск языка программирования Python, содержащий множество изменений в языке, реализации и стандартной библиотеке. Самые значительные изменения включают новый интерактивный интерпретатор, экспериментальную поддержку работы в свободно-поточном режиме (PEP 703) и компилятор Just-In-Time (PEP 744). Это довольно интересный и значимый релиз.

Пропустим про интерпретатор и остановимся на свободно-поточном режиме. В CPython появилась экспериментальная поддержка работы в свободно-поточном режиме с отключенной глобальной блокировкой интерпретатора (GIL). Это экспериментальная функция, и поэтому она не включена по умолчанию. Для работы в свободно-поточном режиме требуется другой исполняемый файл, обычно называемый python3.13t или python3.13t.exe.

Простыми словами GIL это то, что мешает сейчас добиться настоящего параллелизма используя все ядра процессора в СPython, но работы в этом направлении уже ведутся довольно давно и сейчас это становится частью стандарта. Это любопытная вещь чтобы протестировать код и оценить прирост производительности.

А так же JIT. Когда CPython настроен и собран с использованием опции --enable-experimental-jit, добавляется компилятор just-in-time (JIT), который может ускорить работу некоторых Python-программ.

https://docs.python.org/3/whatsnew/3.13.html#whatsnew313-free-threaded-cpython