#houdini #vex #quiz

Do I know VEX Language?

Есть такая вот конструкция. Внутри if (condition) определяем тернарный оператор. Какой результат мы получим?

int x = 2;
if(x > 1 ? 1, x, int(x = 3), 4, 5, int(1) : x){
    i@x = x;
}

Ответы:
1) Compile Error
2) 1
3) 2
4) 3
5) 4
6) 5

Правильный ответ: 3 (спойлер)

Да, запятая это тоже оператор.

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

a = b, c;
эквивалентно:

(a = b), c;
Еще одним интересным фактом является то, что оператор запятой вводит точку следования.

Это означает, что выражение:
a+b, c(), d

гарантирует, что три его подвыражения (a+b, c() и d) будут вычислены по порядку. Это важно, если они имеют побочные эффекты. Обычно компиляторам разрешается оценивать подвыражения в том порядке, который они считают нужным, например, в вызове функции:

someFunc(arg1, arg2, arg3)
аргументы могут быть вычислены в произвольном порядке.
Обратите внимание, что запятые в вызове функции - это не операторы, а разделители.

#houdini #vex #llvmir #hard #content #hack

Грязно "хакаем" код врангла изменяя произвольно его кэшированную версию 👀

Этот маленький кусок кода на VEX расположенный в правом, верхнем углу вызовет бесконечный цикл и значение x никогда не будет установлено если вы его запустите на Detail на своей платформе. Но как же удалось "обойти" его и прыгнуть сразу на return 1?

#houdini #vex #llvmir #hard #content #hack

Всё дело в том, что VEX перед выполнением использует такую оптимизацию как JIT-компиляция. Код динамически компилируется и выполняется после того как мы во врангле всякий раз изменяем код и подтверждаем свои действия через Enter.

Например,

int a;
a += 1;
Warning 
Using uninitialized variable: a (2,1)

Вы наверное замечали, что иногда AttribWrangle выдаёт предупреждение в первый раз при выполнении и оно могло пропадать после копирования ноды, поскольку уже на этом этапе наш код "закэшировался" и VEX использует его прелоад перед следующим исполнением.

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

define private void @__vex_snippet_snippet() #0 {
__llvm_entry:
  ret void
}

Что такое LLVM IR?
Его в какой-то мере можно сравнить с USD от мира CG который требуется реализовать DCC-приложениям для совместного использования, но запускаться он может на различных платформах.

LLVM's IR довольно низкоуровневый, он не может содержать языковые особенности, присутствующие в одних языках, но не присутствующие в других (например, классы присутствуют в C++, но не в C). Если вы раньше сталкивались с наборами инструкций, то LLVM IR - это набор инструкций RISC.

LLVM занимает промежуточное место в компиляторе, после того как мы рассахарили особенности языка, но до бэкендов исполняющие код ориентированных на конкретные архитектуры машин (x86, ARM и т. д.).

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

Чтобы долго не растягивать повествование посмотрим на кусок кода VEX более детально:

int foo(){
    for(;;);
    return 1;
}
int x = foo();
i@x = x;

и его представление на LLVM IR, где нас ничего не интересует кроме цикла:

cond:
  br label %cond

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

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

Поэтому если мы скипнем весь цикл и просто вернём какой-то результат, то мы автоматически выйдем из этой "обёртки" и пройдём на следующую инструкцию, но код в AttribWrangle после открытия Гудини будет выглядеть всё ещё полностью нерабочий.

; Function Attrs: alwaysinline nounwind
define private i64 @"foo@I"() #0 {
__llvm_entry:
; foo(;)
;  br label %cond
;
;cond:
;  br label %cond
  ret i64 0
}

Прелоад берётся из кэша, но стоит нам изменить какую-то переменную в коде врангла как тут же будет создан новый кэш по-новому адресу, а этот станет неиспользуемым. Гудини генерит в директории /tmp/houdini_temp структуру VEX_CodeCache куда складывает метадату и сам код.

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

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

#houdini #usd #pixar #freecontent

"da Vinci’s Workshop" был создан в качестве примера использования OpenUSD в процессе производства, подобном кинематографическому. Датасет "Мастерская да Винчи" включает в себя отдельные 3D ассеты, которые придерживаются последовательной, четко определенной структуры. Датасет также включает структуры Sequence и Shot, которые используют OpenUSD для обеспечения эффективного, неразрушающего, совместного рабочего процесса для работы. Вес архива 67 ГБ.
Полезный материал для изучения.

https://docs.omniverse.nvidia.com/usd/latest/usd_content_samples/davinci_workshop.html?ncid=so-yout-334888

#houdini #math #cpp #rnd #blog

Очень интересный блог посвящённый реализации математических алгоритмов, концепций по technical papers в Houdini.
Автор конечно больше математик чем артист и по ходу повествования блога видно, что он не особо вдаётся в детали как это было реализовано оставляя только ссылки на соответветствующие технические документы предлагая самостоятельно их изучить, но всё равно в некоторых постах можно найти ссылки на hip файлами, но к сожалению из-за срока давности ссылки все умерли, а обновлять никто не спешит. Да и к тому же сейчас некоторые из них уже есть, но насколько же он опередил время их появления.

По дате его постов видно, что это тот тип разработчиков которым не нужно ждать нового релиза чтобы создавать сложные инструменты. Для них Houdini это просто удобное средство визуализации Proof of Concept чем постоянный рабочий инструмент.

https://houdinigubbins.wordpress.com

У Senior FX TD @ Industrial Light & Magic - Yunus Balci больше известного как animatrix_ в широких кругах кругах и автора курса https://www.pragmatic-vfx.com есть свой ещё канал, где он в кратких шортсах показывает новинки Houdini и интересные детали использования непопулярных и редко используемых VEX функций в наглядной манере, например зачем существует pgfind и где используется?

https://www.youtube.com/@pragmaticvfx/shorts
https://www.youtube.com/shorts/j9-3HJbOv1Q

#gaffer #cycles #rnd #rendering #tests

Решил немного посмотреть на то как устроен тот самый Cycles который используется в Blender для рендера, но не используя Blender, а попробовав испытать его возможности в другом открытом, опенсорсном решении для лайтинга Gaffer.

Самое больное место оказалось это однопоточная, адаптивная тесселяция геометрии перед рендером почти 2.5 минуты прошло перед тем как я увидел первый пиксель. Возможно, что это и в Blender так же, не проверял, но реализация для Gaffer на данный момент такая и это очень печально выглядит.
Использование CPU будет не быстрым для тех кто привык видеть результат рендера "почти сразу".

Стоило отключить "сглаживание" во время рендера это стало заметно по объектам которые теперь выглядят угловато и всё залетало Optix: GPU + CPU показало наиболее близкий к реалтайму результат и возможность приятной, интерактивной настройки освещения, хотя конечно нужно было проводить полноценный тест с текстурами, но мне было лень пересобирать эту огромную сцену и повторять весь шейдинг под Cycles.

Тестовый стенд:
OS: Manjaro 23.1.3 Vulcan
Kernel: x86_64 Linux 6.6.19-1-MANJARO
CPU: AMD Ryzen 9 5950X 16-Core @ 32x 3.4GHz
GPU: NVIDIA GeForce RTX 3070 Ti
RAM: 6689MiB / 128722MiB

https://www.youtube.com/watch?v=4noU3BxehwE

#gaffer #presentation #lighting #imagengine

Gaffer неторопливо набирает массу.

https://vimeo.com/923093356

#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.