実プロジェクトでの Grasshopper 反省会 #1 _ Transform や Entwine を利用しコードをまとめよう

有識者の方からはそんなの当たり前でしょと言われてしまうような気もしますが、今回は Transform コンポーネントや Entwine コンポーネントを利用しコードをまとめようという記事です。シリーズになるかは未定ですが、実際のプロジェクトでの失敗を書いてみます。

前提

まずは画像を。

直線部材の組み合わせで構成された形状で、それぞれの部材には構成要素として3種類の要素があります。

部材の芯線
部材の形状
部材に加工する穴位置のポイント

さらにいくつか画像を見てください。

こちらの Grasshopper では、芯線より、移動や回転を計算し、その情報を部材の形状や穴加工位置にも展開して、部材の並べ直しを行っています。

このGrasshopper の書き方はどうでしょうか？

特段読みにくいこともないので個人的には許容範囲内かなと思っています。図形を書きながらスタディするための半ば書き捨てのプログラムであれば全く問題がないと思います。

しかしながら、少しずつアップデートしながら運用するという観点で見ると、上の画像のような書き方では不十分な場合があるということを実感しました。

反省

この書き方の良くないところは、主に2点あるかと思います。

1点目は、部材の要素が増えたときに移動や回転を適切に複製する必要があること。もう1点は、移動や回転を追加するときに複数の部材の要素に対して同じように間違いなく線を繋ぎなおす必要があることです。

どちらの場合もつなぎ直しの手間と、そこでのミス発生のリスクが大きいかと思います。

実際にこのプロジェクトでは、穴に対して取り付けるファスナーに複数のバリエーションがあり、そのファスナー形状をチェック用に記入する方が良いというのが途中でわかりました（部材の要素の追加）。さらに別の都合で最終的な配置を調整したいので移動を追加したいというのがありました（移動や回転の追加）。

このプロジェクトでは、途中で特に整理もせずだましだまし追加対応をしていて、終盤には何をするにも非常に辛い状況になりました。（大半のプロジェクトでは後半になるほど役物の存在もわかってきて、対応すべきバリエーションが増えます。。。）

書き直しにトライ

これらを踏まえ、変換行列にまとめてアフィン変換（Affine Transformation）で処理するように書き変えてみます。要素の整理に Entwine コンポーネントを利用してみます。

長くなるので細かな解説は省略します。

アフィン変換（座標変換）に関して前提知識として

和歌山大学の床井先生のこちらの資料などわかりやすいです。必要があればこちらを参照してください→ https://tokoik.github.io/gg/ggbook03.pdf

それを踏まえて Grasshopper の前提知識として

Grasshopper において変換行列は Transform 型として扱う
アフィン変換は Transform コンポーネントで行う
Transform コンポーネントの入力は、ジオメトリと変換行列の2つ
Move や Rotate の出力の X からは変換行列が出力されている
変換行列の合成は Compound コンポーネントで行う

書き直してみた結果はこちらです。

やっていることは全く同じですが、芯線を操作して Move、Rotate から出てくる変換行列をまとめて（上のグループ内）、それを Entwine でまとめたものに適用しています。

こうすることで、部材の要素が増えても Entwine へつなげば OK で、Move や Rotate が増えても変換行列を求めている箇所の中での変更で簡単に対応することができるはずです。

ここまでのファイルをこちらにアップしています。

github.com

実際のプロジェクトファイルのリファクタリング

以上を踏まえて、実際のプロジェクトファイルの一部をリファクタリングしてみました。

リファクタリングの過程で読み直しつつコンポーネント同士の間隔を広げたり、線を集約したりしているので一概には言えませんが、画像の中央やや左あたりがだいぶすっきりしたのがわかるかと思います。

右側ではまた別の問題がある気がするので、これから検証します。。。

まとめ

今回は、実プロジェクトの中でプログラムを継続的に運用してみて気が付いたコーディング Tips を挙げてみました。一度理解してしまえば簡単なことなので改めて記事にするほどでもないような気がしますが、いつか未来の自分含め今後に向けて今回の失敗についてまとめてみました。次に来るであろう類似の事例ではまずこの記事の共有から始めようと思います。

チームとして目先の進捗と運用のコストの天秤として正しい判断ができるか？というマネジメント的な課題も見えてきたので、こちらもあらためて振り返りをして言語化できればと思っています。

vicc では、Grasshopper の書き方一つからプロジェクトの進め方までガンガンカイゼンしていきたいぜというカイゼンバイブス溢れるエンジニアを募集しています。興味を持たれた方は下記よりお問い合わせください！！

vicc.jp

終わり