画力がないなら立体を作ればいい

「何を作る」より「どう作るか」を考えたい人

今日は少しプラグイン開発が進んだ

(約 2,400文字の記事です。)
f:id:yamato-tsukasa:20190626012614p:plain

今日も日記的駄文なのですがZbrushのプラグイン開発に関わるのでnoteではなくブログに付けることにします。

Zbrushの画面フィットはFキーでトグルする

f:id:yamato-tsukasa:20190626012726p:plain

私自身はZbrushのキーをカスタマイズしまくってしまったため、もはや記憶が曖昧なのだが、確か標準ではFキーを押すとオブジェクトが画面いっぱいにフィット拡大されるはず。で、サブツールを分けている場合、もう一度Fキーを押すと今度はそのサブツールだけを画面いっぱいに表示してくれるはず。なので、サブツール群で構成した1つのオブジェクトの場合、Fキーを押すごとに全体表示、拡大表示が切り替わる、トグルすることになる。

Zbrush内部的にはトグルの状況を把握していない

厄介なのはこれで、Zscriptからは今、「全体表示なのか」「サブツールの部分拡大表示なのか」が判定できないのだ。もちろんユーザー様からすればFキーを1回押すか2回押すかの違いでしょ?と思うかも知れない。だがプラグインの自動実行中の挙動で、今、「全体表示なのか」「サブツールの部分拡大表示なのか」はとても重要なのだ。全体表示のつもりでいてプラグインを実行すると、サブツールの拡大表示状態になっていて全体像が見えなくてわかりにくかったり、逆も然り。今まではその方法がなく、ユーザーにYes/Noボタンで問い合わせるしかないという苦肉の実装であった。

「全体表示」「サブツールの部分拡大表示」を強制できる関数の開発

これが完成したことで、ズーム率の問題が一気に解決した。つまり、こちらの意図で常に全体表示にさせたり、逆にサブツールの部分拡大表示に自由に指定できるようになった。これでユーザーにYes/Noボタンで問い合わせることなく一発で自動的に意図した表示状態に移れる。これは地味だがとても重要なのだ。

3DCGは見た目がとても重要だ。これは間違いない。なのでプラグインで自動実行時、実行中の確認画面など、見た目に関する部分で明示的に全体をフィット表示させる指示を出せることはとても重要。今まではできなかったが、これからは自作関数を使うことでそれを指定できるわけだから、使い勝手(ユーザビリティ)が向上することは間違いない。

机の高さを調節して快適タイピング

私事だが、机の高さを調整したところ、劇的にタイピングしやすくなり、肩こり腰痛が激減した。というか以前の環境に近づいただけなのであるが、それだけで意欲が全然違うから、環境というのはとても重要だ。キーボードの進み、ノリが全然違う(笑)

机の高さ調節の際に机を引きずってしまい、フローリングに傷が付いて気持ち的にとても凹んだことはナイショです。そしてフローリングも凹んだ。

8枚のスクショツール

f:id:yamato-tsukasa:20190624224339p:plain

8方向のスクショをまとめて一気に保存するツール(正確に45度回転のスクショが撮れる) - YAMATO Tools - BOOTH

これ自体は、私の需要ではなく、とある熱烈なユーザー様からの要望に私が一方的に答える形で開発したプラグインだ。なので、自分自身の利便性の向上にはあまり貢献しない(笑)が、作った以上はきちんとした形にしておきたい。なので修正中。

現在の懸案事項は設定値の保存&呼び出しの実装方法だ。スマートなのは1つのファイルに全パラメータを格納するスタイル。だがこれは開発コストが高い。メモリの読み書きとファイルへの読み書きとバイナリ値の制御が入ってくるからだ。一方でお気楽なのは、Zscript純正の機能を使って1パラメータを1ファイルで読み書きするスタイル。これは割と簡単。代償として、パラメータ数分のファイル(1KB)ができる点。今までの実装で、無名固定ファイルの読み書きにはそれを採用している。逆にBTCなどでファイル名保存のスタイルは前者で、面倒なことをしているが、400個のファイルができるよりも1個のファイルがスマートなのは間違いない。

だが、3,4個のファイルなら、悩む。面倒な実装してまで1つにまとめるべきか、ユーザーが気にしないなら4個のファイルへの並列読み書きでも使い勝手に差はないし、ファイル管理の点でも3,4個なら許容範囲でしょ?とも思う。

もちろん美学としては1個のファイルが一番スマート。だが実装への手間が違う。バイナリ制御になるので機能拡張時の動作確認が毎回発生する(1ビットずれたら値がメチャクチャになるため)。これは結構ストレスで、逆に1パラメータ1ファイルの読み書きだとそれがない。代償として、ファイル数が複数になる。ユーザー様がフォルダを作ってそこに入れてくれるなら問題ないが、それを自動化できないのに人にそれを要求するのは美しくない。だが実装の手間がある。

これが目下の悩み所だ。

開発者の美学を取るか、実装コストを取るか

外部ファイルにパラメータを名前を付けて保存するなら、1ファイルが美しい。これは間違いない。ただ、それに要する実装コスト。

逆に1パラメータ1ファイルにするならば実装コストはほぼゼロだ。楽ちん。そのかわりパラメータ数分のファイルができる。美しくはない。

これが悩み所だ。2,3個ならいいけど、4個以上なら悩む。悩む理由は、この仕様変更によって過去と未来のファイルの互換性がなくなるという不便さをユーザー様に押しつけることになるからだ。それを回避するためには過去版をフォローする仕組みを未来永劫サポートする必要がある。これも大変だ。

結局は、人に使ってもらえるようにソフトを作るって事は、こういう開発コストと利便性とポリシーや美学とが絡み合って形になっていくって事を、きっとここに記しておきたかったんだなぁ、と思う。

今回の創作活動は約30分(累積 約871時間)
(272回目のブログ更新)