Опубликована книга «Programming Add-Ons for Blender 2.8»

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

человек совсем не понимает что за бред несет. ты вообще представляешь какя информация в .blend-файле и каких размеров он может быть?

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

лять, ну назачем*?

Для тех кто в танке: перевод на другой язык, это тоже «Derivative».

Добавил в текст новости информацию для желающих занятся переводом книги на русский (или другой) язык ;-)

анонимус-3д-гуру в треде
https://www.sidefx.com/docs/houdini/io/formats/sdl_formats.html
https://www.sidefx.com/docs/houdini/io/formats/geometry_formats.html

json они использовали только в 12-й версии, на дворе уже 17-я. явно тоже наслушались анонимусов и решили проверить, но что-то пошло не так

Кайф! Вообще новый уровень! Типа клеит танчики но не клей ни танчики ему вообще не нужны, он просто щекочет питона в блендере!

анонимус-3д-гуру в треде
https://www.sidefx.com/docs/houdini/io/formats/sdl_formats.html
https://www.sidefx.com/docs/houdini/io/formats/geometry_formats.html

json они использовали только в 12-й версии, на дворе уже 17-я. явно тоже наслушались анонимусов и решили проверить, но что-то пошло не так

daminatorus ★ (22.07.19 19:06:12)

Рекомендую не бросаться на оппонента с шашкой наголо, не узнав, сколько у того дивизий. А то как окажется, что он использует Houdini с версии 5, да на серьезных ААА проектах, да знает API, да общается с разработчиками, причем и по поводу особенностей JSON в bgeo ;p Первый линк на форматы описания сцен Mantra и Renderman, не знаю, к чему (особенно учитывая, что Mantra спокойно себе читает геометрию в формате geo / bgeo). Второй линк - описание т.н. формата classic, который использовался в Houdini до версии < 12, после чего перешел в статус «deprecated» и используется исключительно там, где нужна совместимость со старым форматом (либо нужны Houdini / Mantra <= 11, либо есть зависимость от GPD). geo / bgeo >= 12 все на JSON. И да, на дворе 17.5, а у некоторых и 18.0, в котором JSON все еще никуда не делся.

ну ок, я действительно не особо знаком с Houdini. Но раз ты утверждаешь что знаешь API и вообще в теме, ну и что бы не быть голословным, давай сделаем так, поскольку беглый поиск в гугле не дал результатов и я не нашел файлов проектов, ты пришлешь рандомный, любой проект в json формате используемом в 18.0, который содержит в себе >= 1 млн полигонов, материалы, текстуры и анимацию. И мы все вместе посмотрим на что способен json. Договорились? мне самому интересно как это реализовано

Извините, я если честно не понимаю чем по-вашему жсон отличается от любого другого формата бинарного или текстового, разве что часть данных может чуть менее эффективно храниться из-за ограничений. Сколько там оверхэд у base64 выходит? Около 1%? Да, так и есть.

ты пришлешь рандомный, любой проект в json формате используемом в 18.0, который содержит в себе >= 1 млн полигонов, материалы, текстуры и анимацию. И мы все вместе посмотрим на что способен json. Договорились? мне самому интересно как это реализовано

Я же говорил только о geo / bgeo, файлы проектов в Houdini в другом формате, обычно они легкие, несколько мегабайт/десятков мегабайт. А та самая геометрия измеряется уже гигабайтами. Если интересно самому, как это устроено, можешь либо создать геометрию в Houdini, либо скачать геометрию в PLY (какой-нибудь тяжёлый скан, коих в инете хватает), либо какой-нибудь Alembic или OBJ и записать её из Houdini в foo.geo (текстовый), foo.bgeo (бинарный). Если в конце добавить .hclassic, получится старый неJSON.

Извините, я если честно не понимаю чем по-вашему жсон отличается от любого другого формата бинарного или текстового, разве что часть данных может чуть менее эффективно храниться из-за ограничений. Сколько там оверхэд у base64 выходит? Около 1%? Да, так и есть.

Я не интересовался, почему выбрали JSON для геометрии, но самое простое, что приходит в голову, так это уже готовая неплохая база для формата плюс куча готовых парсеров. Почему JSON, а не YAML, тоже фиг знает.

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

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

upd: да, и при этом с ним тоже можно работать через API

В продакшне всегда сцена лежит отдельно, геометрия отдельно. Это все ассеты, которые в том или ином виде публикуются и становятся доступными работающими над проектом. Скажем, моделлер построил модель персонажа, назначил ювишки, запаблишил. Эта модель стала доступна риггеру, тот, в свою очередь запаблишил риг. Риг стал доступен аниматору, который санимировал персонажа и запаблишил уже свой ассет, например, в виде алембика. Далее этот ассет может подхватиться fx и/или lighting artist[ом|ами] для создания эффекта (сгенерить от персонажа облако эктоплазмы) и зарендерить все это. В Houdini мы просто читаем геометрию, которая пришла в принципе неважно откуда. Т.е. в файле сцены мы обычно либо создаём геометрию процедурно, либо читаем ее. Можно и хранить геометрию в самом файле сцены, но это несерьёзно. Ни к каким потерям это не приводит, наоборот помогает избежать проблем (помню у майщиков, работавших над фильмом Гравитация, майские сцены занимали 2 и больше гига, открывалось это все медленно и глючно. В Гудини этой проблемы нет). Если мы говорим об анимации, то она тоже может лежать как внутри файла сцены (причём это как раз часто), так и в виде клипа на диске (тут скорее речь о наиболее повторяющихся «библиотечных» анимациях, которые могут повторно использоваться, миксоваться и т.д.) Т.е. сцена и в Blender, и в Houdini - одно и то же, но подход может отличаться (хранение тяжёлых или часто используемых данных вне сцены). Ну и отдельной строкой HDA, но про них я писать не буду. Скажу только, что в HDA часто вставляют и геометрию, и текстуры.

В продакшне всегда сцена лежит отдельно, геометрия отдельно. Это все ассеты, которые в том или ином виде публикуются и становятся доступными работающими над проектом

в блендере нет такого понятия как файл проекта, но можно линковать любые данные из других blend-файлов (причем есть возможность аттачить в режиме ro) т.е. по сути создавать структуру в которой к главному файлу линкуется все над чем работают другие

в блендере нет такого понятия как файл проекта

.blend файл это и есть файл проекта в Blender.

имеется ввиду файл с описанpием структуры, такие как .code-workspace в VS Code или project.godot в Godot. В блендере вообще нет такого понятия как «Project»

в блендере нет такого понятия как файл проекта

Здесь проект означает «фильм», «рекламный ролик», «музыкальный клип», " видеоигра".

С чего это вдруг, это чем питон как обычная скриптота в дефолте лучше луа?

Питон проще — он более высокоуровневый. Встроенные типы и стандартная библиотека в питоне лучше. В lua до сих пор надо свой велосипед для split() писать.

В принципе, в луа всё «можно сделать», и каждый пилит свою коллекцию велосипедов. А в питоне всё готовое.

Вот потому и питон.

С чего это вдруг, это чем питон как обычная скриптота в дефолте лучше луа?

Мои 5 копеек. С точки зрения вхождения Blender в VFX-пайплайны Python всяко лучше, так как пайплайны эти написаны преимущественно на Python.