#chill #killertime

Забыл поставить чекбокс и не знаешь почему твоей сетап не работает? Или без чекбокса и на рендер ушли не те пассы?
Подожди! Не спеши, потренируйся и выработай чекбоксную память!

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

https://onemillioncheckboxes.com/

#houdini #vex #learning #std

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

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

Почему Std библиотека так непопулярна?

По причинам названным ранее, она не задокументирована в справке Houdini поэтому на неё можно выйти только если вы достаточно любопытный пользователь или любите копаться в системных файлах программы.
Другая причина, считается, что Std библиотека это unstable, это значит, что служебный код там может меняться от версии к версии и может сломать Ваш код в один прекрасный день, однако я уже много лет не наблюдал такого и основном эта библиотека стабильная к изменениям.
Там скорее что-то может появиться дополнительно, а не исчезнуть совсем.

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

Код из Std библиотеки очень легко подключать в свои сниппеты. Достаточно знать название заголовочного файла *далее я буду писать вместо слова "заголовочный" слово "хидер" поскольку эти файлы имеют расширение .h и обычно их неформально принято так называть.

Стандартная библиотека насчитывает 78 хидеров (на момент написания этого поста и версии H20.0.571) разных категорий и находится в $HFS/houdini/vex/include и решает по сути маленькие задачи. Это говорит о том что многое может вам никогда вообще не понадобится, но тем не менее это ещё один источник информации о том как можно стандартизировать свой код.

VEX следует стандарту языка C поэтому все хидеры принято включать используя директиву include. Эта директива по сути "приказывает" вставить содержимое всего хидера в ваш сниппет, но вы этого конечно неувидите, но сможете обращаться к функциям и определениям в хидере как будто вы сами их написали только что.

Обычно это выглядит вот так просто и незамысловато, главное тут не ошибиться в написании:

#include <agent_util.h>

drawStar({0,0,0});

Недостатком тут является то, что VEX Wrangle не способствует обнаружению этих функций как "своих", встроенных и поэтому здесь не будет работать авто-дополение, подсказки и т.д, только хардкор и чтение функций, аргументов из самого хидера. Много позже я покажу как немного облегчить этот путь исследований.

#include <agent_util.h>

void drawStar(vector pos){...}
drawStar({0,0,0});

Ну и конечно если вы пишете свои собственные функции и включаете код из хидеров можете столкнуться с тем, что в хидере уже имеется такое же определение как и в Std и Wrangle вам громко скажет об этом, сообщением вроде: Multiple definitions of function: void drawStar(vector).
Std библиотека не имеет каких-то нэймспэйсов чтобы избежать коллизий с пользовательскими функциями, однако у Labs всё в этом смысле иначе сделано.

На этом долгое вступление думаю закончено и можно плавно переходить к самому содержимому хидеров. Приступим!

#houdini #vex #learning #std

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

Начнём с хидера agent_util.h

 * NAME:    agent_util.h
 */

#ifndef __agent_util__
#define __agent_util__

#include <math.h>

#define M_TAU 6.283185307179586

Он сразу подключает другой общий, зависимый хидер math.h который включает много полезных функций и встречает нас определением числа TAU которое приближённо в 2 раза больше числа PI.

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

///
/// Draw a set of axes at a specific point. Useful for debugging in the viewport.
///
void drawStar(vector pos){...}

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

vector getMatrixPosition(matrix m){...}
void setMatrixPosition(matrix m; vector v){...}
void rotate(matrix m; vector4 q; vector p){...}
void rotate(matrix m; vector4 q){...}
void rotateAboutSelf(matrix m; vector4 q){...}

Оцените уровень документации в этом хидере, параметры функции, описание, что это если не забота?
Но вы не часто такое будете видеть поэтому это в некотором смысле роскошь. Иногда придётся самостоятельно исследовать для чего нужен тот или иной аргумент.

///
/// Denoscription: Project a vector onto another.
///
/// Parameters:
///     * v1 - the first vector
///     * v2 - the second vector to project onto
/// 
vector project(const vector v1; const vector v2)
{
    return (dot(v1, v2) / length2(v2)) * v2;
}
float projectedDistance(const vector v1; const vector v2){...}
float perpproject(const vector v1; const vector v2){...}
float angleBetween(vector v1; vector v2){...}

Очень часто я вижу как эти фукции пишут руками из раза в раз и пишут иногда неправильно) Но раз они уже есть почему бы ими не воспользоваться?

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

///
int isDirectionWithinCone(vector conedir; 
                          vector up; 
                          float hozlimitangle; 
                          float vertlimitangle; 
                          vector dir){...}
///
/// Denoscription: Find an intersection along a line. Returns the 
///              primitive number of the intersection, or -1 if there is an error.
int
lineIntersect(const string terrain_input_path; const string terrain_group;
              const vector origin; const vector direction;
              const int bidirectional; vector hitpos)

И завершает этот файл набор специфичных функций для работы с агентами

float AGENTcollisionTime(...){...}
vector AGENTinteractionForce(...){...}
void AGENTcomputeChildTransforms(...){...}
vector AGENTtiltBack(...){...}
...

Опять же повторюсь, цель Std переиспользовать существующий код и взаимствовать идеи или куски кода для своих задач, а там есть на что посмотреть.

Для введения пока достаточно. Продолжение следует...

#materialx #github #release #shading

Мм, а что-то вкусное зарелизили в последнем MaterialX, например OpenPBR Surface и кондишен ноды, может они ещё до рэй-свитчей доберутся и починят вот этот PR.
В последней презе H20.5 не было упоминаний на этот счёт конечно, но вполне теперь можно ждать, что поддержка нового убер-шейдера может появиться уже в H21 (но это не точно).

- Added support for the OpenPBR Surface shading model, including the MaterialX definition and example materials for OpenPBR Surface v1.1.

- Added support for Hoffman-Schlick Fresnel, Zeltner sheen, and energy-compensated Oren-Nayar diffuse, with initial implementations in hardware shading languages.

- Added support for the LamaGeneralizedSchlick and LamaIridescence nodes, with definitions provided as MaterialX graphs.

- Added support for integer-type add, subtract, and conditional nodes.

- Added support for matrix-type switch and conditional nodes.

- Added support for additional convert node input and output types.

- Added support for monolithic builds of MaterialX.
...

https://github.com/AcademySoftwareFoundation/MaterialX/releases/tag/v1.39.0

#houdini #vex #learning #std

Продолжаем демистифицировать Std библиотеку. И заглянем сходу в VOP контекст где создадим пару популярных нойзов: aanoise, curlnoise, aaflownoise.

Чем они отличаются от одноимённых VEX-функций?

Если посмотреть в секцию Code у этих нод, то в поле ввода Outer Code мы увидим определение внешних библиотек:

#include <voptype.h>
#include <voplib.h>

и в Inner Code

#ifndef __vex
   $noise = vop_fbmNoise($pos * $freq - $offset, $rough, $maxoctave);
#else
  #if !strcmp($signature, "default")
   $noise = vop_fbmNoiseFV($pos * $freq - $offset, $rough, $maxoctave, $noisetype);
  #elif !strcmp($signature, "ff")
   $noise = vop_fbmNoiseFF($pos * $freq - $offset, $rough, $maxoctave, $noisetype);
  #elif !strcmp($signature, "fp")
   $noise = vop_fbmNoiseFP($pos * $freq - $offset, $rough, $maxoctave, $noisetype);
  #elif !strcmp($signature, "vf")
   $noise = vop_fbmNoiseVF($pos * $freq - $offset, $rough, $maxoctave, $noisetype);
  #elif !strcmp($signature, "vv")
   $noise = vop_fbmNoiseVV($pos * $freq - $offset, $rough, $maxoctave, $noisetype);
  #else
   $noise = vop_fbmNoiseVP($pos * $freq - $offset, $rough, $maxoctave, $noisetype);
  #endif
#endif
$noise *= $amp;

Где voptype.h и voplib.h являются базой для многих хидеров и содержат много полезного, служебного кода. (в voplib.h хидере довольно много функций имеют смысл только в shading контексте и как правило они разделены условной компиляцией вида #if defined(VOP_SHADING) ... #endif т.е будут работать только там где нужно)

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

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

float vop_RipplePattern(float x, y, decay, toff){...}
vector vop_frompolar(float u, v; float radius){...}
vector vop_topolarXYZ(float x, y, z){...}
vector vop_topolar(vector v){...}
float vop_bias(float base, bias){...}
float vop_gain(float base, gain){...}
vector vop_colorLinearTransform(...){...}
vector vop_colormix(vector c1, c2; float bias; int adjust){...}
void vop_composite(...){...}
...

Часто пользовался вот этим сэтом функций чтобы не писать их самому с нуля когда это необходимо, но разумеется полезных там много больше.
Хидер voptype.h наиболее простой он содержит определения алиасов на известные типы и какие-очень базовые функции по установке значений. Наверное самый простой хидер для изучения.

Продолжение следует...

#houdini #contents #kinefx #muscle #rig

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

Компания Djangotron Studios выпустила в бесплатную открытую бета-версию Procedural Anatomy, перспективный инструмент Houdini для создания геометрии мышц, тканей и скелетов CG-чарактеров.

Инструмент генерирует анимационный риг, совместимый с набором инструментов KineFX в Houdini, и может быть экспортирован в игровые движки или другие приложения DCC в формате FBX.

Открытое бета-тестирование началось вчера и продлится до 27 июля 2024 года, а пользователи смогут бесплатно пользоваться программой до 6 августа.

https://www.youtube.com/watch?v=X_EzRbPQq-8&ab_channel=ProceduralAnatomy

#houdini #whatsnew #release

Быстрый взгляд!

"Оказуалили" SideFX конечно H20.5. Этот новый Node Info с плавными анимациями виджетов 🙂 Ладно, возможно новым пользователям это и будет проще, но по мне так и старый справлялся.
Из забавного сходу в глаза бросилась возможность кастомить свои колорсхемы для VEX, Python, Expressions и т.д. Настроить её под себя конечно хотелось, но особо никогда не было приоритетной целью. Теперь это возможно, что приятно.

#houdini #whatsnew #release

Для COPernicus уже поделились ссылками на небольшое, независимое введение по нодам, работе Feedback Loops, OpenCL и сценами. Пока не появилось официальных уроков можно начать ковырять и изучать помимо официальной документации.

https://thevfxmentor.com/quicktips/COP

#houdini #vex #learning #std

Я обещал оставить тут свой способ использования Std библиотеки.

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

Ранее я уже делал пост об этом на этом канале, но теперь я обновил документацию и для H20.5. Документация самобытная и похожа на то, что используется в HDK. Библиотека так же содержит код используемый в OpenCL, OSL включая и новый код из последнего релиза.

Расширение:
https://github.com/alexwheezy/houdini-shl-doxygen/releases/tag/v0.1.1

#houdini #ui #ux #content

Радикальные идеалисты Houdini ведут постоянную борьбу за чистый и классный UX/UI (мало в релизах нового наверное) демонстрируя как это уже сделано в других DCC приложениях, но они забывают, что других приложениях только иконками и занимаются в основном. Мотивируя тем, что это должно повысить читаемость и бонусом притянет обязательно новых пользователей.

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

Кстати, никогда не задумывался о том, что иконка PolyBevel не выдержана в едином стиле с PolyBridge 😕Говорят правильней, что куб должен быть синий, а новые рёбра жёлтыми. Такие дела.

"Смотря какой fabric, смотря сколько details.."

📰 Шотландская студия AXIS объявила о банкротстве.

Компания, занимающаяся визуальными эффектами и анимацией, Axis Studios, объявила о банкротстве, и 162 сотрудника были уволены. Это была одна из крупнейших студий Шотландии, которая участвовала в проектах BBC, Netflix (Love, Death & Robots), Blizzard Entertainment и т.д. Из-за кризиса на рынке, студия не смогла найти новых клиентов, а рост стоимости труда только усугубил ситуацию. AXIS была основана в 2000-м году и проработала 24 года.

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

#houdini #cpu #intel #crash

Этот пост был навеян сообщениями о стабильных сегфолтах в Houdini без явных на то причин на совершенно новой сборке (Intel 14900K) одного из пользователей.

Тех. поддержка SideFX в таких случаях рекомендует отключать E-Cores через BIOS, что довольно неприятно когда ты от новой сборки ждёшь максимальную эффективность.

Обзоры независимых экспертов утверждают, что с 12900K не было таких проблема как с 13900K и 14900K, есть аппаратная проблема которую нельзя просто спихнуть на окружающие компоненты.

В другой статье упоминается проблема, которая может вызывать сбои в декомпрессии данных Oodle Data или сбои в играх, созданных с помощью Unreal.
"Мы считаем, что это аппаратная проблема, которая затрагивает в основном процессоры Intel 13900K и 14900K, менее вероятно, что также 13700, 14700 и другие родственные процессоры. Лишь небольшая часть этих процессоров будет демонстрировать такое поведение. Проблема, по-видимому, вызвана сочетанием настроек BIOS и высоких тактовых частот и энергопотребления этих процессоров, что приводит к нестабильности системы и непредсказуемому поведению под большой нагрузкой."

Возможно стоит подождать соответствующей новой прошивки BIOS или повременить с обновлением железа пока в пользу новых процессоров AMD пока Intel не исправит все недочёты.

https://www.techradar.com/computing/cpu/intels-woes-with-core-i9-cpus-crashing-look-worse-than-we-thought-team-blue-really-needs-to-act-now-to-fix-this-mess

https://www.radgametools.com/oodleintel.htm

#houdini #whatsnew #release #vex

Крайне неожиданное и не анонсированное обновление получил VEX Language которого честно говоря хотелось давно.

До H20.5 невозможно было определить struct внутри сниппета Wrangle и это можно было сделать только во внешнем хидере который нужно было заранее подключать директивой #include, а так же указывать специальную переменную (HOUDINI_VEX_PATH) чтобы Houdini видел все новые расширения если они определены не по умолчанию в директории $HOUDINI_USER_PREF_DIR/ houdiniX.Y.

Но теперь блоки кода со структурами могут быть помечены для перемещения за пределы генерируемой функции с помощью директив #outer и #endouter. Это перемещение выполняется перед стадией предпроцессинга.

Для примера определим тут 2 новых типа Point и Rectangle и напишем пару простых методов вычисляющих площадь и периметр прямоугольника.

#include <math.h>

#outer // {
// This code will be placed outside of the generated function
struct Point{
    float x, y;
    
    float dist(const Point other){
        return sqrt(pow(other.x - x, 2) + pow(other.y - y, 2)); 
    }
};

struct Rectangle{
    Point p1, p2;
    
    float area(){
        return abs((p1.x - p2.x) * (p1.y - p2.y));
    }
    
    float perimeter(){
        return 2 * (abs(p1.x - p2.x) + abs(p1.y - p2.y));
    }
}
#endouter // }
// This code will be in the function.

Point pt1 = Point(0, 0);
Point pt2 = Point(1, 2);

@dist = pt1->dist(pt2);

Rectangle rect = Rectangle(pt1, pt2);

@area = rect->area();
@perimeter = rect->perimeter();

Теперь мы сможем создавать собственные типы данных чтобы более чётко выражать намерения в коде с использованием структур и сделать код более чистым и понятным.
К слову Std библиотека очень много эксплуатирует структуры для инкапсуляции данных и организации кода.

#houdini #whatsnew #release #hnoscript

Кроме того в H20.5 подвезли так же расширенную статистику по потреблению памяти, что бывает тоже крайне полезно.

Команда hnoscript: memory теперь флаг -v выводит более подробную информацию об использовании памяти. Это может работать по-разному в графических приложениях, где также будет выводиться память используемая Vulkan.

До H20.5:

/ -> memory -v
Memory: 607.29 MB

После H20.5:

/ -> memory -v
Memory: 2.39 GB

== Cache Memory ==
           COP Cook Cache:  0.00 KB of 2.00 GB
       HDA Contents Cache:  0.00 KB of 32.00 MB
              Image Cache:  0.00 KB of 31.43 GB
   Object Transform Cache:  0.00 KB of 150.00 MB
     OpenGL Texture Cache:  0.00 KB of 1.60 GB
      OpenGL Vertex Cache:  0.02 KB of 6.40 GB
          Packed Geometry:  0.00 KB of unlimited
                SOP Cache:  0.00 KB of unlimited
     SOP Selection Memory:  0.00 KB of unlimited
                    Total:  0.02 KB

== OpenCL Memory Usage ==
Total Memory Allocated: 0 MB
In Memory Pool (cur / max): 0 / 994 MB
# of Buffers in Memory Pool: 0
In InUse List: 0 MB
Active Memory: 0 MB

== Vulkan Memory Usage ==
Heap 0    (D|-|-)
    VK  allocations:    15 (   312 MB)
    VMA allocations:    37 (   280 MB)
    Whole usage:       312 MB / (     6553 MB budget      8192 MB total
Heap 1    (-|V|C)
    VK  allocations:     0 (     0 MB)
    VMA allocations:     0 (     0 MB)
    Whole usage:         0 MB / (    77233 MB budget     96541 MB total
Heap 2    (D|V|C)
    VK  allocations:     0 (     0 MB)
    VMA allocations:     0 (     0 MB)
    Whole usage:         0 MB / (      196 MB budget       246 MB total
GL Exportable Pool
    VK  allocations:     6 (    82 MB)
    VMA allocations:     6 (    82 MB)

(Хотя многие мечтают менеджерить память вручную выгружая определённый кэш по запросу 😐)

#houdini #whatsnew #release #karma

Продолжаем разбирать "скрытые" новинки.

Как пересчитать определённые кадры в секвенции?

Начиная с H20.5 был добавлен флаг —frame-list командной строки для husk позволяющий просто перечислить нужные кадры через пробел.
По мне этот способ немного хакерский, мне больше по душе конечно решение на TOP нодах, но когда лень может и сойдёт.

Но без нюансов не обошлось.

Путь выходной секвенции $HIP/render/piggy.$F4.exr во время сохранения USD резолвится в полный путь с конкретным номером кадра (в USD ROP нельзя указать список кадров) и всё увы посчитается подряд с номерами 0001-0005, этого нам и не нужно, нам нужно заскейпить $F4 чтобы переменная номера кадра не резолвилась. Поэтому, новый путь будет выглядеть так $HIP/render/piggy.\$F4.exr

Естественно, что таким образом мы сможем пересчитать только уже сохранённый USD файл, если пропустим этот этап, то H сгенерирует временный USD который будет состоять из одного кадра поскольку мы запускам процесс с Render Current Frame.

#houdini #whatsnew #release #python

В H20.5 изменилась версия Python, но что дал переход на 3.11 по сравнению с 3.10?
В основном это конечно про импрув по производительности и уменьшению оверхедов.

Один из пропозалов был про улучшение трассировки сообщений об ошибках. Многие пользователи обычно редко читают ошибки который валит H, но возможно теперь вам будет проще логировать эти сообщения передавая дальше отправляя отчёты.

PEP 657: Fine-grained error locations in tracebacks
При печати трассировки интерпретатор теперь будет указывать не просто на строку, а на точное выражение, вызвавшее ошибку.

xs = []
prant(xs.caunt())

Traceback (most recent call last):
  File "/tmp/main.py", line 13, in <module>
    prant(xs.caunt())
    ^^^^^
NameError: name 'prant' is not defined. Did you mean: 'print'?

Сообщения теперь более гранулированы и интерпретатор показывает не только место исправления, но и возможный вариант исправления. Всё как в лучших домах ЛондОна. 🙂

Если мы исправим функцию prant() на print(), то следующая ошибка будет уже про неверный метод в листе.

Traceback (most recent call last):
  File "/tmp/main.py", line 13, in <module>
    print(xs.caunt())
          ^^^^^^^^
AttributeError: 'list' object has no attribute 'caunt'. Did you mean: 'count'?

Правда это помогает не всегда 😐

Python 3.10

Traceback (most recent call last):
  File "/opt/hfs20.0.761/houdini/python3.10libs/hou.py", line 17795, in loadItemsFromFile
    return _hou.OpNode_loadItemsFromFile(self, file_name, ignore_load_warnings)
hou.OperationFailed: The attempted operation failed.

Python 3.11

Traceback (most recent call last):
  File "/opt/hfs20.5.305/houdini/python3.11libs/hou.py", line 18114, in loadItemsFromFile
    return _hou.OpNode_loadItemsFromFile(self, file_name, ignore_load_warnings)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hou.OperationFailed: The attempted operation failed.

Вот трассировка одной функции, одной и той же библиотеки в H20.0 и H20.5. Сразу понятно теперь где нужно и что исправлять. 🤡

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

#houdini #github #opencl #copernicus #cop

Небольшие эксперименты на OpenCL в COP. Некоторые реализации просто порт с OSL, что тоже открывает дополнительные возможности для изучения OpenCL когда есть готовый алгоритм.
Я так понимаю, что автор планирует расширять библиотеку, поэтому полезно следить за обновлениями.

https://github.com/melMass/cops-cl?tab=readme-ov-file

#houdini #whatsnew #release #fx #mpm

После нескольких тестов с MPM Solver решил поискать самостоятельно причины "невысокой производительности" и нашёл тесты годичной давности автора и создателя по всей видимости MPM Solver'а в H20.5.

ICE (Neural Temporal Adaptivity for the Material Point Method Accelerated on the GPU) был создан в рамках магистерской программы в Университете Макгилла и программы Mila. Приложение представляет собой автономный MPM Solver, написанный на C++/CUDA. Оно использует встроенную 3D-конволюционную нейронную сеть для асинхронного определения активных областей моделирования. Экспериментальные результаты показывают улучшение производительности в практических сценариях. Несмотря на то, что это не плагин, был создан небольшой набор HDA, позволяющий создавать сцены в Houdini напрямую. Все симуляции были отрендерены с помощью Karma XPU.

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

Scene        Particle Count  Grid Res.  Timestep (×10-4) Sec/Frame Ad.Speedup
Ship Breach      54.0M   492 x 212 x 492     6.9           16.6      3.38x
Bullet Time      24.1M   688 x 364 x 492     4.2           17.9      1.05x
Avalanche        35.5M   736 x 148 x 760     21.0          7.5       1.53x
Train Push       24.9M   520 x 144 x 174     2.6           28.8      1.55x
Rally Drift      14.9M   1400 x 196 x 536    1.1           40.7      2.00x
Glacier Collapse 39.5M   320 x 184 x 520     6.9           16.4      1.00x

Глядя на результаты в таблице есть 2 соображения:

- В H20.5 я ничего не нашёл про Neural Temporal Adaptivity применительно к MPM Solver для улучшенного и прагматичного солвинга, сейчас это "чисто" расчёты с помощью OpenCL и использование разряженной сетки NanoVDB в фоне. (Проглядел или это задел на следующий релиз?) У автора в работе PDF по его диссертации открывающая детали реализации ICE, но пока у неё статус Coming Soon...

- MPM Solver в целом и не был никогда реалтаймовым (даже у DreamWorks) чего от него многие ожидали глядя на то что это расчёты на GPU, но на то это и презентация 🤪. OpenCL конечно в ряде сценариев намного может быть быстрее чем VEX, но данные (и их не мало), всё равно приходится перегонять по шине так или иначе между хостом и компьют девайсом память, а это зачастую неизбежные потери + H должна менеджерить остальные ресурсы и заниматься красивой отрисовкой во вьюпорте.
Скажем спасибо, что это было реализовано хотя бы не на CPU.

На данный момент важный и основной вопрос почему в MPM Solver такое высокое количество сабстепов по умолчанию и почему такая медленная компиляция ядер?

Документация говорит, что:
Солвер динамически выбирает наименьшее количество сабстепов, основываясь на типе и скорости материала. Хотя по умолчанию максимальное значение установлено на 10 000, это не означает, что обязательно будет использовано 10 000. Фактическое количество сабстепов можно увидеть на выведенной геометрии в качестве дитэйл аттрибута. Высокое значение по умолчанию предназначено для более жестких материалов, таких как бетон или металл, которые требуют большего количества подшагов и, как ожидается, будут медленными.

Это значит что и CFL, и Material Conditions накладывают свои собственные независимые ограничения на максимально допустимый интервал таймстэпа. При солвинге очень жестких материалов (ограниченных условием материала, например металла или бетона) объекты будут двигаться относительно быстро без заметных изменений в количестве сабстепов требуемых условием CFL.

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

Но будем надеяться, что скорейший мастер-класс сможет прояснить ситуацию на эти вопросы включая и не быструю компиляцию ядер 😕

https://www.youtube.com/watch?v=md_UXDYrlL4&ab_channel=AlexandreSirois-Vigneux

#houdini #whatsnew #release #fx #mpm

███▄ ▄███▓ ██▓███ ███▄ ▄███▓
▓██▒▀█▀ ██▒▓██░ ██▒▓██▒▀█▀ ██▒
▓██ ▓██░▓██░ ██▓▒▓██ ▓██░
▒██ ▒██ ▒██▄█▓▒ ▒▒██ ▒██
▒██▒ ░██▒▒██▒ ░ ░▒██▒ ░██▒
░ ▒░ ░ ░▒▓▒░ ░ ░░ ▒░ ░ ░
░ ░ ░░▒ ░ ░ ░ ░
░ ░ ░░ ░ ░
░ ░

Не верьте блогерам, знакомым, коллегам которые пиарят MPM как "blazing fast" решение, они показывают флипбук 😅

Ещё немного эксклюзива ⚡️ про MPM Solver. Я не стал дожидаться появления мастер-классов и попутно пока делал предыдущий пост про MPM написал автору чтобы уточнить пару вопросов про его работу над этим солвером.

- Почему в H20.5 в настройках солвера по-умолчанию установлены такие высокие сабстепы?

Я слышал, что многие люди были разочарованы тем, что, хотя MPM активно использует OpenCL, но отзывчивость тестовых примеров в H20.5 во вьюпорте очень низкая даже на очень хороших рабочих станциях с видеокартами Nvidia 4090.
Хотя если значительно снизить количество сабстепов то становится намного лучше, но стабильность симуляции падает.
Может быть есть какие-то оптимальные настройки для старта?

Alexandre Sirois-Vigneux:
- MPM печально известен своей медлительностью. По моему скромному мнению, CPU MPM просто непригоден для использования. Я сделал GPU MPM только для того, чтобы сделать его пригодным для использования в производстве, но он не быстрый, если сравнивать его с более простыми алгоритмами флюидной динамики.
Он быстр, только если сравнивать его с CPU MPM, который большинство людей никогда не использовали. Учитывая это, я постараюсь сделать его быстрее в будущем, но я не ожидаю увеличения скорости на порядки.
Явное интегрирование в паре с жесткими материалами действительно требует большого количества сабстепов.

- Правильно ли я понимаю, что ваша диссертация по использованию нейронной временной адаптивности для MPM все еще в работе? И в H20.5 этот метод не реализован? Сейчас реализованы только GPU-вычисления?

Alexandre Sirois-Vigneux:
- В настоящее время мы не используем никаких нейронных сетей и не делаем локальную временную адаптивность. Причина в том, что мы хотим сохранить как можно больше памяти для самого сима.
Фризинг партиклов появится в следующей итерации (здесь он не поясняет это, но я так понимаю, что имеется ввиду, что сейчас неактивные партиклы всё равно участвуют в симе), но оно, скорее всего, не будет опираться на нейронные сети. Сначала будут протестированы более простые подходы.

Продолжение следует...

#houdini #opencl #cop #sop

При использовании OpenCL в SOP, а теперь ещё в COP можно столкнуться с неожиданными ошибками приводящими к неопределённому поведению.

Возможно по роду своей деятельности вы и не часто будете писать код на CL (возможно и никогда) для SOP, но для COP придётся использовать существующий код из открытых источников или писать что-то своё простое, какие-нибудь интересные, шейдерные паттерны.

OpenCL очень редко сообщает когда вы совершаете логическую ошибку, а в некоторых случаях и синтаксическую.

Например, неявное приведение типов из float в и int в VEX

int x = 10.5;

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

OpenCL же не выдаёт по-умолчанию никаких предупреждений или намёков на что-то подобное, но можно этому процессу помочь используя Kernel Options или Compiler Options чтобы сделать предупреждения явными, а так же сделать предупреждения строгими ошибками компиляции.

В OpenCL SOP это указывается в Kernel Options флагом -Werror, а в OpenCL COP Compiler Options, после этого компилятор будет под прицелом смотреть на весь код, что будет очень полезно чтобы избежать ошибок на ранних стадиях.

Кайф, теперь это ошибка и нужно явно приводить один тип к другому если мы этого хотим.

int x = 1.9f;

// OpenCL Exception: <kernel>:1581:13: 
// error: implicit conversion from 'double' to 'int' 
// changes value from 1.9 to 1

int x = (int)1.9f;

Здесь та же самая ситуация, мы используем несовместимые типы в сигнатуре функции и передаваемом аргументе.

void foo(int* ptr){}
foo(10);

// OpenCL Exception: <kernel>:15:9: 
// error: incompatible integer to pointer conversion 
// passing 'int' to parameter of type '__generic int *'

int x = 10;
foo(&x);

Мне очень нравится, что таким образом можно проверить находится ли значение в границах массива, не вызывая падения Kernel в неожиданных местах.

int arr[] = {1,2,3};
int x = arr[100];

// OpenCL Exception: <kernel>:1582:13: 
// error: array index 100 is past the end of the array 
// (which contains 3 elements)

Это разумеется не все ошибки, но одни из популярных с какими сталкиваются часто.

#houdini #nodeinfo #network

Кто ещё находится на стадии отрицания с новым UI в Node Info всё ещё можно вернуться к "старому виду" используя недокументированную переменную окружения:

HOUDINI_USE_OLD_INFO_WINDOW=1

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