vicc blog

株式会社ヴィックの技術ブログです。

実プロジェクトでの Grasshopper 反省会 #5 _ 計測結果を Dot だけで置かない

ヴィックの吉岡です。相も変わらず、反省会シリーズです。

blog.vicc.jp

今回の記事では、過去のプロジェクトでマネージャーから背景の説明とともに指示として伝えられていたことについて、直近のプロジェクトでなるほどこういうことですねと身をもって実感したのでそれについて書いてみます。

はじめに

読者の方の中でも Grasshopper 上で長さを計測し、計測結果の数値を Dot として Bake したことがある方もいると思います。Dot を Bake することで、一目で数値を確認することができるので一見とても便利なように思えます。僕もついついこれでやってしまうことがあります。

丸孔からのへりあきの距離を調べる例

しかしながら、大量のファイルを連番処理したのち、Dot で数値が記されている状況に恐怖を覚えたので今回は記事にしてみます。

Dot だけで計測結果が残っている状態の恐怖

Grasshopper で数値を計測してその結果の数字だけの状態であると、どの箇所の計測を行ったのか後からではわかりません。Grasshopper でのアルゴリズムが完璧で、ソフトウェアのエラーも起こらなければ問題は無いのですが、絶対に正しく動く Grasshopper を書くというのはなかなか難しいと思います。

例えば、

  1. 前工程で作成されたポリサーフェスを分解する
  2. サーフェスをフィルタリングしてソートする
  3. 計測したい箇所を取り出す
  4. 計測する
  5. 計測結果を Dot として Bake する

という処理があったとします。ここでは、計測箇所の抽出と、計測と結果の出力といった大きく2つのステップがあると言えます。

計測箇所の抽出の作業では、前工程で作成されたポリサーフェスがものによって面の数が異なる場合があることや、XYZ の値でソートしていた箇所で形状によってソート順が異なってしまうことにより、計測すべき箇所を取り違えるという事が安易に想像できます。

面の数を数えて処理を分けましょう等、アルゴリズムで解決できる部分も多いはずですが、建設プロジェクトにおいて役物も発生しますし、建設プロジェクトの中でのデータ作成においてバグを絶対に作らないような堅牢な開発スタイルで進めることは多分コストが合いません。

世の中のソフトウェアが内包されるプロダクトのシステム開発のように、仕様書を書いて開発してテストしてという開発スタイルであってもどこかではエラーが起きていますし、エラーが絶対に起きない仕組みということは有り得ないと認識すべきでしょう。

が、コンピュータを用いた機械の処理というものがそういう面を持ち合わせているならば危険なのでコンピュータを使うのを控えましょうというのもナンセンスだと思います。どうすればよいのでしょうか?

これに対するアイデア

今回の件に関していうと、計測する箇所のオブジェクト、例えば部品の長さを測る場合はその箇所のカーブといった計測の対象となる中間生成物を Dot と合わせて Bake するということで解決できる部分があると思います。

計測する箇所をカーブとして作成した

Dot だけが Bake されている状態の恐怖というのは、Grasshopper でなんらかの計測箇所を抽出して、計測を行うというプロセスのうち、なんらかの計測箇所を抽出する部分に関して、Grasshopper の実行プロセスの中でしか確認できないので後から確認することができないことにあります。

計測結果として出力されている Dot の数値が変という場合に Grasshopper を開かなければ一切の状況がつかめませんし、一見妥当な数字に見えても間違った箇所を抽出して計測をしていて偶然それっぽい数値になっているということも十分起こり得ますが、それに気づくことも難しいです。

計測する箇所のオブジェクト、例えば部品の長さを測る場合はその箇所のカーブといった計測の対象となる中間のデータを Dot と合わせて Bake することにより、そのオブジェクトを確認することで計測が正しい箇所で行われているか確認することができるはずです。

計測箇所の抽出を間違えていても、中間生成物によりミスに気が付きやすい(真ん中)

中間生成物がファイルに残るのが嫌という場合は連番処理でクリーニングするということも簡単にできるはずなので、これは大きな問題ではありません。

まとめ

今回の記事では、一見便利な Dot を Bake することでの結果の確認に関して、知識として理解していたことを自分であらためて実感したので、ブログの形で書き起こしてみました。また、今回の記事のモチベーションとしては、過去のプロジェクトで先輩から教えてもらって確かにそうした方がいいですねと当たり前でやっていたことが、社内の別のプロジェクトには共有されていなかったということもあります。社内の打ち合わせでこの話をしつつ、この記事がどこかの誰かの事故を未然にふせいでくれれば嬉しい、ということでここで記事は終わります。

さて、Value の1つとして We are sharing and growing together. を掲げている vicc では、日々の学びを仲間に共有し組織として強くなることを志すエンジニアを募集しています。興味を持たれた方は下記よりお問い合わせください。

vicc.jp

(終わり)