Немного про предыдущий пост: я его рендерил в карме, потому что как оказалось редшифт не очень любит рендерить точки в виде сфер, когда их количество слегка превышает 10 тысяч. С кармой у меня весьма скомканный опыт взаимодействия, в результате которого карма виделась мне заметно менее удобной чем рс из-за пары умозаключений.
Первое такое умозаключение - всегда нужен один лишний бейк в сравнении со стандартным пайплайном. Там, где в редшифте вы кэшируете симуляцию и можете спокойно манипулировать атрибутами/самим кэшем, в карме вы вынуждены это бейкать еще раз. Типа, вы закэшили симуляцию на 40 гигов, добавили после кэша одну ноду, кэшите это еще раз в usd, а иначе карма будет делать это сама. Ученикам Родиона советую почаще проверять вес папки Temp и состояние ссд.
Второе такое умозаключение - все нужно бейкать в юсд, что в целом приводит к той же проблеме одного лишнего кэша и еще пары нюансов, связанных со сложностью самого кэширования в юсд и в дальнейшим их чтением в лопе.

Несмотря на то, что они оба в принципе верны, есть пара интересных моментов, которые слабо освещены. Начну со второго: карма действительно ожидает только юсд файлы на рендер, это её нативный формат, как .rs для редшифта или .orbx для октана, но все эти форматы объединяет одна вещь: они описывают и содержат не только чистую геометрию, они также могут содержать и другие форматы, например Alembic. Теоретически, если вы соберёте сцену из 10 алембиков по 10 гигабайт и запечете её в .orbx или .rs, вы получите не 100-гиговый файл, а компактное описание сцены, которое будет в себе содержать только пути к алембикам, которые движок, в свою очередь, может нативно читать. На практике, я, конечно, не уверен что так будет в случае с рс или октаном, но суть такая. С юсд то же самое, и что важно в контексте кармы - сайды прикрутили нативную поддержку стандартного для гудини bgeo формата к карме. Нативная поддержка какого-либо формата движком означает следующее: когда вы подаёте на рендер сцену из DCC - движок начинает её конвертацию в свой нативный формат (буквально берет всю сцену и генерирует из неё новый файл, новую сцену, новую геометрию в другом формате). Если вы подаёте нативный формат - он читается напрямую без конвертации и пересохранения. В случае с кармой это значит, что мы можем создать usd файл, ссылающийся на самый обычный bgeo кэш и без проблем с usd и ститчингом его спокойно рендерить.

С первым умозаключением интереснее, оно привело меня к такой вещи как rendertime procedurals, которые ранее казались чем-то типа невероятно низкоуровнего волшебства непонятного класса. Пробегусь по общим моментам в контексте гудини+кармы.
Давайте начнем с семантики: procedural означает определенную последовательность действий, rendertime значит что она выполняется во время рендера. Как именно выполняется? Буквально так же, как что угодно что вы делаете до рендера, просто после. В гудини есть концепция сохранения нод графа в bgeo файл в виде точек и атрибутов, а в карме есть концепция чтения и выполнения этого нод графа на рендертайме, то есть вы можете сохранить в такой файл набор каких-то нодовых соп-операций и на рендертайме они выполнятся для вашей текущей сцены и начнут рендериться. Если у кого-то есть желание разобраться получше - всегда можно скормить содержимое готовых процедуралов в нейронку и через пару итераций получить свой.
Плохая новость заключается в том, что в целом это всё хоть и полезно на бумаге, на практике, с учетом ограничений и неудобств, почти всегда будет выгоднее, удобнее и быстрее всё-таки воткнуть один лишний кэш, но топик для общего развития весьма занимательный. Единственное полезное применение без негативных сторон, думаю, это просчет v на рендертайме, чтобы не сохранять векторный атрибут для миллионов точек, всё остальное слишком ситуативно.

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