#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

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

#houdini #meme

Когда изучил всю документацию, посмотрел фоном все курсы и стримы Horikawa от корки до корки и теперь готов написать свой первый, рабочий код..