#houdini #apex #rnd #content #procedural

APEX is NOT a programming language, it is not VEX, it is not VOP.

Именно такой заголовок хочется написать первым чтобы начать разговор об APEX. Когда нам презентовали этот новый фрэймворк у многих осталось устойчивое впечатление будто это что-то сделано исключительно для системы процедурного риггинга. Но у этого фрэймворка как и у SideFX совершенно другие планы на его развитие.

SideFX совершила ошибку рекламируя APEX как инструмент для процедурного риггинга. Я имею в виду, что до сих пор SideFX представлял несколько SOP-нод 'component, autorig, rignoscript' как APEX и люди будут ассоциировать APEX как этот инструмент.

В этом обзоре я попытаюсь ответить на вопрос: что же такое APEX на самом деле по мнению людей и того, что посмотрел я уже к этому времени.

#houdini #apex #rnd #content #procedural

Давайте ненадолго вернемся к Maya.
Вы когда-нибудь открывали редактор нод в Maya? Что вы видите?

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

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

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

APEX прежде всего в своей основе - это не что иное, как движок, который может запускать ноды и передавать данные между ними.
Забудьте про понятие кода как данных, про то что APEX хранится как геометрия, данные есть данные, неважно, как они хранятся, и неважно как они сохраняются.

Граф APEX может быть yaml-файлом, json-файлом или бинарным файлом, поэтому совершенно неважно, что сейчас он хранится как геометрия, данные есть данные и не имеют смысла сами по себе. Когда вы хотите запустить APEX Graph, вы сначала запускаете данные (которые в настоящее время являются геометрией Houdini) и переводите их в APEX Graph, а затем передаете этот график движку APEX.

import apex
apex.Registry().reloadSubgraphs()

APEX находится на уровне ниже SOPs и не привязан к какому-либо привычному контексту в представлении пользователя. Вы можете строить, манипулировать и запускать графы APEX, используя API Python, другие графики APEX и SOPs. В будущем могут появиться другие контексты, которые смогут получать доступ к графам APEX и использовать их.

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

SOP не может быть заменен APEX и не исчезнет так как вы тогда потеряете все, что делает SOP великим: экпрешенны, hda, и так далее.

Итак, ещё раз.
APEX - это низкоуровневый фреймворк, на котором построены существующие инструменты, но сам по себе APEX не является системой риггинга, это абстрактная система, которая в первую очередь используется для риггинга в этой версии Houdini.

#houdini #apex #rnd #content #procedural

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

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

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

#houdini #lifeblood #renderarm #rnd #pipeline

Оригинальные фичи которые есть у Lifeblood и которых не хватает в PDG/TOP.

Возможность сделать рекурсию!

Крайне необычная возможность для нодового графа связать выход ноды со входом и если вы попробуете сделать нечто подобное в Houdini получите основательное сообщение в духе:
Error: Infinite recursion in evaluation.
Поскольку мы не можем явно задать условия для выхода из неё. И кажется какой в этом может быть прок для работы с тасками?

Здесь я для примера сделал 2 типа тасков: один копирует файлы из одной папки в другую рекурсивно, а второй тип просто копирует эту же директорию целиком.
С первым вариантом мы можем добиться сильно большего: например возможности ожидания появления файлов на диске наблюдая за ними используя file watcher и применить к ним какую-то операцию преобразования.

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

#houdini #lifeblood #renderfarm #sim #pipeline

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

Что если мы в середине процесса забыли что-то и хотим поменять? У нас не будет иной возможности как только перезапускать таски.

Планировщик PDG всегда считает, что мы "загрязняем" граф создавая новые зависимости поэтому требуется его рекукать заново даже несмотря на новые возможности в более поздних версиях паузить задачи, но это не всегда происходит и не всегда удобно.

Напротив в Lifeblood граф никогда не остановлен, всё динамическое, один и тот же граф может обрабатывать таски разных юзеров, групп тасков. Мы можем при процессинге работы динамично изменять граф и считать задачи добавляя новые таски. Это безумно удобно, как же этого не хватает в PDG.

#houdini #whatsnew #todayilearned #content #opencl

Давненько что-то не было ничего OpenCL'го.

Исправляемся и пишем простую, итеративную, но эффективную реализацию Relax Points на современном OpenCL SOP.

Подробности как это сделать в следующем посте.

#houdini #whatsnew #todayilearned #content #opencl

Сначала находим ближайшие точки находящиеся в заданном радиусе с помощью pcfind

float radius = chf("radius");
int points = chi("points");
i[]@neighs = pcfind(0, "P", @P, radius, points)[1:];

И итеративно расталкиваем точки используя pscale и дистанцию между ближайшими точками.
Аттрибут pscale в OpenCL SOP можно установить дефолтным по-умолчанию как 1.0 и ещё опциональным, на тот случай если аттрибута pscale например не существовало на геометрии, это позволяет избежать ошибки которая сделает код неработоспособным.

#bind point neighs int[]
#bind point &P float3
#bind point pscale? float val=1.0

#define TIME 24.0

@KERNEL
{
    float step = 1 / TIME;
    float dist = 0.f;
    float3 dir = (float3)0.f;
    float3 curr_pos = (float3)0.f;
    
    float scale = @pscale;
    float3 pos = @P;
    
    for(size_t idx = 0; idx < @neighs.entries; ++idx){
        size_t nidx = @neighs.comp(idx);
        curr_pos = @P(nidx);
        dist = distance(curr_pos, pos);
        
        if (dist <= scale){
            float offset = dist - scale;
            dir = curr_pos - pos;
            dir *= offset * step;
            pos += dir;
        }
    }
    @P.set(pos);
}

Всё просто как нарисовать сову в 2 этапа, но работает очень быстро по сравнению с VEX реализацией которую придётся запихнуть в SOP Solver или ForEach.
Мне достаточно часто приходилось применять этот сетап в том числе и с краудами чтобы избегать столкновений между агентами во время симуляций.

#rust #rendering #raytracing #sansara #rnd #github

Пишем многопоточный рэйтрейсер с блэкджеком и сферами за выходные 2 недели. (Но говорят, что можно за выходные 😢).

Есть такое упражнение - хочешь понять как работает твой язык напиши на нём рэйтрейсер. Пишем на мэйнстримовом Rust используя популярную книгу и наработки для такого: https://raytracing.github.io/books/RayTracingInOneWeekend.html

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

Исходный код проекта для погружения в детали:
https://github.com/alexwheezy/ray-tracing-in-one-weekend

#houdini #whatsnew #todayilearned #content #vexpressionmenu

Этот простой fix позволяет вернуть создание параметров в AttribWrangle ниже окна сниппетов в H20, а не выше как происходит сейчас.

Более формально, настройки хранятся в файле vexpressionmenu.py которые можно локально заоверрайдить у пользователя положив этот файл к себе в домашнюю директорию с настройками ~/houdini20.0/python3.10libs. так же изменил права доступа у файла c read-only на read + write only поскольку файл находился в системной директории Houdini.

#houdini #lifeblood #renderfarm #sim #wedging #pipeline

Продолжаем эксперименты с таск-менеджером Lifeblood.

Lifeblood так же позволяет создавать Wedge-сетапы для задач связанных с получением различных вариантов.

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

https://help.autodesk.com/cloudhelp/ENU/AR-Core/images/ac-rn-7310-robotIPR_optixDenoising.gif

#houdini #arnold #rendering #htoa

HtoA 7.3.0.0 и 7.3.1.0 - Arnold for Houdini

Вышло очередное обновление HtoA.
Из наиболее ярких обновлений релиза:

- Прогрессивная выборка с затуханием: Arnold теперь поддерживает сэмплы с затуханием при прогрессивном и адаптивном рендеринге. Сглаживание обеспечивает более приятное распределение шума при низком количестве сэмплов AA.

- Улучшена поддержка MaterialX: Arnold теперь может отображать графы узлов MaterialX, смешивая узлы Arnold с узлами стандартной библиотеки MaterialX. DCC, загружающие определения узлов Arnold, получают преимущества от недавно добавленных метаданных пользовательского интерфейса и обеспечивают лучший пользовательский опыт. Arnold также теперь использует MaterialX 1.38.8. Это обновление привнесло новые узлы в стандартную библиотеку MaterialX, полный список изменений приведен в полном описании выпуска.

- Обновлён Intel Open Image Denoise (OIDN) до версии 2.2.2: Обновленный денойзер на 10 % производительнее на CPU, содержит ряд критических исправлений и лучше обрабатывает высокочастотные детали.
Денойзер OptiX теперь выполняет денойз на прогрессивных, негативных проходах низкого разрешения (рендеры с AA < 0). Это должно привести к повышению качества обратной связи в IPR.

Более полный список исправлений и улучшений:
https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_core_7300_html
https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_core_7310_html

#houdini #vex #quiz

Do I know VEX Language?

Субботний квиз. Мы в VEXpression на Detail написали такой код. Корректен ли данный код и будет ли он работать?

#define false 0
#define true 1
void main(){
    int a = 4;
    while(a --> false){
        printf("v:%d\n", a);
    }
}
main();

Ответы:
1) Compile Error
2) Runtime Error
3) 4,3,2,1
4) 3,2,1,0
5) Infinite loop (блокировка интерфейса)

Правильный ответ: 4

Это не причудливый оператор стрелочка в VEX и даже не С, это просто 2 операции подряд "склеенные" в одну такие как операция пост-декремента и знака больше.
Т.е можно было бы написать (a-- > 0) и это тоже самое.
В каждой итерации цикла будем отнимать значение и проверять на равенство в нулём и так до тех пор пока равенство не станет соблюдаться.

#houdini #todayilearned #top #pdg #content

How does TOP/PDG work?

1) Houdini с графом PDG и нодами TOP должен запустить один инстанс Houdini, который открывает сцену и готовит граф PDG. Houdini в процессе создает множество файлов с информацией о выполнении каждой задачи. Каждая нода содержит список задач, которые должны быть выполнены. Задачи одной ноды могут зависеть от некоторых или всех задач родительской ноды.

2) Планировщик (Scheduler) отвечает за запуск сервера PDG и распределение самих задач.
а) Локальный планировщик. Задачи выполняются локально используя доступные ресурсы, планировщик может перераспределять нагрузки задач используя собственные параметры.
б) Внешний планировщик по отношению к машине отправляет задачи на "удалённую" ферму и получает отчёт через PDG Server.

3) Сервер PDG обеспечивает:
a) связь между Houdini и задачами.
б) связь между задачами в случае, если они связаны (например, разделенная симуляция)
в) веб-сервер для получения информации о состоянии задачи.

И это всё. 🙂

#pixar #renderman #release #rendering

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

- Усовершенствования XPU: XPU получил значительные обновления, улучшенную поддержку освещенения, управление камерой и возможности адаптивной выборки, что привело к ускорению рендера и повышению интерактивности.

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

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

https://vimeo.com/930406276

#houdini #challenge #jams #tech

Подведены наконец-то итоги затянувшегося Tech Art Challenge стартовавшего ещё в прошлом году.

По мне так победителями в категории Best Houdini Utility стали последние 2 инструмента: Find Center Line и AutoFix Intersection поскольку многим часто приходится именно с таким сталкиваться в повседневной работе. Достаточно интересно сделаны и выложены в открытый доступ по правилам конкурса. Первые 2 призовых места спорные на мой взгляд чтобы их рассматривать как лучшие инструменты, но SideFX конечно виднее.

В категории Best Game Art Asset: ассет Trebushet с крутой физикой. Выглядит классно.

https://www.sidefx.com/community-main-menu/contests-jams/h20-tech-art-challenge

#houdini #vex #quiz

Do I know VEX Language?

Субботний квиз. Что должен будет вывести этот код?

int x = 3;
int y = 1;

if(x == 0)
    if(y == 0) printf("%d\n", y + 1);
else {
    int z = y + 2;
    printf("%d\n", x);
}

Ответы:
1) 1
2) 2
3) 3
4) Ничего

Правильный ответ: 4

При таком положении вещей у нас этот код никогда не выполняется. Дело в том, что else тут относится относится не к внешнему, согласованному оператору if, а к внутреннему оператору if и следующий кусок кода можно переписать эквивалентно

if(x == 0) {
if(y == 0) printf("%d\n", y + 1);
else {
int z = y + 2;
printf("%d\n", x);
}
}

Так становится более наглядно почему важно соблюдать синтаксическую особенность языка. Чтобы этот пример стал работать ожидаемым образом нужно всего лишь правильно переписать пример

if(x == 0) {
if(y == 0) printf("%d\n", y + 1);
} else {
int z = y + 2;
printf("%d\n", x);
}

#houdini #content #research #undefined

Unsafe integer overflow!!!

На исследование этого вопроса меня "вдохновила" недавняя тема на форуме от создателя Modeler в Houdini где он мягко говоря прошёлся по разработчикам и высказал своё недовольство, что новый билд H20 стал не лучше, а даже хуже по сравнению с H19.5.
Вот этот пост https://www.sidefx.com/forum/topic/95458

Мне стало интересно посмотреть на это глазами не просто пользователя который ловит баги от случая к случаю, случайно, а как тестировщик такой сложной системы который будет делать то, что вообще кажется иррациональным и контр-интуитивным в обычной работе. Справедливости ради все найденные баги есть и в H19.5.

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

#houdini #axiom #content #freeware #hip

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

https://www.doublejumpacademy.com/community-files

#houdini #hnoscript #code #noscripts #env

Variable modifiers

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

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

Чтобы изменить значение переменной, добавьте :code в конец имени переменной.

Мы будет смотреть на поведение модификаторов используя переменную $HIPFILE которая возвращает полный путь до сцены: /tmp/houdini_temp/example_v001.hip

Нам доступны следующие коды:

Head :h (Часть пути в имени пути (то есть путь до имени файла)
$HIPFILE:h == /tmp/houdini_temp

Tail :t (Только часть имени файла в имени пути)
$HIPFILE:t == example_v001.hip

Extension :e (Расширение в конце имени файла)
$HIPFILE:e == hip

Root :r (Все части имени пути, кроме расширения)
$HIPFILE:r == /tmp/houdini_temp/example_v001

Search :s/ptrn/repl (Заменить вхождения шаблона ptrn на repl)
$HIPFILE:s/v001/v002 == /tmp/houdini_temp/example_v002.hip

Upper :u (Преобразование первого символа в верхний регистр)
$HIPFILE:u == /Tmp/houdini_temp/example_v001.hip

Lower :l (Преобразование первого символа в нижний регистр)
$HIPFILE:l == /tmp/houdini_temp/example_v001.hip

Так же мы можем изменять поведение самих модификаторов кодов:

Global :g (Рассматривайте строку как список строк, разграниченных пробелами, и применяйте следующий код к каждому компоненту независимо)

All :a (Рекурсивно примените следующий код столько раз, сколько возможно)

Больше примеров:

A = "foo1 foo2 foo3 foofoo4"

$A:u == "Foo1 foo2 foo3 foofoo4"
$A:u:u == "FOo1 foo2 foo3 foofoo4"
$A:gu == "Foo1 Foo2 Foo3 Foofoo4"
$A:gu:u == "FOo1 Foo2 Foo3 Foofoo4"
$A:au == "FOO1 FOO2 FOO3 FOOFOO4"
$A:al == "foo1 foo2 foo3 foofoo4"

$A:s/foo/bar/ == "bar1 foo2 foo3 foofoo4"
$A:s/foo/bar/:s/foo/bar/ == "bar1 bar2 foo3 foofoo4"
$A:gs/foo/bar/ == "bar1 bar2 bar3 barfoo4"
$A:as/foo/bar/ == "bar1 bar2 bar3 barbar4"

К чему это я всё, некоторые вещи удобнее сделать HScript чем Питоном 🙂