Masaaki Shibata blog
すこし前になるけど Blender の新しい LTS となる、4.2 LTS がリリースされた。以前のポストでも書いたけど、4.x にはカラーマネジメントの Device Profile にはじめから Display P3 が用意されている。
Mac で Blender を使っていて、私の以前のポストを参考にカスタマイズしたカラープロファイルを作っていた場合は plist ファイルや環境変数、OpenColorIO 設定などを削除しておかないと、せっかく公式でサポートされたのにその恩恵を受けられないので注意してください。
Blender のアドオンを作った。Add-on Filter Tweak アドオン（ややこしい）。
Blender を使っていくと便利なアドオンをどんどん追加していくことになって、気がつくと N で表示されるサイドバー（通称 N-Panel）がたいへんなことになってしまう。
だいたいたとえば Auto-Rig Pro でキャラクターを作ってるときに Fluent のハードサーフェースモデリングの機能とか表示されてなくていいのである。Rigify でリギングされてるキャラクターを作ってるときは Game Rig Tools のパネルが出てほしいが Auto-Rig Pro のパネルは不要である。いっぽうで Auto-Rig Pro のワークフローなら Rigify の設定項目や Game Rig Tools のパネルは使わない。
Blender には標準機能として UI として有効にするアドオンをワークスペースごとにフィルタする機能がある（View3D > Sidebar > Tool > Workspace > Filter Add-ons）が、ワークスペースごとなので使いにくい（.blend ファイル内のすべてのワークスペースで個別設定）。
このあふれる N-Panel 問題を解決するための Clean Panels Pro というアドオンもある。私も使ってみたけどこれはこれで便利なものの自分にはオーバーキルな感じもした。
ようするに標準のアドオンフィルターですぐに .blend プロジェクト内の全ワークスペースに反映させたり、あれを簡単に全オン／オフできればいいのである。ということでそのための UI を追加するアドオンを作りました。
1.0 – mshibata/addon_filter_tweak – Codeberg.org
上記リンクからスクリプトをダウンロードしてインストールしてください。README.md ドキュメントはあるけどようは入れるだけです。
あけましておめでとうございます。
「macOS で Blender を使うときのカラーマネジメント設定」、「Mac の Blender でレンダリングした画像のカラープロファイル」、「続（？）Blender のカラーマネジメント設定」で細々と愚痴っていた Mac で Blender を使うときの色問題ですが、Blender 4.0 において「カラーマネジメント」の設定にめでたく「Display P3」が追加され、こちらでごにょごにょやる必要はなくなりました。
Color Management – Blender Developer Documentation
私はまだ 3.6 LTS なので詳しく試してませんが、少なくとも基本的な不満はこれで解消されたと推測します。
2024-01-01 追記。「Blender のカラーマネジメント設定（完結編？）」
Blender のカラーマネジメント設定、とくに広色域ディスプレイを持つ Mac で正確な色を見て作業するノウハウについて一昨年、昨年にブログを書いたのだけど、じつはそこで言ってる方法は理論的には正しいのだがなぜか Blender が落ちたりしてしまって実用上あんまりいいものではなかった。
いっぽうであいかわらずこのトピックは情報がマジでぜーーーーんぜん更新されなくて、同じような疑問を持った人がけっこうこのブログを検索で見つけて（というか日本語でこの話題を書いているのはここだけだ）試行錯誤してるみたいである。
で、じつは昨年くらいに最終解みたいのを見つけてしまっていたのだけどめんどうで書いていなかった。ツイートはしたかもしれない。というのも、ある YouTube 動画を見つけてそこにすべて述べられていたのである。
Blender configuration for ICC color accurate display with OCIO / ACES [English]
ここで言ってるとおりにすれば解決です。おわり。
あとはせいぜいだれかが日本語でこの内容を書いてくれればそれでいいんですがだれも書かないんですよ。なんなん
VSCode で Python ウェブアプリケーションを開発するとき、コンテナの活用という視点で見るとつぎのように分類できる。
古典的なやりかた。プロジェクトをチェックアウトして、venv を作ってコードを書く。デバッグ（実行）するときもローカルのマシンで venv の Python で動かして確認する。いちばんなじみがある。
VSCode ではデバッグ時にコンテナでプロジェクトを走らせることができる。ウェブアプリなんて作ったらどうせ（？） Dockerfile 書いてコンテナで動かすんだからはじめからコンテナで動作確認したほうがいい。後述の Dev Container が出るまでは有力な選択肢だった。
Dev Container ができて、最初から実行環境に近いコンテナでぜんぶ開発できるようになった。コンテナの中でローカルのように開発、デバッグできる。VSCode すごい。
Dev Container 開発の利点は、“What’s a devContainer and what is it good for?” (2023) という記事で次のような点が挙げられている。
で、ここではじつは開発環境が実行環境に近いということはとくに謳っていないのだが、たとえばプロジェクトで利用しているあるライブラリが Linux のみ対応だったり、Windows / macOS では挙動が違ったり、ディレクトリ構成が異なることで面倒な対応が必要だったりというのはありがちな話なので、そういうことから解放されるのはけっこう大きいメリットではないかと思う。