ComfyUIでXYZ-PlotするワークフローのサンプルとTips(ComfyUI-XYZ-Stitch)

ComfyUIでAutomatic1111的なXY-Plotをしたいのだが、ComfyUIデフォルト機能には用意されていない。

カスタムノードが必要となるのだが、Webには古いとか何故か動かないとかなXY-Plotパッケージの使ってみた系記事か、githubに上げられた野良ノードの作者本人コメントredditしか引っかかってこない。

また、この記事の時点でChatGPTもGeminiも具体的なパッケージ名や動くサンプルのワークフローを出力してくれない。

なので、まだしもComfyUI-managerのパッケージにあるものから（何故かXY-Plot用パッケージが複数ある）適当に ComfyUI-XYZ-Stitch というパッケージを選定し動かしてみた。

結果的に使えるようになるまでそれなりに調査の手間が必要になった。

公式がサンプルのワークフローを用意していればかけずに済んだ手間なのでそうしてほしい。

結論として、ComfyUI-XYZ-Stitch はいろいろ不便で不具合らしき挙動もありドキュメント周りが不親切だが有るだけで100倍は楽になるのでとてもありがたい、といったところ。

＊右クリック＞ノードを追加＞XYZ Grid>下にパッケージ関連ノードがある

＊ XYZ Grid Input(Batch)のほうを使う

　＊ Batchでないほうは1枚実行するたびIndexを手動でインクリメントする必要あるやつ

　＊「実行する」横のバッチ数は1回でよい。自動で画像生成が複数回実行されGridを埋める

　　＊このあたりバッチInバッチみたいな挙動をするというか、正直きちんと使うにはComfyUIのバッチ構造を把握する必要がありそうだが、とりあえず動くし使えるので今回は後回しにした

＊各軸のValueはテキスト出力されCLIPテキストエンコードには直結できる、K-Samplerのステップなど数字にしたい場合XYZ StringNumberノードで変換

＊ XYZAutoController,XYZGridStitchノードに画像が貯まる（イメージ）

＊（罠っぽい仕様として）ラベルは勝手につけてくれない

　＊ので(xy)z_labelsはBatchノードの(xy)z_valuesに入れた値に対応するものを手入力する必要あり（基本同じもので困らないが、ノード連結して勝手に入れてもらうとかはデフォルト非対応）

＊ layout_styleは変えても変化なかった。おそらくバグ

＊ labelサイズ設定は変えても変化なかった。おそらくバグ

＊ラベルが上半分しか描画されない場合がある。おそらくバグ

＊（罠っぽい仕様として）XYZ Grid Input(Batch)ノードのx_value他インプットは","コンマ区切りの入れ子ができない。コンマ区切りを含むプロンプトを切り替え出力したければ別途工夫が必要

＊（罠っぽい仕様として）8x8pxの黒いゴミ画像が出力・保存され「画像を保存」ノードの表示がされない

　＊ XYZ−Stitchが、Gridを埋める最終画像が来るまで、

　　画像1枚生成されるたびワークフローにダミー結果画像を作って流していることが原因

　＊ImpactPackのControlBridgeノードで解決

　＊（XYZAutoControolerのis_completeとControlBridgeのmodeをつなげる。

　　Grid生成が終わるまで来るダミー画像を捨てる）

＊あと出力がおかしかったらXYZAutoCollectorのresetをONにして実行する。バッチが詰まって順番おかしくなっていた場合、クリアされるらしい

＊ Zを使わずXYだけで出力すると、Grid画像のXY軸が反転する

　ラベル側だけXY逆にしておくことで暫定対処はできる

一番不親切なのはバッチ毎にゴミ画像が出力されることで、ドキュメントに案内が見当たらなかったが、ControlBridgeノードなどで工夫して回避する必要がある。

このことだけでも、XYZ−Stitchは動くサンプルのワークフローを用意すべきだと思う。

追記：なのでサンプルのワークフローを用意した。PRしているが取り込まれるかは不明

https://github.com/psdwizzard/Comfyui-XYZ-stitch/pull/5

ComfyUIのLoRA管理ノードを利用する(ComfyUI-Lora-Manager)

LoRAとプロンプトの対応を管理したくなり、調べた結果ComfyUI-Lora-Managerを導入した

LoRAの並び順に優位な効果があるかは議論があるが、画像コンディション調整の初期に足し引きON/OFFを試すのは確かで、標準のLoRAノードを都度繋ぎ変えるのは面倒だし、weightをゼロにしても影響が残るLoRAがあったりで、複数LoRAを集中管理できるノードが欲しくなる

そこで下記のComfyUI-Lora-Managerノードを導入した
ComfyUIのCustomNodeManagerから導入できる

（つまり半標準的と思われるパッケージに含まれている、らしい）

ワークフローへの追加は、ノードを追加＞LoRA Manager 下から「LoraLoader(LoraManager)」を選択。

このNodeの興味深いところは単にLoRAをリスト管理するためのNodeが追加されるだけでなく、ComfyUIのサーバにLoRAのページが追加されて、LoRAをヴィジュアルに管理・選択できるようになるところにある

ComfyUI上でブラウザで開けるイラスト表示なLoRAリストのページを作ってくれるので、選びやすくなってありがたい

専用のブラウザアドオン(LM Civitai 拡張機能)と連携し、ローカルにありComfyUIに認識されているLoRAの情報をCivitaiからトリガーワードを含め集めてくれる

（管理画面から「取得」ボタン押下）

また「更新」ボタンを押すと、ComfyUIサーバを再起動することなく、新しいLoRAを読み込ませることができる

LoRA管理画面では、各LoRAのトリガーワードを確認したり、配布元のCivitaiのページへ飛ぶこともできる

このLoRA管理画面はワークフロー内のNodeとも連携しており、LoRAの紙飛行機矢印ボタンを押すと、開いているワークフローの「LoraLoader(LoraManager)」にLoRAが追加される

トリガーワードをワークフローに接続するには専用のLoRAノードを使う必要があるが、以前諦めたLoRAのまとめて管理とドラッグによる並び替えも対応しており、都合がよかった

LoRAの運用管理に大変便利な一方で、私が使った範囲では、トリガーワード自動設定は実用できなかった

（ワークフロー上ではmodelのみ接続して、Clipは接続するべきではない）

トリガーワードは服装の指定がされていたり、逆に服装の指定がないためほか条件で服装が変わってしまうものもある
そのため例えば、服装毎に複数種類指定されているLoRAは、結局は手作業でプロンプトを管理しないといけない。あるいは、服装が指定されていると困るテーマの画像を生成したいときもある

それだけでなく、トリガーワード管理を任せてみると、LoRAのweight設定がうまく反映されないという問題が起きた

LoRAを外して”FlatShadow”,"<lora:FlatShadow:0.01>"とプロンプトに書いてみたり、調査したり、色々試した結果、原因としては、おそらくこういうことらしい

＊ LoRAManagerはモデル入出力側で強度を調整している。出てくるプロンプトではない
＊ ComfyUIは"<lora:FlatShadow:0.01>"などと書いたとき強度(0.01)を無視する
＊元モデルにLoRAと同じものが取り込まれている(？)と、LoRAと同じ効果がデフォルト強度で適用

つまり上の例では、どう書こうがweight設定しようが常にweightを無視して「FlatShadow:1.0」が適用されて、「LoRAManagerでの強度調整が効いていない」ように見える、ということらしい
(モデル内に存在するのがLoRAそのものか、同じキーワードなのかはよくわからないが、LoRAの名前は多くの場合にLoRAの特徴で命名するので、単語として解釈すればキーワードになる)

（「世の中には何を設定しても常に強度１のLoRAがある」とかの真偽不明の情報もあり、この調査結果も仮のもので実用上困ったらまた検証レベルだが、一応頭の片隅にとどめておく）

結論：ComfyUIの仕組み上、「LoRA Managerでトリガーワードを自動適用」は破綻しており、実用は無理
でも並び替え可能LoRA StackとローカルLoRAの画像で見れるVisualなリストは便利なので引き続き採用したい

雑感：
体感として今更ながら、コンセプト・キャラクタを含めて、何でもLoRA投入ではなく、まずモデルにプロンプトででやってみて反映が弱かったりされなかったらLoRAを試す、という順にすべきらしい
SD1.0時代の記憶のせいか、なんとなく棒立ちモデルにLoRA乗せていくイメージになっていたけれど、illustriousはプロンプトがわりと英文ぽい複合的ワードになっていたり、キャラクターが標準搭載されていたりで、表現力がある

画像生成AIをやるということについて、ChatGPTやGrokにプロンプトを書いてもらうにしても、結局は日本語でやりたい構図や欲しい表情を伝える必要があり、つまりは言語化が必要で、「お前は何を描かせたいんだ。それを言語化しろ」と言われている気がしてくる

Pixel 7aを買ったので自分が購入前に読みたかったレビューを自分で書いてみる

カメラ性能がどうとかスペック比較がどうとか、そういう一変通りな評価ブログ記事ははっきり役に立たないので、本当のスマホ端末の評価ブログ記事というものはこう書くのだという記事を自分で書いた。

スマホ端末レビュー記事で一番大事なのはちゃんと筆者の自分語りがされていること。なぜならスマホ10台持っていてスマートニュースとITmediaに寄稿して技術書典に出展しているガジェットナードの書いた記事（このスマホはレンズが５つあるし世界で唯一ホンジュラスでしか使われていないバンド帯域のSIMにも対応しているので最高！）はガジェットナード以外が読んでも参考にならないから。
このブログ記事の筆者は、「スマホの画面はデカければデカイほどいい」と信じており、8インチタブレット(huawei media pad M5 lite 8)がSoCスペック十分だった頃にはメインスマホとしてポケットに入れて持ち歩いていたことがある。
そして7aはRedmi note 10tからの買い替えで、「音楽再生しながらChromeでツイッタを見ているだけでもミュージックプレイヤーがKillされるのが辛い」という理由で買い替えに踏み切った。

＃＃総合

とにかく音楽再生しながらChromeでツイッタを見ていてもミュージックプレイヤーがKillされないのが最高。
タブを移ったりちょっとLINEを触ったあとにツイッタに戻ってもページリロードで見ていた箇所が消えないのは素晴らしい。

＃＃（購入前）Suica対応

Suicaが不安定な個体があるという未確認情報があるため、購入はギャンブル要素がある。
この情報源のブログ、やたらと冗長な文章でどうにも信頼性を怪しく感じる。閑話休題。
私が買った端末は問題なく改札Suicaタッチできたのでよかった

＃＃ロック

電源ボタンに指紋センサがないのは面倒
また画面の指紋センサはあまり効きがよくない
ガラスフィルム貼って使っているから感度が低いという話はあるが、ン万円もする端末をフィルム貼らずに使うはずがないのだから（要出典）最初からフィルム貼られる前提で指紋センサ作っておくべきというだけ
購入してまずフィルムを貼ったため、指紋登録自体をフィルム有りで行っている
PIN入力の際、以前の端末までは正解PINを入力すれば解除されていたのが、確定ボタンを押さなければいけないのが１アクション増えて面倒になった
（セキュリティが気になるユーザは１文字増やせば同じようなものなのだから、省略させてほしい）

＃＃ウィジェット

アプリ一覧のアプリを種別ごとにまとめられないのはどうなのか
（数ヶ月使ってみたら後述の検索でなんとか運用でカバーできるようになり、まあまあ慣れた）
インストール済みアプリを検索でひっかけられるのは良い。ただ全く引っかからないこともあり、もっとあいまい検索でもひかっけられるように（カタカナでラインと打ってもLINEがひっかかるとか）できているべきだと思うが（Googleって検索で大きくなった会社じゃなかったのか？　検索の技術力が低すぎる企業なのではないかと感じた）

＃＃キーボード記号入力

gmailのメールアドレス拡張(+xxxx@gmail.comをつけ放題の機能)のメールアドレスをよく使っていたのだが、ログインなどでメルアド入力する際に入力が地味に面倒。
インテリセンスが効かないのと、｀+｀の記号を入力するのがテンキーでもできないため。
わざわざキーボードを記号入力までモード移動しなければならないが、7aでは「使用歴あり記号一覧」みたいなのがあり、少ない候補からいつもの｀+｀が入力できるのは便利。ただこれ私はいいけれど各種記号使うユーザはすぐ溢れるのでは？

＃＃カメラ

画質はそもそも気にしていない。気になるほど悪くはないのでOK
前の端末より起動が早くなったのは嬉しい

が、以前の端末と違い、ロック画面からアクセスできなくなったのは不便

pixel 7aの問題と言うより、スマホ以外のカメラも含めて、やはりまだ、撮りたくなってからアプリを立ち上げてシャッターを切るまでの時間で、撮りたいものに撮影が間に合わないな、と感じている

＃＃アラーム

以前はホーム画面の時計をタップすれば設定に入れたが、今は一旦メニューを出してから時計を触る必要があり、かつ時計が小さくアクセスしづらくなった

＃＃あとがき

購入して上記のレビューの原文を書いてからざっくり半年ほど経った。pixel 7aに慣れてしまっただけかもしれないが、いまのところ大きな不満はない
あえて言うなら、以前はPixelの広告がプッシュ通知されていたのだが、OFFにしたのか覚えていないが最近は出てこなくなったようで良い、というのが近況だろうか

個人的には、早く24インチディスプレイが気軽にモバイルできるようになってほしい

スズランのフィギュア作りました

スズランのフィギュア、なかったので作りました

フルスクラッチ 1\7 スケールの光学式3Dプリントガレージキットです

「無いんだったら作ればいいのよ」という古い神様の格言に従った次第

2022/09から着手して2025/5リリースとなり、足掛け2.5年かかってます

まあ途中中断していたからなのですが、正月アカリを作ったり商業出版したりいろいろあった間に競合でもある素敵なガレキがいくつか出てきたものの、公式からスズランフィギュアが出ないままだったのは、良かったのか悪かったのか

Blenderの利用

スズランのモデルデータはBlenderにてポリゴン方式でモデリングしました

今回いわゆる「ローポリ」の先人たちの知見を応用させていただいた次第です

ポリゴン方式は、ざっくり説明すると三角形の面をくっつけ合わせるタイプの作り方です

2Dにベクタとラスタがあるように3Dにもポリゴンとボクセルがあり、Blenderは3Dモデリングソフトウェアとしてはボクセル風な作業もできますが基本はポリゴン系ベースです

ただ、いわゆる美少女フィギュアのモデリングで一般に多いのは、ZBrashでボクセルです。ようはCG粘土細工といった手触りになります

つまり、Blenderでモデリングをすると一般的なフィギュアモデリングのテクニックそのまま使えない部分が出てくるということです。ゲームキャラクターCGなどでこれまた知見の多いローポリを応用する必要があった理由でもあります

あとついでに、Blenderは元はCGアニメーション向けとして出発しているソフトウェアです。なので3Dプリント用モデル製作での使用は、向いてないというか不便なところは正直ちょっとあります

髪と顔

頭部は前髪と後頭部をパーツ分けする標準的な分割です。耳は後頭部と一体化

髪は房毎のポリゴンパーツとしました。参考モデルがそうだっただけなのですが、結果的に流れるような綺麗な髪を持つモデルの素敵なスズランとなり、作り直しせずに済みました

とはいえ次モデルでは、パーツ管理の都合で一体ポリゴンパーツに挑戦すると思います

顔モデルは元々CGアニメーション向けのポリゴン構造を参考にして流用しています

そこから手元にあるフィギュアや、デッサン用に持っているアニメドールの頭部を参考に、アイペイント向けに作り変えています

また、フィギュア向けを意識して、元イラストよりも僅かにシュッとした縦長で大人っぽい造形に寄せています

スカート周りの造形

薄いマテリアルはプリント時に歪みの原因となり、広がった裾が3Dプリンタの造形サイズ限界を叩き、多量のフリルは作業工数を爆発させ、左右非対称の皺がスケッチ技能を要求する...等々、スカートは単純ながら難しいターゲットです

モデルとして固定方法も困りもので、最終的に、スカートを胴体と下半身の間で挟んで固定するため、腰回りの全モデル含有を断念しています

最初はアンダースコートもそうだったのですが、スカート厚の問題もあり、かなり手間を掛けて、スカートにビルトインする形に変更しました

BlenderではSubdivisionSurfaceを用いることでかなりポリゴン数を削減しなめらかなスカートを作ることができます。この方式は操作ポイント数をかなり削減できるため編集が楽になるのですが、Blenderと印刷の都合によりViewレンダリングが重くなってしまうのを避けられません

アンダースコートのフリルは何かしら良い感じの幾何学的操作で半自動で作ったような気がするのですが、時間が経ちすぎて手順を忘れてしまいました

スズランの背中

スズランの背中側、意匠がどうなっているのかは正直よくわからず、あちこち調べまわりました

現状、調査の結果として公式の3DモデルがX周年記念動画で登場しており、後ろからのショットもあったのでこれを参考にしています

(CG,VRでない立体造形用モデリングなので色付けは適当です)

ただしこれも3Dモデル用にディフォルメなどされたものである可能性はあります

また、どうにも首元の布色など詰めていくと矛盾するようなところがあり、最終的には首裏の構造には創作も少し混じっております

公式資料集などには答えが載っているのかもしれませんが、タイミングにより入手はできなかったため、情報をお持ちの方は良ければお知らせください

とはいえ、最終的には後述の通り、マントをマウントする都合で本モデル固有な意匠も入れています

マントの固定

引き続きベルトも関係する話として、フィギュアのマントの固定

フィギュアのマントパーツは、どう固定するかという問題がつきまといます

スズランの意匠の場合、肩を覆うフリルと前面の止め紐で全周を覆っているのも問題です

今回のガレキでは、パーツ構成としては止め紐はパーツ分離して肩フリル付きのマントを一体出力

組み立ては首を外した状態でマントをかぶせて組み立て

基本的には接着剤で固定する、という想定としました

成形について、最初は止め紐含め一体で3Dプリント出力していたのですが、

上半身の方にマントの止め金がありそうな位置に対応するマウントポイントを造形することで対応しました

マウントポイントは創作で、背中の見えないところは完全に固有ですが、前面の止め金は本家デザインにも存在する蓋然性はかなり高いのではないかと思っています

ワンド（杖）

フィギュアモデリングはキャラクターが主体ですが、直線が多く作りやすい装備類、特に長物として目を引く杖のモデリングは、ある意味３Dモデリングで最も楽しい工程ではあります

今回悩んだのですが、弊シャとしては新しい試みとして、ワンドの軸に既製品3mmプラ棒を採用することとしました

パーツ管理まで考えると意外とこういう単純な形を3Dプリント出力するのは面倒ですし、あと弊シャは高価なレジンを使っているので置き換えられるパーツは節約したい、という都合もあります

モデル側の工夫として、杖自体ではありませんが、杖を持つ手のひら内側に杖を位置固定する凸モールドを入れてあります

中折装着にすることで杖の塗り剥げを防止し、杖を持つ高さも固定できます

３Dプリント工程

苦労が多い3Dモデリングですがフィギュア制作においては道半ばに過ぎません

モデル完成から、3Dプリントにたどり着くまでにはいくつか乗り越えるハードルがあります

＊多くの場合、モデルをそのまま一括3Dプリントはサイズ上厳しいため、印刷モデルはパーツ分割が必要です。パーツ分割方法によっては後の着色工程を支援することもできます

＊コストと取り扱いの都合、印刷モデルは中抜きするべきです。中抜き自体はスライサが自動でしてくれますが、中に溜まるレジンを抜くための抜き穴の位置はヒトが調整して開ける必要があります

＊多くのモデルは全てが土台にひっついた出力とはならないので、出力中に印刷物を支えるサポート材を付けることになります。これもスライサが自動で付けてくれますが、あまり賢くないので最後はヒトが調整します

＊これらを３Dプリント土台上で配置し、必要なら複数回に分けて、3Dプリントを実施します

パーツの分割

パーツを分割してしまうとポーズの大幅な変更は厳しいため、非可逆な工程となります

3Dプリンタの印刷可能サイズによってはモデルデータを未分割で出力が厳しい

大きなスカートなどをモデリングするときは、当初から分割可能になるようデザインを検討することになります

芯棒穴をあけておく

ガレージキットといえばパーツを繋げる針金を刺す穴も購入者が開けるもので、パーツ同士ズレないように穴をあけるテクニックがよく取り上げられています

流し込み複製では難しいですが、３Dプリント向けモデルでは穴を開けることも容易なので、最初から芯棒を刺す穴をあけておくことにしています

自分で仮組みをするときにも役立ちます

モデルの中抜き

高価な光造形レジンを使っている都合、モデル中抜きは大切で、中抜きの有無で材料費が３倍とか違うため試作にも影響が出ます

ちなみに、弊シャことdaisy bellではエキマテという安価帯価格から5倍くらいする高額レジンを使っています

アレルゲンフリーを謳っており、うっかりレジンアレルギーで光造形3Dが出来なくなるなどのリスクを低減できる、はずです（ちなみにエキマテ販売元に「硬化前から大丈夫なの？」と訊いたことがあるけれど成分表だけ渡されて大丈夫と明言はしてくれなかった）

閑話休題

初期、中抜きはBooleanモディファイヤで手作業していました

できるだけ材料消費を減らすよう薄くギリギリを攻めて、試作を出力すると薄すぎて破綻したり中貫が突き抜けて穴が空いていたりで、やり直しに時間と材料費が無駄にかかる本末転倒、みたいなことになっていました

ほかにも、Booleanモディファイヤで複雑になるとモデルデータが重くなるとか、モデルを編集したとき中抜きも編集して追従する必要があり面倒、などのデメリットがあります

結局、モデル作成でまごまごしているうちにスライス後工程ソフトウェアのCHITUBOXに中抜き（Hollow）機能が実装されたため、ほとんどのパーツで中抜きをCHITUBOXに移行してモデルからは削除しました

3Dプリント実施

スズランはスカートが大きく他パーツも点数が多いため、結局、弊シャ環境では4回に分けて3Dプリント出力が必要となりました

総括

満足いくものが出来ましたが、もっと工程は洗練できると思うので、次回はもっとうまくやります

daisy-bellのBOOTHにて頒布

https://daisy-bell.booth.pm/items/6800571

Blenderクイズ：SubdivisionSurfeceの結果がおかしい

（今回、持って回った英文翻訳風にざっくり雑にブログ記事を書きたい気持ちだったのでクイズの形式を取っているだけです。答えバレ防止反転表示などはしていないので、本当にクイズ当てしようとせず、軽い気持ちで読んでください。）

3Dモデリングソフトウェアは立体という我々が日常に何時も触れている身近な存在を扱うソフトウェアですが、あくまでコンピュータの中にあるObjectは計算で仮想しているものでしかなく、そのため時に思いがけない結果形状を示し、望みの外観を得るためには（私がそういった深い認知を持っているかは棚に上げますが）Blenderへの深い理解や長い経験が必要な場合があります。

今回はクイズです。Blender上でSubdivisionSurfece モディファイアを掛けた結果がおかしいのですが、まずどこがおかしいか気づきますでしょうか。そして、原因と解決法は？

詳しい状況として、肩掛けのフリルを作成しています。先程Split>Selectionでオブジェクトを分割してフリルを切断し、空いてしまった面を埋めたあと、EditModeでいくらか点を動かして形状の調整をしたところでした。

こうすると見える対象Objectのフリルの端はObject形状の調整前というだけで、クイズの答えではありません。

正解はフリルのこの面です。

この面だけおかしなことに、SubdivisionSurfeceが効いていません。隣の面と比べれば一目瞭然です。

Blenderでのモデリング中、SubdivisionSurfeceがおかしな結果を示すことは枚挙に暇がありません。

大抵の場合、点の重なりを散々調べることになり、膨大な点を１つずつクリックしてみる作業に１時間を費やした後、面のNormalがおかしいことに気づきFlipで解決、といったコトになります。ですが今回、スクリーンショットをご覧いただければ、最初からFace Orientation のView設定が有効な状態で、一発で見て判るとおり、今回は面のNormalも原因ではないようです。

今回、原因を探るには、別のView設定で見る必要があります。