#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

#houdini #python #noscripts #tools #network

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

В плане визуализации нам помогает Depedency Links - Show for All Nodes однако это только визуализация и мы не сможем использовать этот же метод из Python API чтобы "потрогать" этот список.

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

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

#lifeblood #renderarm #rnd #pipeline #manager

Гуд ньюс! Lifeblood-Manager получил обновление приближающее его к более практичному использованию для конечного пользователя. Мне никогда особо не нужно было управлять планировщиком и пулом из трэя, но я слышал, что для артиста будет удобнее когда он точно будет знать, что процесс имеет автозапуск и может быть свёрнут в трее.

🤖 Lifeblood-Manager update v0.5.0!

Minimize to tray and Autostart

- Now can stay in tray after closing
- Can Autostart with the system
and additionally start some components,
such as Scheduler and/or Worker Pool
- (windows) Console window is now hidden by default,
But can be shown/hidden with buttons on Launch tab
- Remembers selected installation dir and autostart
configuration into a file next to exe.

Patreon:
https://www.patreon.com/posts/lifeblood-is-now-114356547

GitHub:
https://github.com/pedohorse/lifeblood-manager/releases/tag/v0.5.0

#houdini #epyc #amd

Multi-socket EPYC System can't reach above 50% load

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

Будет ли линейный рост производительности от количества ядер процессора? Всегда ли больше - лучше?
Как оказывается далеко не всегда.

Автор темы столкнулся с тем, что 2х-сокетная система собранная на AMD EPYC 9654 96-Core Processor (суммарно в 192 ядра и 384 потока) c Gentoo Linux под Houdini не смогла быть загружена на все 100% в симуляции, а только на 50% в хайлоаде.

Ответ тех. поддержки в SideFX со слов автора примерно такой:

При 384 потоках вам потребуется довольно большая рабочая нагрузка, прежде чем они смогут насытиться. Возможно, вы даже добьетесь большего прогресса в производительности если запустите меньшее количество потоков с опцией -j, а затем запустите несколько процессов Houdini.
Синхронизация 384 потоков сама по себе занимает время...

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

Далее они обсуждают работу c AttribWrangle в режиме Number поэтому краткая врезка о том как он используется:
Когда используется Run Over в режиме Numbers то это говорит о числе итераций которые будут выполняться в отдельном потоке. Если это число больше или равно Number count, все итерации будут выполняться последовательно в одном потоке. Если это число равно 1, то каждая итерация будет выполняться в отдельном потоке. В промежутках между итерациями нода будет группировать их в партии этого размера и запускать каждую партию параллельно в отдельных потоках.

Если мы "раскрутим" все потоки с помощью AttribWrangle, гранулярность которого по умолчанию составляет 1024 для потока, то вам необходимо как минимум значение 384 * 1024. Затем создал бы ядро которое выполняет некоторые длительные вычисления для каждой точки, т.е. время работы SOP должно занимать секунды, но если вместо этого вы попытаетесь запустить SOP много раз небольшими задачами чтобы ускориться у вас будут точки синхронизации и вы не сможете полностью загрузить все потоки.

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

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

#houdini #news #karma #nvidia #render

Пока Россиян отлучили от разработки ядра Linux и Линус Торвальдс заявил, что отмены решения не будет 🤡, а Nvidia лишила доступа к новым драйверам в SideFX так же сломали Карму.

Официальное обращение от Chris McSpurren, Senior Quality Assurance Specialist:

"Привет! Как некоторые из вас обнаружили, существует проблема при обновлении до драйвера Nvidia 565. Если вы уже обновились, откатитесь назад. Если вы еще не обновились до драйвера 565...хорошо.
В настоящее время мы работаем с Nvidia над этой проблемой. Проблема возникает только в том случае, если Karma XPU использует Optix. При работе Karma XPU с Optix может возникнуть ряд проблем, начиная от голубого оттенка подсветки и заканчивая полным отказом устройства из-за сообщения cudaErrorIllegalAddress.

Мы сообщим вам, когда у нас будет больше информации."

upd: В ежедневной сборке 20.5.397 содержится потенциальное обходное решение/исправление этой проблемы с драйвером которое мы сейчас тестируем. Если у вас уже установлен драйвер nvidia 565+, попробуйте 20.5.397 и посмотрите, будет ли он лучше для вас.

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

Как выглядит пайплайн на бумаге 😅

🎬 VES VFX JOBS DESCRIPTION

Сегодня VES опубликовал очень интересный и суперполезный документ, в котором они описали общую структуру VFX студии, её департаменты и роли всех участников. Сформулировали как выглядит Pipeline студии, кто кому рапортует, процесс производства шота и момент, когда подключается тот или иной департамент в процессе производства.

Посмотрите на очень любопытный раздел Levels of expertise in the VFX professions. Там наглядно расписаны уровни художников и продакшена в соответствии с уровнем выполняемой ими работы, независимости, степени ответственности и вовлеченности в организацию процессов/команд/проектов.

Ну и в заключении они описывают взаимодействия и области ответственности всех участников создания VFX, начиная от главного VFX супервайзера до узкоспециализированных художников.

#gaffer #render #lightning #opensource

Shading & Lighting with Gaffer and Arnold | Level Up Your VFX Game
Introduction to Gaffer and Arnold | Open Source VFX / CGI Basics

Удивлён в хорошем смысле, что Gaffer начали пушить среди CG-блогеров хотя стабильный, последний релиз 1.5.0.1 и не был ознаменован как финал финалов тем не менее люди всё равно начали к нему присматриваться.
Arvid записал уже пару уроков с рендером Arnold о том как начать с ним работать в сцене и разобрать его на паре примеров сам процесс лукдева.

#cgnews #modo #foundry

Modo, всё.

Компания Foundry объявила о своем решении прекратить разработку инструмента для 3D-моделирования Modo после выхода версии Modo 17.1 в конце этого года. Это стратегическое решение позволит Foundry сосредоточиться на своих основных предложениях и инвестировать в новые решения, отвечающие развивающимся потребностям медиа и развлекательного сообщества.

https://www.foundry.com/news-and-awards/foundry-winds-down-modo-development

Кто ещё помнит о Athera от Foundry? Платформа, ранее известная как Elara, предоставляла облачный производственный сервис "все в одном", включая виртуальные рабочие места, аренду программного обеспечения, рендеринг, инструменты для совместной работы и аналитику, но в итоге массово так и не пошло. Проект свернули через 18 месяцев после открытия и полностью закрыли к 2020 году.

https://www.cgchannel.com/2019/11/foundry-closes-athera/