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

デジタル箱庭クリエーターを目指す小さな足跡

BTC Ver.2.3.2 開発裏話

(約 5,200文字の記事です。)
f:id:yamato-tsukasa:20190130034308j:plain
いよいよBTCプラグインも集大成という気がする。これ以上シンプルで強力な機能を実装できる気がしない。今回はちょっとだけ開発秘話をば。
DLはこちら。
Zbrush用プラグイン「Back To the Center」(斜め配置と原点配置とを往復可能) - YAMATO - BOOTH

サブツール名と回転情報とのリンクはできるのか?

実はそれを試すべく急いで作ったのがVer.2.3.1。かなりの急造仕様。我ながらよく動いたものだと関心。アルゴリズムはできていた。あとは実装できるかどうか。できそうだったのでやってみたらできた。といってもメチャクチャ苦労してますが。

で、実現が可能だと言うことが分かったので、冷静になってソースコード類の整頓。これに時間がかかった(笑)急造仕様と同じだけの時間がかかった。不思議である。

Ver.2.3.1は、できることを最短でやるためのコードでできていたので、メンテナンス性など皆無。例えて言うなら地図上を最短距離で進むための経路で作ったような物なのだ。裏の畑や竹林を突破したような感じ。

さすがに今後のメンテがきつい。なので、最短距離ではなく、大通りと交差点と、どこでどこに曲がるべきかが分かりやすいような、そんなコードに整理し直した。

共通部分と非共通部分との徹底分離

例えば、BTCもCWAも共通分がある。今まではCWAはBTCのエンジンを使わせてもらっての実装だった。だからどうしてもCWA特有の動作にBTCの文言が入ってきたりして、微妙に入り交じった状態だった。なので、今回、ワークフローをきちんとBTC用とCWAとに分離させた。

もちろん両者に共通する部分は冗長になる。だが、その代わりに各フロー特有の現象に細かに対応できるようになる。こちらの方がメリットが大きいと判断した。

回転エンジンの分離

BTCの肝は回転移動だ。これはBTCもCWAも共通。だから、コアになる関数をきちんと独立させ、BTCからもCWAからもたった一つの回転エンジンを呼び出して使うようにしている。これにより、回転エンジンにバグがなければ確実な動作が保証される。

同様に、BTC AgainボタンやRelocationボタン、Extra Banksの BTCAボタンやRlcボタンでも、同様に1つの回転エンジンを呼び出して利用している。なので、メモリからの回転情報読み出しにバグがなければ、常に同一の精度の回転結果が得られる。これれがソースコードを整理して分離した最大の理由だ。

1つが完璧なら、全てが完璧。これがわざわざソースコードを整理した理由。Ver2 系で、回転させるボタンが複数になった時から考えていたアイディアがついに実現されたわけだ。
バグ取りが減る。

CWAモードの充実

これもCWAモードがBTCモードの後発だったためか、どうしてもおざなりになっていたのが不憫で仕方が無かった。
だが、フローを分けたことによりCWAモードの動作の細かい所に手が届くようになった。「いいえ」ボタンを押してきちんとプリスキャンモードに戻れるようになった。
他にも今回、色々CWAモードを便利にするための工夫が込められている。例えばこれだ。

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

全てのオブジェクト全体が見えていますか?
もしズームしすぎているなら「いいえ」ボタンを押してください。

もちろん画面から見切れていても自動スキャンやトランスポーズマスター結合は正常動作するのだが、何だか気分が悪い。
だが、Fキーによる画面フィットは、1回押すごとにサブツールへのズーム⇔全体フィットが交互に切り替わる。この状態を取得する方法がない。なので、ユーザーがFキーを何回押したのか分からない。そこで、質問ダイアログを出し、Fキーを1回実施した後の画面の状態をユーザーに聞くダイアログを設置。これにより以後は画面に全体フィットさせた状態での処理が進むようにしている。トランスポーズマスターの場合は全体を眺めた状態で処理が進む方がユーザーにとって安心感があるだろう、との配慮。
なお、事前スキャン時にエラーを発見した場合には、エラーのあるサブツールにズームインする仕様なので、さらに分かりやすいという配慮。感動してもらいたい。

トランスポーズブラシを出しっ放しにする

当初、BTCモードではいちいちドローモードになってトランスポーズブラシが消える仕様でした。なぜならば、頭部パーツにキューブを仕込みそのキューブにアクションラインを引く想定だったからです。ですが、開発中のバグ取りではいちいちWキーを押さなければならずとても辛かった。そこで、標準ではトランスポーズを出しっ放しにする仕様に変更し、オプションとして「Hide TPbrush(TransPose brush)」ボタンを実装。これは通常OFFだが、これをONにするとVer.1 系の説明のように、毎回トランスポーズブラシが消える。

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

だが、人によってはトランスポーズブラシが出っぱなしの方がいいだろう。説明もしやすいし。なので、毎回トランスポーズブラシを消すのはオプションにより実現可能、というように仕様変更した。

実はトグルスイッチの実装に引っかかった

これも裏話なのだが。トグルスイッチ、リロードするとなぜか初期に戻る。ON/OFF状態が保持されない。なんて仕様。わざわざメモリ1つ確保してIF文を仕込まないと保持してくれない不親切仕様。そしてなぜか起動直後はクリック不可のDisableモードになっている仕様。どうやってそれを解除するのか(Enableにするのか)調べるのに2時間くらいかかった。謎仕様。だってPreferencesの通りにやってもDisableのままなんだもの。なぜ?Why?

トランスポーズマスター中のサブツール名

これも謎仕様。サブツール名の取得方法は分かっていたのだが、TM中のサブツール名がやたらと長かったのだ。

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

これが普通のサブツール名。当たり前だが普通に取得できる。だが、TM結合中のファイル名はこちら。

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

なぜかファイル名が40文字を大幅に超える80文字越え。サブツール名は40文字までしか入力できない仕様なので、データベースのメモリも40文字までにしていたから、そりゃはみ出てしまえば、そんな名前はDBにないよ、という判定になるよね。

で、色々試したところ、なぜかフルパスを含むファイル名にすると、両者とも「Tool:(ファイル名」」という文字列に落ち着く。なので、ファイル名取得関数のオプションを0から1に変更して、フルパスを取得する様に変更して実装。事なきを得た。

当初、わざわざDBのファイル名を200文字にまで拡張して対応させる方法も試したが、アホらしい気がしたので色々試したら上記の方法が一番スマートだった。なのでDBのファイル名の文字制限数は40+5、更に5文字だけ予備を加えて合計50文字分として確保している。
もし文字数の仕様が変わったら、どっちみちDBの文字数が変わるわけで、そうなると仕様変更だから諦めるしかない。だったらばなるべく小さなファイルサイズ&メモリサイズの方がいいだろうとの判断から40+5+5=50文字なのです。


結局、トランスポーズマスター中のファイル名と、スイッチの状態制御に引っかかったってのが一番大きな原因。ファイル名を指定して保存も少し引っかかったのだが、初の実装だったので多少の試行錯誤は許容範囲と言うことで。

全体的には、やはりソースコードの整理が効いていて、バグの原因をかなり狭い範囲まで絞れるようになったことが大きい。
ちなみに、Ver.2.3.1までは、単一の巨大なテキストファイルでした(笑)さすがに関数を探すのが大変だったので、今回はテキストファイルを分割し、インポートする形にしている。Referenceにそれができそうな記述があったので試してみたら上手くいったので。だが、それが仇となってトグルスイッチの罠にはまったのだが。
ファイル分割してみたら何と!おおざっぱに分けたつもりでも「8つのファイル」になっていた。それが元々1つだったわけだから、どこに何があるかわからなくなるのも仕方が無い。
2千行超えてました(笑)

今はだいぶ楽になった。おかげでCWAモードのフローを再整備できたわけで。

細かい配慮、地味にトランスポーズマスターの分解呼び出しボタン

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

これ、トランスポーズマスターの分解ボタンを呼び出すボタン。

f:id:yamato-tsukasa:20190208091322p:plain
これを押すのと一緒。

通常はCWAモードのStep3から自動で分解させられるんだけど、人によっては一度手動で加工した後に分解したい場合もあるだろう。だが、そのときにいちいちPluguin > Transepose Master を押すのも面倒だろう、との配慮から。

なぜ回転情報の記憶保持の上限が400個なのか?

Ver.2.3.2現在、ローカル軸の記憶数の上限は400個に設定している。別にいくらでも構わないのだ。400個設定してもHDDに保存されるファイル容量は6つ合計しても1MB未満である。ほとんどゴミファイルみたいな容量だ。なので別に何個でもいいのだが、一応根拠がある。当初、200個で実装していた。とあるユーザーからの情報で、サブツールは大体50個は使っているとのことなので、倍の100個もあれば安心とのこと。なので更に倍の200個もあれば十分だろう、と思っていた。

だが、DBという性質上、不要データが必ず発生する。例えば、一度BTCした後にサブツールを削除してその名前を二度と使わない場合、その回転情報は名前とともにDBに残って消えない。一般的に、データベース管理では、コンパクションといってデータベースを圧縮・再構築する処理が行われる。だが、これを実装するとなるとこれまた大変。

そこで、記憶可能容量をさらに倍の400個まで拡張する代わりに、コンパクションを諦めたわけだ。今の実装では、確かに名前の見当たらない謎領域はスキップされるのでDB内の記憶可能容量は消費し続けることになる。だが同じ名前が見つかった場合には対応するDB箇所にデータが上書き保存されるので、実際に運用していて無限にDBを消費し続けることはない。なので、意図的に「サブツール名を純正ツールで変更してBTCし、更にサブツール名を純正ツールで再び変更する」ようなことを繰り返さない限り、400個分のローカル軸の保存領域が消費し尽くされる可能性はほぼ無いと思っている。

ツールとしては完成形だと思う

もう拡張できる機能がない気がする。入出力系、操作系、回転エンジンの堅牢化、強化するところがない。後はちょこちょこっと利便性の向上くらいだと思う。ツールとしては完成したと思っている。これ以上シンプルにできない。使い勝手を向上させるのみだろう。
シンプルかつ使いやすくて強力、これがツール開発当初のコンセプトだったから、ゴールに達した気がする。

恐らくは大きなバグも出てこないだろう。内部コードを読んでみてもスッキリしているから、そうそう大きなバグは入っていないはずだ。
あとは堅牢に動いて多くの人に驚きと感動を提供できれば嬉しいと思っている。

Zbrushの可能性が大きく広がった。
BTCはそういうツールになったと確信している。



平成31年2月8日(金)8時58分21秒(笑)

大和 司