#houdini #meme

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

#check #github #pipeline #python #cpp #rust

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

Вот с такой на данный момент структурой:

#[derive(Debug)]
#[cfg_attr(feature = "arbitrary", derive(arbitrary::Arbitrary))]
pub struct CheckResult<Item: crate::Item, Items: std::iter::IntoIterator<Item = Item>> {
    status: crate::Status,
    message: String,
    items: Option<Items>,
    can_fix: bool,
    can_skip: bool,
    error: Option<crate::Error>,
    check_duration: std::time::Duration,
    fix_duration: std::time::Duration,
}

Фрэймворк предоставляет простой API с типом результата, который показывает всю информацию чтобы пользователь знал почему проверка не удалась и что ему нужно сделать чтобы исправить проблему. Фрэймворк также поддерживает авто-исправление проблем, если проблема может быть устранена без участия пользователя.

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

https://github.com/scott-wilson/openchecks

#houdini #vellum #rnd #github #opencl #cpp #hard

Возможно кого-то вдохновит этот небольшой плэйлист по созданию Vellum Solver(XPBD) с нуля, но с позиции более "упрощённого" солвера.
Автор с ангельским голосом проведёт вас через бОльшую часть этапов создания от идеи до реализации, но это конечно не подробный обзор каждого атрибута, параметра, значения, поскольку здесь всё таки нужно уловить суть.
⚠️ Это несомненно хард и конечно и не для всех, но такой материал редко можно увидеть в свободном доступе.

https://www.youtube.com/playlist?list=PL9mEiwkYhL1Y55UYIUuRLmwA3re5c7hAy

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

GitHub: https://github.com/Jingzheng-Li/Houdini_Learn_Microsolvers

⚡️На закуску: по страничке видно, что автор так же делал попытки написать свой MPM Solver, который выложен с исходниками на HDK с парой сцен для тестирования.
Может скопилировать и посмотреть? 🙂

#houdini #meme #group #syntax

Немного постиронии. Не смог пройти мимо этого наблюдения, очень часто наблюдал..
Ссылку на доку не оставляю, всё равно не будете читать 😅

#houdini #nextrelease #topic

▄████ ▓█████▄ ▄▄▄▄
██▒ ▀█▒▒██▀ ██▌▓█████▄
▒██░▄▄▄░░██ █▌▒██▒ ▄██
░▓█ ██▓░▓█▄ ▌▒██░█▀
░▒▓███▀▒░▒████▓ ░▓█ ▀█▓
░▒ ▒ ▒▒▓ ▒ ░▒▓███▀▒
░ ░ ░ ▒ ▒ ▒░▒ ░
░ ░ ░ ░ ░ ░ ░ ░
░ ░ ░
░ ░
💥По доброй традиции, ставшей уже классикой в мире H, после каждого минорного и мажорного релиза каким-то случайным юзером форума (раньше и сейчас был OdForce) создаётся новая тема с листом ожиданий от следующего релиза где юзеры могут накидать на вентилятор идей чего бы хотелось видеть уже в следующем релизе.

Обычно большинство пожеланий выглядят так:
- больше GPU вычислений (везде где только можно, SOP, DOP, COP и т.д)
- больше AI, ML в H (больше ассистентов для кода, хочется ML для разного рода симульни с предсказуемым результатом),
- больше понятного и классного UI/UX
- больше современных решений и подходов (кто-то уже там на fVDB замахнулся, а он только был анонсирован недавно...)

Ну вы поняли в общем..

Я бы на данный момент предпочёл всему новому и "свежему" стабильность и качество, что в данный момент видно по последнему релизу когда разработчики выносят новый релиз, но у кода довольно низкое покрытие тестами, что видно в большом количестве багов, поскольку юзеры уже привыкли, что в каждом релизе H будет лучше и больше чем у других. Сами распустили юзеров.🙂

В H ~35 переменных окружения которые должны помогать решить проблему отладки: HOUDINI_*_ASSERT, HOUDINI_*_DEBUG, HOUDINI_*_ERROR, HOUDINI_* (undoc).
Некоторые помогают справиться с некоторыми проблемами, но флагам отладки неподвластны unrecoverable errors такие как Karma Error: Command Exit, Fatal Error (сидеть в обнимку с gdb houdini-bin мало кто захочет) и тому подобные ошибки. Ведь сколько раз мы задавали себе и друг другу этот вопрос, что означает Mantra: Render Error -123456789 ? Очень большая часть вопросов на форуме, группах посвящена только этому, что ознают коды ошибок и что с этим делать?

Поэтому мне кажется, что полезней для юзера было бы часто знать почему не работает та или иная функциональность (хотя справедливости ради на окнах я видел сообщение вида Memory Allocation когда H не хватало памяти).

Мой небольшой список улучшений выглядит вот так:
- More flags for debugging (General, OpenCL, COP, DOP, etc.)
- Redesigned or new error handling system
- Built-in system for sending error reports
- Reworked HDK documentation
- Documentation of VEX, OpenCL, OSL, etc. code (which is connected by #include directives in snippets)
- Ability to save more settings in configuration files, as well as use the Python API for this

Загадываю желание, что в H23 это всё будет!

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

#houdini #cop #opencl

Hello, COPernicus!

И как не посмотреть на этот новый COP контекст в H20.5, о котором уже слышал достаточно отзывов, что сыро, баговано и работает криво. Надо посмотреть!
Поэтому решил сразу проверить его каноничным примером после Hello,World! это генерацией множества Мандельброта на OpenCL.

Я честно говоря ожидал, что этот пример будет идти из коробки для разного рода тестов, но там был другой эстетический фрактал Julia неразрывно связанный с множеством Мандельброта.
Поэтому быстро сделаем его сами, пока игрался с подбором параметров резко и неожиданно словил багу, что Tile Size у OpenCL лучше не устанавливать отрицательным значением иначе H уходит в бесконечный цикл , я это сделал случайно когда у Ladder Slider сдвинул параметр мышкой не туда 🙂

Кому захочется поиграться или добавить в свои пресеты рецепы, вот исходный код (который уже не поместится в это сообщение):
https://pastebin.com/8UmqJEkk
(у параметра dst нужно изменить тип с Varying на RGBA для красивой отрисовки цветов)

#houdini #vex #hda #std #todayilearned

Не особо популярные возможности использования AttribWrangle взятые из стандартной библиотеки SideFX HDA которые можно так же использовать в своей работе или хотя бы взять на заметку. Картинки пронумерованы поэтому пойдём по пунктам:

TD;LR:

1. Чтение данных из второго входа и запись в атрибут Detail выходной геометрии.
2. Вычисление результатов на месте без создания промежуточной копии геометрии.
3. Создавайте атрибуты только в том случае, если их имена соответствуют шаблону.
4. Обработка ошибок на VEX, так же и в графе.
5. Референс снипетов кода в другие снипеты.

А теперь подробно:

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

for(int i = 0; i < nprimitives(0); ++i)
    addpoint(0, vector(prim(0, "P", i)));

for(int i = 0; i < nprimitives(0); ++i)
    removeprim(0, i, 1);

можно будет просто написать

for(int i = 0; i < nprimitives(1); ++i)
    addpoint(0, vector(prim(1, "P", i)));

Добавили чуть оптимизации и меньше написали!

2. Compute In Place. При компиляции Attribute VOP может работать с входящей геометрией на месте, не создавая ее копию. Это может ускорить обработку, так как создается на одну копию меньше, но требует, чтобы код VEX не связывал для записи любые атрибуты, которые считываются из первого входа.
Вы можете записывать в любые атрибуты, только НЕ в те, из которых вы читаете, так как он не создаст копию геометрии, поэтому не сможет прочитать оригинальные значения, если они будут перезаписаны.
При попытка сделать запись вида @P = point(0, "P", @ptnum); будет выброшена ошибка вида Error: Attempt to read from actively streamed attribute P.

Эта особенность так же активно эксплуатируется во всей библиотеки там где можно и не нужно. И наибольшую выгоду от использования можно почувствовать если использовать её именно в блоке компиляции на большом количестве геометрии (>10 лямов). Некоторые люди отмечали внушительный 3-4х кратный прирост при обработке, но в других сценариях польза может быть более изотерична и не так выражена.

Здесь вопрос оптимизации отрытый и более тонкий (много где включено по-умолчанию в ассетах).

3. Шаблон по умолчанию позволяет создать любой атрибут. Вы можете ограничить создаваемые атрибуты, заменив * на список разрешенных имен.
Стандартная библиотека смотрит это как на своего рода иммутабельность атрибутов, те которые явно экспортируются те и используются, все остальные только для чтения. Это предотвращает ситуации когда вы случайно хотите поменять значение в атрибуте который менять нежелательно. В таком случае компилятор скажет: Error: Read-only expression on left side of assignment (1)).

4. Обработка ошибок в VEX 💣 представлена разными функциями: warning,error. error cообщает о пользовательском предупреждении VEX во время выполнения. При этом используется тот же синтаксис строки формата, что и в printf. Так же нередко используется и одноимённая нода Error которая так же может полезна когда вы хотите дать обратную связь сразу если входные данные невалидны со своим сообщением. Приятней видеть всё таки понятные ошибки вида: Ты не видишь бл*ть!? Атрибута нет! вместо id not found.
(На этом скрине так же видно, что автор вообще не экспортирует никакие атрибуты явно показывая, что тут не происходит создания новых атрибутов, поэтому параметр Attributes to Create пуст)

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

На этом пока всё 🙂

https://imgur.com/a/fTRUtbq

#houdin #apex #cop #whatsnew #release

APEX isn't JUST for rigging!!!

Да, начиная с H20.5 в APEX можно теперь собирать дебажить COP граф. Что можно с этим сделать в APEX?

Пока немного, COP может генерировать граф APEX, который был скомпилирован и выводит его в виде геометрии, а не как результат целенаправленной обработки COP во вьюере.
Это в основном для отладки или эзотерического использования, например для генерации slap-comp-файлов формата bgeo или bgeo.sc, простыми словами, возможность применять одинаковый пре-комп к разными USD файлам.

Например, husk --slap-comp geo/defocus.bgeo geo/test.usdnc, а не копировать из сцены slap-comp каждый раз в новую сцену. Этот параметр может встречаться несколько раз, и каждая операция выполняется последовательно.
Это так же может быть запущенно непосредственно с ROP ноды в Solaris.

Нооо, поскольку COP это бета, всё чего я добился это:

55225: Fatal error: Segmentation fault (sent by pid 0)
-- TRACEBACK BEGIN --
...
-- TRACEBACK END --

Видимо надо подождать ещё 🙂

#asfw #materialx #openpbr

MaterialX Virtual Town Hall 2024

Про новый стандарт OpenPBR Surface и релиз MateriaX 1.39 с тайм-кодами.

Если коротко то референсная имплементация есть уже в MaterialX 1.39, в Adobe Substance тюнится, Arnold (3ds Max, Maya, Katana), Omniverse уже есть, в Houdini будет в следующем релизе.

- Intro

New Features:
- Energy-preserving Oren-Nayar
- New fuzz model
- Coat darkening
- Dispersion scale
- More expenssive layer ordering
- Art-directable metal model
- Other user-friendly tweaks

- Future Work

MaterialX Updated:
- Pixar (OpenUSD & Hydra)
- Omniverse
- LookdevX in Maya
- V-Ray
- Houdini

Вообще на их канале вышло много свежего видео про разные опенсорсные разработки (видеоплееры, рендер-менеджер, форматы изображений).

Это. Просто. Интересно.

#houdini #meme

Здесь нечего пояснять 🤡

#houdini #todayilearned #hnoscript #path

Пишем рендер на один уровень выше относительно HIP файла. А если бы надо было на два уровня выше? 👀

#houdin #event #sidefx

Adventures in MPM-land: the Fine Art of Balancing Numbers
Mastering the Elements: The New MPM Solver

Возможно наконец-то что-то в этих докладах расскажут про MPM солвер и приоткроют завесу "как правильно его готовить? и что там с дестаркшеном, пацаны? как деформить RBD?"

Так же интересно будет глянуть доклад From Bodies to Branches, Unconventional Instancing on FX's Shōgun от непревзойдённых мастеров качественного графона - ILP. Брэйкдаун по этому проекту был крутой.

А так же этот доклад Solving Plants in Houdini, описание звучит достаточно интересно.

Используя OpenCL для ускорения GPU, наша система построена на архитектуре APEX в Houdini, которая поддерживает частичную и отложенную оценку, обеспечивая быструю интерактивную обратную связь. Это позволяет художникам создавать сложную, натуралистичную растительность с беспрецедентным контролем и скоростью.

https://www.sidefx.com/houdini-hive/hive-horizon-2024/

#houdini #forum

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

Жаль, теперь и тикет не найдёшь чтобы в поддержку можно было обратиться по похожей проблеме. В одиночку будешь бороться со своими проблемами и поддержкой отвечая на базовые вопросы: "а вы пробовали переустановить драйвера видеокарты" или "попробуйте забэкапить пользовательскую директорию houdiniX.Y". "Извините, я не могу воспроизвести эту проблему."

Лучшее, что могу посоветовать при обращении в поддержку это делайте запись экрана через OBS своих действий даже если видео длится больше 5 минут и в идеале на ванильном H. Как показала практика это намного эффективнее чем переписка. Единственное исключение если ваша сцена 100% падает при открытии с сегфолтом то её можно без видео отправить.

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

#houdini #meme #solaris

У Solaris есть своя изюминка 🙂

#houdini #cop #taichi #julia #opencl

Сегодня на форуме обсуждали такой вопрос: какая могла бы быть возможная альтернатива другому языку в COP вместо OpenCL?
Поскольку многие отмечали, что OpenCL сложный и небезопасный язык для использования художниками.

"На данный момент в новом COP (Copernicus) есть два языка программирования для пользовательской логики. Первый - это старый надежный VEX, но он не работает на GPU. Другими словами, если вы используете VEX в COPernicus, вы, по сути, понижаете его производительность до уровня старого COP2. В некоторых случаях это нормально, но если текстура имеет размер 4k или больше, то бог с вами."

Сам автор трэда предложил такой язык как Taichi. Taichi Lang - это императивный язык параллельного программирования с открытым исходным кодом для высокопроизводительных численных вычислений на CPU или GPU. Ссылка не него в конце поста.

Но другой пользователь вспомнил про такой язык как Julia.
"Я думаю, что Julia - лучший язык программирования на данный момент, поскольку он настолько близок к математике, что хорошо работает с LLM потому что в нем не так много технической многословности. Это JIT-компилируемый язык с API на языке C. "

Возможно это тоже о чём-то мало скажет. Но тут я вспомнил, что уже видел одно воплощение Julia в Houdini наравне с VEX в виде сниппета которое работает с геометрией в SOP.

Легче ли на нём писать для артиста? Мне показалось, что нет 🙂 Нужна ещё одна абстракция над этим языком. 😜

https://github.com/pedohorse/yuria
Думаю, что оно даже под H20.5 соберётся сейчас.

И следом идёт показательная статья о том какую производительность показывает Julia в H по сравнению с VEX и удобно ли на нём было бы писать. Хотя бы интересно изучить.

https://www.patreon.com/posts/julia-61740179

Taichi:
https://github.com/taichi-dev/taichi