Zbrushプラグイン開発、難航中
（約 2,600文字の記事です。）
今日もZbrushプラグイン開発の日記。結局、多分、7度目の仕様変更かなぁ。もう忘れた。最終的に回り回って最初の仕様に近づいた。
今日も疲れ切ったのだけれど色々と愚痴を書いておこうと思う（笑）
ボタン文字列とIDが1対1じゃない
Zbrushのボタンにはボタンパスという文字列によるアクセス方法がある。そしてそのボタンにはウィンドウIDという数字が割り当てられている。てっきりIDとボタンパスは互いに唯一の存在で1対1の関係だと思っていた。
普通のソフトウェア設計ではそうなる。
だがZbrushは普通じゃない。
それを忘れていた。
Zbrush 2022では62個、2023では58個も重複アイテムが存在する。
これも結局、分析用のプログラムを書いてループで回して解析した結果だ。これだけでもかなり苦労した。
上記の場合には文字列が同一でもIDは一意だった、2023では。
IDのバッティング
だが2022では検査しただけでも28個のボタンが他のボタンIDと重複していた。これもあり得ない。ハッキリ言ってバグだと言っていい。2023でかなり改善されていることからも、エンジニアから見ればバグなのは明らかだろう。
そして2022のこのIDバッティングの問題が、最終的にユーザー側での使い勝手の制約につながってしまう。開発者としてはどちらか一方を選んで「IDとボタン文字列とを1対1にする」必要があるからだ。
今回の実装では最初の目的に一番近いボタンとIDとを結びつけることにした。なので一部は今のZbrush 2022の実装のままでよしとし、他の一部は意図的に例外処理を組み込んだ。それ以外はもう面倒臭いので操作禁止アイテムとして実装することにした。
ここまでで、かなりの例外処理に次ぐ例外処理でぐちゃぐちゃになりそうだった。
これらについてはエクセルで管理している。アー面倒くさい。主にリリース後のメンテで面倒くさい。またアプデでボタン文字列やIDが大幅変更された場合のアプデのことも考えると、正直言って頭が痛い。
状態によってボタン文字列が変わるアイテムがある
これもあり得ない実装で。とあるアイテムについては、アイテムの状態によってボタン文字列がコロコロ変わる。なのにIDは一定。もはや謎仕様。どういう思考で実装されているのかもはや意味不明😭
他のアイテムと全く同じ制御コードを使っているのに動いてくれないアイテムがある
プログラムなので同一のコードで制御することは当たり前だ。ところがとあるアイテムだけはなぜか正常に動作してくれない。これもまたあり得ない話だ。だがそれがZbrush。幸い、色々試行錯誤した結果「正常に動作させられる方法」が分かったので、それをその特定のアイテム専用の処理として用意する必要がある。
また例外処理が発生した。どんどん増える例外処理ルーチン。
それの「別パターン」もまた発生。また例外処理かよ～😱
自作マクロや他者製プラグインを入れるとボタンIDが変わる
これも厄介な点。実はこれによって昨日から仕様変更を強いられた。自作でマクロを作ったり、他者のプラグインをインストールしたりすると当然ながらボタン類の数が変わる。これによって特定のボタンIDがずれ込むのだ。なので開発者とユーザー側の環境が同じではない可能性がある。
これを回避しようとするとIDではなくてボタン文字列を主体に扱う必要がある。
だがボタン文字列とIDは一意じゃない。1対1じゃない。
これに苦しめられた3週間だった。
選んだのはハイブリッド
二転三転どころか六転七転して、一番最初の仕様に戻ってきた😭ただし変更点もある。基本的には9割ほどはボタン文字列を扱い、それでは困る部分を例外的に文字列の数字を扱うことにした。ウィンドウIDを直接文字列として扱うのだ。Zbrush内部では、95％ほどは数値型のIDを扱い、例外処理として5％ほどは文字列型のボタン文字列を扱う。
これだけ見ても外部ファイルでの文字列と数字文字列の扱いの違いがあるし、内部でも数値の扱いと文字列型の扱いがある。すでに4パターンの分岐がある。つまり4パターンの例外処理を実装しているわけだ。
特定の困ったアイテム以外は、ボタン文字列が基本的には唯一である場合が多いので、ZbrushのアプデなどでIDが変わっても文字列が唯一であれば上手く対応できるからだ。問題になるのは直接数字としてIDを扱っている場合。こればかりはアプデごとに実装結果をフルチェックしてバグ修正していくしかない。
だが運良くユーザー様が普段使っているボタンについてはアプデで影響がないボタン文字列を使っているならば、何の問題も表面化しない。その可能性が高いと思ったので、そちらを採用する仕様に変更した。
昨日まではID数値を扱うやり方だった。この仕様変更に今日一日が消えた。
ほとんどリファクタリングしたようなもの
といってもオブジェクト指向言語ではないのであくまでも概念的な意味合いで。結局色々あって、最初の仕様に近いながらも、内部のコードの構造はかなりスッキリとした。コード呼び出しの往復を省き一方向にした。といってもかなりの分岐があるけれど、最初のコーディングからすれば絡まり具合がかなり減った😊主に可読性の問題。
ユーザーからすれば使い勝手は何も変わっていないが、Zbrushのアプデなどでの例外処理の追加がしやすいコードに仕上がった。
これ以上の例外処理は今は見つけられないので、リリース後にユーザー様からのバグ報告に個別にアプデで対応しようと思う。
明日は明日でもう一踏ん張りでコーディングしなければならない。まだ営業サイドの活動には移れない。
だがもしこれが完成すれば、95％のユーザーは満足する使い勝手の良いツールになると思う。残り5％のユーザーには、もしいるとすれば、お問い合わせ＆打ち合わせからの個別対応になる。
100％カバーできないのはZbrushのバグのせい、Zscriptのバグのせいです。開発者側ではもうどうしようもありませんし、5％のためにこれ以上骨身を削ることもまた現実的ではない。
というわけで今日から4月ですね～。はるでぇむん。
今回の創作活動は約45分（累積 約3,218時間）
（887回目のnote更新）
読んでくれてありがとう。気長にマイペースに書いてます。この出会いに感謝😊