見出し画像

【開発秘話】Zbrushプラグイン「YT マスクセーバー」公開記念🎉

今日、全機能を無料で使える無料体験版をBOOTHで公開しました。またこのプラグインに関する全ての情報は以下のページに書いています。

書きたいことは山ほどあるけど、一晩寝て起きて考えたら、ま、いっか、となった😊


今回のZbrushプラグインは、Pythonが9割、AutoHotkeyが9%、残り1%がZscriptでできている(概算値)。主要な処理のほとんどはPythonで記述した。なので主要な実行ファイルもexeファイル。そして難読化exe作成でも大変だった。

だがPythonを使ったことでZscriptだけではできないたくさんのことができるようになったし、同じ実装でもPythonの方が短いコードでスッキリスマートに実装できた。

(約 4,500文字の記事です。)



今回の開発テーマは結構多かった

今回のZbrushプラグイン開発は私にとっては大きな転換点だった。そして1本作り上げて色んなことを学んだ。全部次に生かせる😊

今回の開発のテーマは、実は機能そのものではなくて以下が目的だった。

  1. 次に使える(使い回せる)価値あるソースコードの資源化

  2. 一般的なソフトウェア開発アプローチの採用

    • PyCharmやVS Codeといった統合環境の利用

    • Gitによるバージョン管理

  3. 開発時期に依存せずに改良や継続開発システムの採用

  4. Webページの更新とPush型の通知システムの採用

  5. 無料版と有料版の使い分け、ユーザーへのアピール方法の使い分け


次に使える(使い回せる)価値あるソースコードの資源化

これはズバリ脱Zscriptの最大の理由。Pythonというメジャー言語を選んだ理由でもある。長期的なプログラミング経験を積む上で、過去に苦労して作り上げたソースコードを未来に生かしたい。そのためには言語はメジャーな方が有利だ。Pythonの将来性は十分だろう。ここには議論の余地がない。

なおZscriptはZbrushプラグイン開発に必須なので避けようがない😖


AutoHotkey実はこれが結構くせ者だった。だがPythonでは手を出せない「他者製ウィンドウの制御」これに絶対に必要だった。AutoHotkeyもv2になってかなりPythonっぽいというか、イマドキのプログラミング言語っぽくなっている。なので実はPythonでもAutoHotkeyでもどちらでも実装できる内容が結構多かった。だが前述の理由で「両方でできるならば可能な限りPythonで実装」にこだわった。AutoHotkeyよりもPythonのほうがメジャーな言語と言えるので。

だがAutoHotkeyのメリットとして他者製ウィンドウの制御がある。これは強い。Zbrushに限ってはZscriptしか使えないが、Zbrush以外ではAutoHotkeyなしでは立ちゆかない場面がある。Pythonでは無理。

結局PythonとAutoHotkeyとZscriptの三者を使うことで今回のZbrushプラグインを実現させている。当然ながら大変だった。二者連携ならまだしも三者連携なので大変だった。

10日でアルファ版を作って5日かけてリファクタリングと再設計。2週間かけて作り直し。つまりはほぼ1ヶ月かかった。


一般的なソフトウェア開発アプローチの採用

PyCharmとVS Codeを使ってIDE環境でコーディングをし、Gitを使ってバージョンを管理するという、ごく普通のソフトウェア開発手順に従って作ってみた。餅は餅屋。IDE環境は効率がとてもいい。そしてGitとの連携も抜群。commitとbranch, margeによる枝分かれと合流の流れ。その間をタイムリープするようにソースコードを秒で変更して閲覧できるGitの強さ。

プログラミングは実はメモ帳があればコーディングはできる。

だが作業効率を考えると最悪だ。IDE環境と構文ハイライトの強力さには勝てない。ある程度の規模のソフトを作ろうと思うと、さすがにテキストエディタオンリーというのは無謀すぎた

ソースコードは機能拡張と共に膨れ上がる。そうなったときにIDEの強力なサポート機能がないと、すぐに破綻する。

実際問題、私の過去のZbrushプラグインはある時期から更新がピタリと止まっている。理由は幾つかあるが、ソースコードの保守性が限界値を超えてお手上げ、という状況。

テキストエディタだけでの開発の限界は割と天井が低かった。ここを打破したかったし、そもそもZscriptの限界も感じていたので。

なのでPython+PyCharmで始めたわけだ。


開発時期に依存せずに改良や継続開発システムの採用

Gitを採用した理由として、Ver.1の公開後の追加のメンテの追跡性、これが欲しかった。というのも熱くなって開発した1~3ヶ月程度はすべて頭に入っているので拡張や変更が容易。だが半年もすれば全部忘れている😭。そうなったときの、つまり「時間を空けたあとでも問題なくメンテや維持の開発ができる仕組み」が必要だったわけ。

今回はGitを採用したのでそれもしやすくなった。開発途中もbranchを分けてゆっくり開発しつつ、リリース版のマイナーバグはすぐに潰せる。頃合いを見計らって開発版をリリース版にマージすればいい。ゆっくり確実に、記憶に頼らずに開発を前に進めることができる。Gitを学んだ甲斐があった。


Webページの更新とPush型の通知システムの採用

今回のプラグインから、Zbrush起動後の初回の特定ボタン押下時に、強制的にWebページの更新状況を取得してポップアップを表示させるシステムを導入できた。「更新情報があるけど、Webページを開く?」という二択ダイアログ。これでプラグインユーザーに確実にアプローチできる。開発者主体で能動的にユーザーにプッシュ型アプローチができる点。この仕組みが欲しかった。

これによってSNSでの公開に依存せずに、プラグインユーザーに確実にアプローチできる。二択ボタンなのでユーザーが忙しいときにはWeb閲覧をスキップできる。仕事が一段落したときにでもInformationボタンからウェブページを開ける。

このプッシュ型通知の仕組みを導入できたのもPythonのおかげ。


無料版と有料版の使い分け、ユーザーへのアピール方法の使い分け

今回の公開は色々考えて二転三転した結果、期間限定ですべての機能を無料公開することにした。

最初はMask Save, Loadの2ボタン版のみ無料版とし、他の9個のマスクボタンは有料版で公開予定だった。

だがPyarmorを使えばexeの利用期間をこちらから一方的に制限できることを知った。今回はお盆明けの8月16日までの期間に制限してexe化した。なのでVer.1.0.0を、誰がどこから入手しても8月17日以降に使うことはできない。Pyarmorによって開発者による能動的な「利用可能なバージョン管理」をユーザーに強制できることになった。この恩恵も大きい。

なのでまずはお盆明けまでフル機能を、興味のある人に触ってもらい、8月17日以降でも使いたい人は有料版を買って欲しいし、1組のマスクの保存と復元で十分だと思った人は無料版を使えばいい。

開発者としては8月16日までに、別の期限を切ったVer.1.0.1以降をリリースすればいいだけ。

この手法で行けば、「今だけは大盤振る舞いで無料公開したいが、かといって永遠に無料で使い続けられると困る、だが公開したい😖」というジレンマがなくなる。なので気軽に高性能な無料版を期間限定で公開できる。開発者としても気軽に打って出て、ユーザーからの反応に応じて柔軟に次の版の有料・無料版の内容を検討できるようになった。


【まとめ】継続開発と継続リリースに向けて

CI/CD, Continuous Integration / Continuous Delivery & Deployment.

継続的な統合 / 継続的な配布&公開。要するに継続的に機能拡張を続けることと、継続的にソフトをリリースしていくということだ。今回のテーマはここに集約される。「今までのような使い捨て」ではないソフトウェア資源の開発と過去資源の価値の向上、これをプラスのループでグルグル回すための、根本的な開発アプローチの見直しと刷新。

そのためのテストケースとしての、Zbrushプラグイン開発だった。

なので別にマスクに限らず、Zbrushプラグインなら何でもよかった😊。今回はたまたまとっかかりがマスク情報の抽出と外部ファイル化と再読み込みだったというだけ。

ちなみにマスクの抽出と再読み込みの発想自体は5年前にあったが当時の実力ではZscriptのみではどうしても突破できない問題があったので断念して寝かせていた。だが今回、5年越しにそれを打ち破ることができた。

そういう意味ではとても感慨深いチャレンジだった😍

このチャレンジで、

  1. Pythonによるバイナリファイルの取り扱い

  2. PythonとZscriptとAutoHotkeyとの連携方法

が分かった。そしてWebサイトからの情報取得と情報処理もできるようになった。

あとは他のZbrushプラグインではその「メイン処理内容が変わるだけ」で、他の仕組みは使い回せる。ソースコードの資源化の価値が次以降から雪だるま式に増えていくのだ。

それらをGitで管理していけば、開発期間に空白があってもとっちらからない

これはつまり、臨機応変に開発中のプロジェクトを切り替え運用できることを意味する。TPOに応じて「今」対応すべき案件に切り替えられるということ、その後に元に戻れるということ。

そしてその手法はZbrushプラグイン開発に限らず、Blenderのアドオン開発やWindowsのGUIアプリ開発でも使える。何にでも共通する手法の確立。これでまた雪だるま式に効率UPできる。


今回はその挑戦の第一弾だった。無事に完成した😊



乾杯🍺


今回の創作活動は約1時間(累積 約3,878時間)
(1,126回目のnote更新)

筆者はAmazonアソシエイト・プログラムに参加しています。(AmazonアソシエイトとはAmazon.co.jpの商品を宣伝し所定の条件を満たすことで紹介料をAmazon様から頂けるという大変ありがたい仕組みのこと。)
以下のリンクを経由してAmazonでお買物をするとその購入額の1~3%ほどのお小遣いが私に寄付されます。誰が何を買ったという情報は私には通知されませんのでご安心下さい😊 以下のリンクを経由して頂ければ紹介商品以外のご購入でもOKですよ~。


さて、明日から何をしようか、ネットは広大だわ……。



読んでくれてありがとう。気長にマイペースに書いてます。この出会いに感謝😊