#houdini #developers #forum #content #users

В преддверии H20.5 Keynote решил сделать пост о людях.

Эти люди в большинстве своём не выступают на официальных презентациях новых релизов, (не) записывают мастер-классы, некоторые ведут свои блоги, но с радостью или несчастьем постараются ответить на ваши вопросы. Наш бэкэнд в H - это разработчики.
Их часто можно встретить на официальном форуме среди других юзеров и зная это я использовал их профиля как стартовую точку для поиска ответов.
Было бы конечно классно иметь дискорд с dev team напрямую как это есть у некоторых языков программирования, но это мечты конечно.

Зачем нужны профиля когда есть уже сгруппированные темы по категориям? 😐

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

APEX/Rigging:

- Esther Trilsch впервые презентовала новый фрэймворк для оценки графов APEX в H20.0. Очень охотно помогает и идёт на контакт.
- edward девелопер с богатым опытом в очень разных аспектах H, отвечать может почти везде и на любой вопрос.

Crowd:

- Cameron White достаточно плотно работает с краудами

Technical Discussion (HDK/HEngine):

- Seelan Vamatheva часто отвечает по вопросам коннекта с Unity так и по TOP контексту
- edward алсо помогает и в вопросах HDK, Unity, Unreal
- Jeff Lait не побоюсь этого слова, "отец" микросолверов в DOP контексте, автор For Loop, Compiled Blocks, Grains, Heighfield, OpenCL в SOP и конечно Vellum🔥
- John Mather в основном отвечает на вопросы связанные с коннекторами между H и другими приложениями, но часто помогает и с HDK

LOP/Karma/Solaris/MaterialX:

- Mark Tucker пишет очень развёрнутые и полезные ответы о том как работает USD в Solaris. Наверное один из лучших источников информации дальше хелпа, что я читал. 🔥
- rafal в основном много консультировал по вопросам интеграции и развития MaterialX в Karma.
- brians я подозреваю, что участвует в разработке самого ядра Karma, помойму он выступал с докладом как раз на прошлом ивенте
- Rob Pieké один из ведущих девелоперов Solaris, бывало незамедлительно создавал тикеты на баги прямо на форуме без формальностей в виде подробного общения с суппортом
- malexander в основном вопросы взаимодействия Vulkan, OpenGL в Solaris
- edward
- Cameron White вопросы интеграции краудов в Solaris
- Chris Rydalch переключился на Solaris. Ответы максимально подробные и полезные🔥.

Technical Discussion (VEX/OpenCL/Math):

- Jeff Lait написал довольно много интересных пояснений по поводу того как и что работает в H на самом глубоком уровне

Technical Discussion (General/OpenGL/Vulkan):

- malexander здесь на канале делал выдержки из его постов о новом вьюпорте на Vulkan появившемся в H20
- edward

Technical Discussion (General/Feather/Shading):

- Kai Stavginski достаточно известная личность. В H16 показал как создание шейдеров было перенесено в новый единый Material контекст. Сейчас активно развивает тему перьев.
- Chris Rydalch тоже своего рода "легенда" уже, помню его за серию уроков в H16: как заинстансить лайты в Mantra, как использовать IFD Workflow, как настроить HQueue под линуксом и т.д.

General:

- Robert Magee старший менеджер по маркетингу продуктов, просто приятный человек готовый помочь разобраться в "почти" любых вопросах
- Jeff Lait
- edward
- malexander

PDG/TOPs:

- Brooke Amaranth
- Seelan Vamatheva
- Taylor Petrick пишет очень ёмкие ответы решающие проблему, часто даже с кодом решения или подсказками
- Chris Grebeldinger как и предыдущий девелопер пишет ёмкие ответы с ссылками на доку

Muscle/Tissue:

- Liesbeth Levick новый девелопер в команде по вопросам мышц, тканей, мускулов.

Надеюсь, вы найдёте их ответы полезными и для себя.

#houdini #python #noscripts #tools #hotkey #savetime

Переиспользуем стандартную библиотеку и пишем фокус на дисплэй ноде на изи. Это удобно бывает когда открываешь большой проект и селект ноды оказывается не на диплэй ноде, а так же если нужно часто держать фокус нетворка в этой области, это работает хорошо в связке со стандартным букмаркингом. Работает это там где это имеет смысл, а именно там где можно однозначно определить этот флаг: SOP, LOP, TOP.

import hou
import nodegraphview

def focusDispayNode():
    editors = [pane for pane in hou.ui.paneTabs() \
    if isinstance(pane, hou.NetworkEditor) and pane.isCurrentTab()]
    if not editors:
        return None
    for editor in editors:
        pwd = editor.pwd()
        if hasattr(pwd, "displayNode"):
            nodegraphview.frameItems(editor, (pwd.displayNode(),))
        
focusDispayNode()

#houdini #vex #learning #contents

Хей! VEX-патруль на связи. Исправляем ошибки в коде, переизобретаем существующее и учимся.

Пришёл такой вопрос: как соединить точки с рандомными номерами в пространстве по возрастанию координаты Y используя VEX? И вот такой код который делает это некорректно.

// Run Over: Detail
int roots[] = expandpointgroup(0, "roots");
int newTrunkPts[] = {};

for (int i = 0; i < len(roots); i++) {

    vector vb = set(3e+38,3e+38,3e+38);
    vector minV = 0;
    int minID = 0;
    
    for (int j = 0; j < len(roots); j++) {
        vector va = point(0,"P", roots[j]);
        if (va.y < vb.y) { 
            minID = roots[i];
        }
        vb = va;
    }
    append(newTrunkPts, minID);
    removevalue(roots, minID);
}
addprim(geoself(),"polyline", newTrunkPts);

printf("roots: %d\n",newTrunkPts);

#houdini #vex #learning #contents

Наивное решение в 4 ноды: AttribWrangle: id = ptnum, Sort by Y, нодой Add by Group соединяем точки, и другой нодой восстанавливаем нумерацию по id: Sort by Id. Но нам это не интересно, мы хотим одним вранглом. 😢

Очевидно нужна какая-то сортировка. Но какая? В коде выше есть попытка написать что-то очень похожее на Bubble Sort она же пузырьковая сортировка в простонародье, но мы её писать не будем с нуля, хотя можете попробовать она самая простая, а возьмём просто стандартную VEX-функцию sort которая как то это эффективно делает за нас.

function int[] c_argsort(float arr[]){
    if(len(arr) < 1) return {};
    
    int ordering[];
    int size = len(arr);
    resize(ordering, size);
    float coords[] = sort(arr);

    for(int i = 0; i < size; ++i){
        int f = find(arr, coords[i]);
        if(f) ordering[i] = f;
    }
    return ordering;
}

int roots[] = expandpointgroup(0, "roots");
float y_coords[];
int size = len(roots);
resize(y_coords, size);

for(int i = 0; i < size; ++i){
    y_coords[i] = vector(point(0, "P", i)).y;
}

int ordering[] = c_argsort(y_coords);
addprim(geoself(),"polyline", ordering);

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

Итак,
До:
[ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]

После:
[ 0, 1, 3, 2, 6, 8, 7, 5, 4, 10, 9 ]

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

int roots[] = expandpointgroup(0, "roots");
float y_coords[];
int size = len(roots);
resize(y_coords, size);

for(int i = 0; i < size; ++i){
    y_coords[i] = vector(point(0, "P", i)).y;
}
int ordering[] = argsort(y_coords);
addprim(geoself(),"polyline", ordering);

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

Всем шашлыков!

#houdini #release #mpm #contents

На реддите активно обсуждают, что представляет из себя новый солвер. Один из пользователей знает что-то больше об этом чем просто название MPM. Интересные мысли были и относительно того почему в презентации MPM выглядел не очень в деформациях и при разрушении здание.
Это небольшая выдержка. Его полные, интересный ответы можно прочитать в посте.

"MPM - это своего рода гибридный солвер. Он был создан как расширение FLIP solver'а. В то время как FLIP очень хорошо справляется с поведением жидкостей, не допуская divergence free. MPM - это скорее универсальное решение, которое намного лучше справляется с растяжением, деформацией и гранулированными моделями, однако оно также может работать с жидкостями.
Теперь с помощью MPM вы можете эффективно взаимодействовать с различными материалами, чего раньше не было, например, с тканью и жидкостью, зерном и текучей средой и т.д.
Кроме того, в некоторых случаях, таких как накопление снега и т.д., MPM может дать гораздо лучшие результаты, чем решения на основе PBD, такие как vellum. Однако одним из недостатков является то, что с MPM вам придется создавать ограничивающие баунды, такие как FLIP или Pyro solver, которые не всегда могут быть очень эффективными с точки зрения памяти."

Короче говоря, он сможет сочетать в себе решения основанные на Лагранжевых и Эйлеровых солверах.

https://www.reddit.com/r/Houdini/comments/1dqfcbk/houdini_205_mpm_what_is_that/

#visualprogramming #crafts #games #killertime #chill

Кому ещё не надоело таскать ноды, связи в VOP'ах или подобных графах?

Craftomation 101 - это игра о самореплицирующихся роботах, которых можно программировать с помощью визуального программирования. Эти роботы, КрафтоМаты, создают (и едят!) ресурсы, нужные для терраформирования замерзшей планеты.

Попробовав чуть-чуть я что-то прям залип. Игра кстати написана (отчасти) на очень простом, скриптованом и прекрасном языке Lua. Впервые я с ним познакомился как ни странно в Katana от The Foundry в качестве основного языка сценариев для взаимодействия с графом, атрибутами и много позже начал использовать для расширения плагинов в NeoVim и оконном менеджере AwesomeVM.
Lua представляет собой разумный баланс между быстрым временем разработки скриптов над графом сцены и быстрым рантаймом и стабильностью в процессе кукинга сцены. Он отлично подходил для прототипирования.

Выбор Lua был слегка необычным для того времени решением, когда существовал уже наряду с Python и C++, но у всего есть своё предназначение. Базовый синтаксис самого языка можно изучить за 15 минут.
По мне так это было отличное решение. Его достаточно легко освоить чтобы пользоваться везде где есть его интеграция, пишется почти как на питоне, но без табов и других динамических структур данных кроме одной и язык так же с GC. Простой пример,

local function fib(n)
  if n < 2 then
    return n
  end
  return fib(n - 1) + fib(n - 2)
end

local output = output or ""
for i = 1, 15, 1 do
  output = output .. fib(i) .. " "
end

https://luden.io/craftomation/

#chill #killertime

Забыл поставить чекбокс и не знаешь почему твоей сетап не работает? Или без чекбокса и на рендер ушли не те пассы?
Подожди! Не спеши, потренируйся и выработай чекбоксную память!

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

https://onemillioncheckboxes.com/

#houdini #vex #learning #std

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

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

Почему Std библиотека так непопулярна?

По причинам названным ранее, она не задокументирована в справке Houdini поэтому на неё можно выйти только если вы достаточно любопытный пользователь или любите копаться в системных файлах программы.
Другая причина, считается, что Std библиотека это unstable, это значит, что служебный код там может меняться от версии к версии и может сломать Ваш код в один прекрасный день, однако я уже много лет не наблюдал такого и основном эта библиотека стабильная к изменениям.
Там скорее что-то может появиться дополнительно, а не исчезнуть совсем.

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

Код из Std библиотеки очень легко подключать в свои сниппеты. Достаточно знать название заголовочного файла *далее я буду писать вместо слова "заголовочный" слово "хидер" поскольку эти файлы имеют расширение .h и обычно их неформально принято так называть.

Стандартная библиотека насчитывает 78 хидеров (на момент написания этого поста и версии H20.0.571) разных категорий и находится в $HFS/houdini/vex/include и решает по сути маленькие задачи. Это говорит о том что многое может вам никогда вообще не понадобится, но тем не менее это ещё один источник информации о том как можно стандартизировать свой код.

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

Обычно это выглядит вот так просто и незамысловато, главное тут не ошибиться в написании:

#include <agent_util.h>

drawStar({0,0,0});

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

#include <agent_util.h>

void drawStar(vector pos){...}
drawStar({0,0,0});

Ну и конечно если вы пишете свои собственные функции и включаете код из хидеров можете столкнуться с тем, что в хидере уже имеется такое же определение как и в Std и Wrangle вам громко скажет об этом, сообщением вроде: Multiple definitions of function: void drawStar(vector).
Std библиотека не имеет каких-то нэймспэйсов чтобы избежать коллизий с пользовательскими функциями, однако у Labs всё в этом смысле иначе сделано.

На этом долгое вступление думаю закончено и можно плавно переходить к самому содержимому хидеров. Приступим!

#houdini #vex #learning #std

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

Начнём с хидера agent_util.h

 * NAME:    agent_util.h
 */

#ifndef __agent_util__
#define __agent_util__

#include <math.h>

#define M_TAU 6.283185307179586

Он сразу подключает другой общий, зависимый хидер math.h который включает много полезных функций и встречает нас определением числа TAU которое приближённо в 2 раза больше числа PI.

Далее идёт функция drawStar которая красиво несмотря на своё название рисует крест по заданным координатам от нас лишь требуется передать есть начальную позицию.

///
/// Draw a set of axes at a specific point. Useful for debugging in the viewport.
///
void drawStar(vector pos){...}

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

vector getMatrixPosition(matrix m){...}
void setMatrixPosition(matrix m; vector v){...}
void rotate(matrix m; vector4 q; vector p){...}
void rotate(matrix m; vector4 q){...}
void rotateAboutSelf(matrix m; vector4 q){...}

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

///
/// Denoscription: Project a vector onto another.
///
/// Parameters:
///     * v1 - the first vector
///     * v2 - the second vector to project onto
/// 
vector project(const vector v1; const vector v2)
{
    return (dot(v1, v2) / length2(v2)) * v2;
}
float projectedDistance(const vector v1; const vector v2){...}
float perpproject(const vector v1; const vector v2){...}
float angleBetween(vector v1; vector v2){...}

Очень часто я вижу как эти фукции пишут руками из раза в раз и пишут иногда неправильно) Но раз они уже есть почему бы ими не воспользоваться?

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

///
int isDirectionWithinCone(vector conedir; 
                          vector up; 
                          float hozlimitangle; 
                          float vertlimitangle; 
                          vector dir){...}
///
/// Denoscription: Find an intersection along a line. Returns the 
///              primitive number of the intersection, or -1 if there is an error.
int
lineIntersect(const string terrain_input_path; const string terrain_group;
              const vector origin; const vector direction;
              const int bidirectional; vector hitpos)

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

float AGENTcollisionTime(...){...}
vector AGENTinteractionForce(...){...}
void AGENTcomputeChildTransforms(...){...}
vector AGENTtiltBack(...){...}
...

Опять же повторюсь, цель Std переиспользовать существующий код и взаимствовать идеи или куски кода для своих задач, а там есть на что посмотреть.

Для введения пока достаточно. Продолжение следует...

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