#houdini #opencl #cop #github

Не удивлён, что кому-то пришло в голову сделать это классическое задание по написанию Ray Tracer'a на каком-то ЯП и так уж получилось, что на OpenCL и внутри COP который работает молниеносно.

Однако это хороший пример того чтобы показать, что работать с COP OpenCL не ультра сложно и можно взять какой-то код на C и его распараллелить в кернеле не особо напрягаясь.
Во всём коде от OpenCL специфичного кода это разве, что заведение параметров через bind, различные касты и определения типов в стиле float3,4, а так же приходится оборачивать основной код в KERNEL шаблон (который генерирует общую форму создания kernel функции, глобальных параметров, начальных условий и т.д) и использовать обработку каждого индекса в буфере независимо:

float2 pindex = (float2){ (float)@ixy.x, (float)@ixy.y};
float2 res = (float2){ (float)@res.x, (float)@res.y};

В остальном это классический код на C.

GitHub:
https://github.com/richardcope/cops-ray-tracer

#houdini #gaffer #lifeblood #opensource

Честно говоря, последнее время мне совершенно нечего нового рассказать о Houdini. Sad but true.

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

Поэтому чтобы избежать участи очередного новостного канала-агрегатора который собирает ассеты, ссылки со всего гитхаба, ютуба и т.д., я буду смещать фокус от Houdini в сторону других опенсорсных приложений и проектов которые мне кажутся достойными внимания и да, в том числе среди них будут: Lifeblood, Gaffer, рендер-менеджеры и другие. А где мы ещё посмотрим на Cycles без Blender?

#gaffer #basic #introduction #opensource

Не знал, что у Trixter Film оказывается такой полезный канал и помимо шоурилов, брэйкдаунов они начали выкладывать и образовательный, уникальный контент. Неожиданно 2 дня назад выложили пару свежих ролика по введению в Gaffer.

Что ж, это отличный повод познакомится с программой и понять, а что же предлагают нам опенсорсные решение сейчас и можно ли ими пользоваться.
У Gaffer не так много активных контрибьюторов, а основных разработчиков вроде бы всего 3, но его комьюнити довольно неплохо развивается, а разработчики с радостью внедряют новые фичи и помогают пользователям обуздать новый функционал потому что не всё к чему привыкли пользователи в других DCC приложениях будет справедливо и в Gaffer, как говорится есть свои особенности.

Я Gaffer никогда не использовал полноценно в реальном производстве, изучал исключительно для себя поскольку люблю такое, хотя мысли и попытки были однажды его применить на проекте "Легенда о Коловрате", однако я уже смутно помню детали такого выбора, возможно, что в Houdini мы упёрлись в какое-то мыслимое ограничение которое было уже реализовано там. На тот момент программу версии ~0.25-0.5 нужно было самостоятельно собирать из исходников (для Windows версия программы появилась относительно недавно), она часто падала с ошибками сегментации памяти SegFault и нельзя было нормально трансформить объекты используя хэндлы во вьюпорте, но из года в год это не останавливало смотреть за прогрессом программы. С годами продукт стал и становится намного лучше и стабильнее и очень хорошо, что начинает появляться обучающий материал.

GitHub:
https://github.com/GafferHQ/gaffer

https://youtu.be/qJWtai73TB8?si=zrguJNU7cjRbQEl4
https://youtu.be/aKUMRKPbdZI?si=FaOxWlfB9VmT3XbV

#houdini #python #custom #desktop

Network Context Desktop Mapping

Мне такое было не сложно делать руками, но однако есть люди кто решил, что неплохо было бы автоматизировать смену рабочих столов в зависимости от контекста. Например, если я нахожусь в нетворке SOP, я бы хотел, чтобы Houdini автоматически переключался на рабочий стол A. Если я затем погружаюсь в нетворк COPernicus, я бы хотел, чтобы автоматически происходила смена на рабочий стол B и так далее.

Автор использует хардкод в виде словаря для маппинга:

# network context mapping to desktops
editor_desktop_map: dict = {'Object' : 'Build', 
                            'Sop'    : 'Modeling', 
                            'Vop'    : 'Labs', 
                            'Dop'    : 'Technical', 
                            'CopNet' : 'Image'}

Его нужно будет поднастроить под свои нужды.

#python #whatsnew

TL;DR: в Python разблокировали GIL?

Не про красивые пиксели на экране, но однако не смог мимо этой новости пройти.

Сегодня релизнулся Python 3.13 - это последний стабильный выпуск языка программирования Python, содержащий множество изменений в языке, реализации и стандартной библиотеке. Самые значительные изменения включают новый интерактивный интерпретатор, экспериментальную поддержку работы в свободно-поточном режиме (PEP 703) и компилятор Just-In-Time (PEP 744). Это довольно интересный и значимый релиз.

Пропустим про интерпретатор и остановимся на свободно-поточном режиме. В CPython появилась экспериментальная поддержка работы в свободно-поточном режиме с отключенной глобальной блокировкой интерпретатора (GIL). Это экспериментальная функция, и поэтому она не включена по умолчанию. Для работы в свободно-поточном режиме требуется другой исполняемый файл, обычно называемый python3.13t или python3.13t.exe.

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

А так же JIT. Когда CPython настроен и собран с использованием опции --enable-experimental-jit, добавляется компилятор just-in-time (JIT), который может ускорить работу некоторых Python-программ.

https://docs.python.org/3/whatsnew/3.13.html#whatsnew313-free-threaded-cpython

#houdini #python #noscripts #tools #network

Иногда в проекте требуется узнать все зависимости от текущей ноды: кто на эту ноду ссылается? куда смотрит у этой ноды запасной (spare) вход помимо основных? а если нода использует выражения, а куда у них тянутся ссылки и подключены их входы т.д?

В плане визуализации нам помогает Depedency Links - Show for All Nodes однако это только визуализация и мы не сможем использовать этот же метод из Python API чтобы "потрогать" этот список.

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

GitHub:
https://github.com/alexwheezy/python/tree/master/houdini/dependency_nodes

#lifeblood #renderarm #rnd #pipeline #manager

Гуд ньюс! Lifeblood-Manager получил обновление приближающее его к более практичному использованию для конечного пользователя. Мне никогда особо не нужно было управлять планировщиком и пулом из трэя, но я слышал, что для артиста будет удобнее когда он точно будет знать, что процесс имеет автозапуск и может быть свёрнут в трее.

🤖 Lifeblood-Manager update v0.5.0!

Minimize to tray and Autostart

- Now can stay in tray after closing
- Can Autostart with the system
and additionally start some components,
such as Scheduler and/or Worker Pool
- (windows) Console window is now hidden by default,
But can be shown/hidden with buttons on Launch tab
- Remembers selected installation dir and autostart
configuration into a file next to exe.

Patreon:
https://www.patreon.com/posts/lifeblood-is-now-114356547

GitHub:
https://github.com/pedohorse/lifeblood-manager/releases/tag/v0.5.0

#houdini #epyc #amd

Multi-socket EPYC System can't reach above 50% load

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

Будет ли линейный рост производительности от количества ядер процессора? Всегда ли больше - лучше?
Как оказывается далеко не всегда.

Автор темы столкнулся с тем, что 2х-сокетная система собранная на AMD EPYC 9654 96-Core Processor (суммарно в 192 ядра и 384 потока) c Gentoo Linux под Houdini не смогла быть загружена на все 100% в симуляции, а только на 50% в хайлоаде.

Ответ тех. поддержки в SideFX со слов автора примерно такой:

При 384 потоках вам потребуется довольно большая рабочая нагрузка, прежде чем они смогут насытиться. Возможно, вы даже добьетесь большего прогресса в производительности если запустите меньшее количество потоков с опцией -j, а затем запустите несколько процессов Houdini.
Синхронизация 384 потоков сама по себе занимает время...

Решение такое, что либо запускаем отдельные инстансы Houdini явно или например используем TOP.

Далее они обсуждают работу c AttribWrangle в режиме Number поэтому краткая врезка о том как он используется:
Когда используется Run Over в режиме Numbers то это говорит о числе итераций которые будут выполняться в отдельном потоке. Если это число больше или равно Number count, все итерации будут выполняться последовательно в одном потоке. Если это число равно 1, то каждая итерация будет выполняться в отдельном потоке. В промежутках между итерациями нода будет группировать их в партии этого размера и запускать каждую партию параллельно в отдельных потоках.

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

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

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

#houdini #news #karma #nvidia #render

Пока Россиян отлучили от разработки ядра Linux и Линус Торвальдс заявил, что отмены решения не будет 🤡, а Nvidia лишила доступа к новым драйверам в SideFX так же сломали Карму.

Официальное обращение от Chris McSpurren, Senior Quality Assurance Specialist:

"Привет! Как некоторые из вас обнаружили, существует проблема при обновлении до драйвера Nvidia 565. Если вы уже обновились, откатитесь назад. Если вы еще не обновились до драйвера 565...хорошо.
В настоящее время мы работаем с Nvidia над этой проблемой. Проблема возникает только в том случае, если Karma XPU использует Optix. При работе Karma XPU с Optix может возникнуть ряд проблем, начиная от голубого оттенка подсветки и заканчивая полным отказом устройства из-за сообщения cudaErrorIllegalAddress.

Мы сообщим вам, когда у нас будет больше информации."

upd: В ежедневной сборке 20.5.397 содержится потенциальное обходное решение/исправление этой проблемы с драйвером которое мы сейчас тестируем. Если у вас уже установлен драйвер nvidia 565+, попробуйте 20.5.397 и посмотрите, будет ли он лучше для вас.

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

Как выглядит пайплайн на бумаге 😅

🎬 VES VFX JOBS DESCRIPTION

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

Посмотрите на очень любопытный раздел Levels of expertise in the VFX professions. Там наглядно расписаны уровни художников и продакшена в соответствии с уровнем выполняемой ими работы, независимости, степени ответственности и вовлеченности в организацию процессов/команд/проектов.

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

#gaffer #render #lightning #opensource

Shading & Lighting with Gaffer and Arnold | Level Up Your VFX Game
Introduction to Gaffer and Arnold | Open Source VFX / CGI Basics

Удивлён в хорошем смысле, что Gaffer начали пушить среди CG-блогеров хотя стабильный, последний релиз 1.5.0.1 и не был ознаменован как финал финалов тем не менее люди всё равно начали к нему присматриваться.
Arvid записал уже пару уроков с рендером Arnold о том как начать с ним работать в сцене и разобрать его на паре примеров сам процесс лукдева.

#cgnews #modo #foundry

Modo, всё.

Компания Foundry объявила о своем решении прекратить разработку инструмента для 3D-моделирования Modo после выхода версии Modo 17.1 в конце этого года. Это стратегическое решение позволит Foundry сосредоточиться на своих основных предложениях и инвестировать в новые решения, отвечающие развивающимся потребностям медиа и развлекательного сообщества.

https://www.foundry.com/news-and-awards/foundry-winds-down-modo-development

Кто ещё помнит о Athera от Foundry? Платформа, ранее известная как Elara, предоставляла облачный производственный сервис "все в одном", включая виртуальные рабочие места, аренду программного обеспечения, рендеринг, инструменты для совместной работы и аналитику, но в итоге массово так и не пошло. Проект свернули через 18 месяцев после открытия и полностью закрыли к 2020 году.

https://www.cgchannel.com/2019/11/foundry-closes-athera/

#learning #python #cg #exercism

Отступы - часть кода!

Чёт умильнулся с того как некоторые CG-блогеры изучают Python. Я конечно слышал, что конспектирование материала который читаешь помогает лучше запоминать информацию, однако в программировании крайне важна практика и хорошая IDE, 140 упражнений на ветвление и всё подряд и синтаксис станет вашим вторым языком, что и забыть захочется.

Никогда конспекты по языкам программирования не вёл, даже по системным ЯП, у меня не прижился такой подход, тем более по синтаксису и всегда это были лишь какие-то короткие заметки..
Но может зря?? И рисование котиков на свободных местах реально бустит и помогает в изучении языков? А может это способ чтобы построить ассоциативный ряд в памяти?
Вспоминаю про грустного кота и сразу помню как применять бранч 😅
Каким бы чудесным и весёлым стало изучение ассемблера с таким оформлением, я бы честно говоря посмотрел на арт-бук от этого автора.

#houdini #hdk #github #opensource #fluid #ml

HinaFlow - это дифференцируемый солвер жидкостей и солвер жидкостей на основе глубокого машинного обучения с открытым исходным кодом на Houdini HDK*.

* компилировать надо из исходников под свою платформу и для своей версии Houdini, но это и не сложно.

HinaFlow - это рекурсивный акроним, означающий "HinaFlow is not a Fluid Learning Optimization Workflow".

Ключевые особенности:
HinaFlow работает в двух контекстах: Houdini и Python. В обоих контекстах используются ноды Houdini HDK. (Ноды Python в Houdini отсутствуют).

- При работе в чистом Houdini вы можете использовать HDK HinaFlow в чистом виде как расширенный ассет Houdini. Это ничем не отличается от стандартного рабочего процесса в Houdini.
- При работе в контексте Python вы можете использовать все преимущества всей экосистемы Python, включая PyTorch, TensorFlow, NumPy и т. д., чтобы создать свой собственный конвейер для солвинга.
Оба контекста полностью совместимы друг с другом. Вы можете переключаться между ними в любое время.

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

В Hinaflow в основном используется phiflow в качестве бэкенда для солвинга жидкостей который является полностью дифференцируемым фреймворком с поддержкой PyTorch, JAX и TensorFlow.

https://github.com/HinaPE/HinaFlow

#vex #python #programming

Пост вдохновлённый небольшой статьёй A list of ternary operators о разнообразии тернарных операторов.

В VEX или Python наш тернарный оператор ? : называется тернарным потому что принимает 3 аргумента и право называться так стало монопольным поскольку других операторов такого плана не было, но VEX так же имеет ещё один непопулярный способ записать тернарное выражение и мне кажется он проще.

Посмотрим на простую запись ветвления с помощью if:

int res;
if(10 > 5){
    res = 42;
}else{
    res = 123;
}

Ассемблер (LLVM IR ) у этого куска кода такой:

; Function Attrs: alwaysinline nounwind
define private void @__vex_snippet() #0 {
__llvm_entry:
  %return = call i64 @"gt@III"(i64 10, i64 5)
  %0 = icmp ne i64 %return, 0
  br i1 %0, label %true, label %false

true:
  store i64 42, i64* %_bound_res
  br label %end
false:
  store i64 123, i64* %_bound_res
  br label %end
end:
  ret void
}

Глазам с непривычки может быть тяжело здесь увидеть осмысленный код, но он не сложный.
Здесь мы видим в основном метки, базовые инструкции и вызов call, функция сравнения чисел на больше call i64 @"gt@III"(i64 10, i64 5), а ниже идёт просто выбор бранча в зависимости от результата.

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

int res = 10 > 5 ? 42 : 123;

; Function Attrs: alwaysinline nounwind
define private void @__vex_snippet() #0 {
__llvm_entry:
  %return = call i64 @"gt@III"(i64 10, i64 5)
  %0 = icmp ne i64 %return, 0
  %. = select i1 %0, i64 42, i64 123
  store i64 %., i64* %_bound_res
  ret void
}

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

Быстрее ли этот работает? Возможно, но как обычно всегда нужно делать тесты профилирования на производительность. Удобнее ли это? Однозначно да, особенно когда нужно результат присвоить тут же переменной.

Однако, если покопаться в документации по функциям VEX, а так же коде стандартной библиотеки окажется, что мы так же можем вызывать эту функцию select прямо из сниппета самого Wrangle:

int res = select(10 > 5, 42, 123);

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

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

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

#math #houdini

🔥 Хороший анонс!

Начало положено…

https://boosty.to/nord3d/posts/90857717-a405-4e5a-98d9-6558c4e903c7

#gameengine #opensource #github

Кто хотел потестить какой-то другой движок кроме Unity или UE с плотной поддержкой USD в том числе?
Теперь Nau Engine вышел в бету с открытыми исходниками. И это отличный повод покопаться в структуре кода.

https://habr.com/en/companies/nau_engine/news/861316/

#houdini #apex #rigging

( )
( )\ ) ( /(
)\ (()/(( )\())
((((_)( /(_))\ ((_)\
)\ _ )\(_))((_)__((_)
(_)_\(_) _ \ __\ \/ /
/ _ \ | _/ _| > <
/_/ \_\|_| |___/_/\_\

Matt Estela выложил WIP по APEX на своём ресурсе это взгляд дженералиста на APEX, а не как профессионального сетапщика, но и тем более интересно прочитать про этот взгляд со стороны.
Ресурс пока конечно суховат, но можно прочитать про общие концепции, идеи, более простыми словами для артиста чем документация и не сильно углубляясь в детали чтобы сложилось представление об этом контексте.

https://tokeru.com/cgwiki/HoudiniApex.html

#pipeline #ffmpeg #opensource

Иногда из какого-то шота или видео требуется сделать нарезку для превью через определённое количество кадров чтобы по нему можно было понять всё содержимое от начала до конца.

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

https://steelcm.com/blog/generating-video-sprites-using-ffmpeg/