vicc blog

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

なぜRhinoではUser Textで情報を保持するべきなのか？

Rhinoceros BIM 生産設計BIM

RhinoをBIM目的で使う場合、情報モデルを構築するためにどこかでデータを保持し、それをテーブルとして切り出せるようにしなければいけません。
いにしえの技でObjectやLayerの名前だけでツリー状に管理するというやり方がありましたが、 より現代的な手法としてAttribute User Textで情報モデルを構築する方法と他の手法を比較してみようと思います。

User Text の概略

Rhinocerosの内部でオブジェクトやファイルに対して情報を記載する機能です。

ファイルのUser Textはドキュメントのプロパティから見れます。今回の記事では触れません。

Document User Text

オブジェクトのUser Textはここにあります。今回の記事ではこちらについて書いていきます。

Attribute User Text

Attribute User Text の実例

User TextやKV、User Stringなどと呼称される文字情報はハッシュマップ形式で保存されます。
ハッシュマップが何か、どんな良さがあるかはChatGPTにでも聞いてください。
ハッシュマップなので一つのKeyに対して一つのValueを持ち、Keyの重複は許されません。
Keyは複数のオブジェクト間で共通、Valueは固有（ただし、重複をゆるす）と考えてください。
おそらく、我が社のメンバーという卑近な例を示したほうが帰納的に理解が進むでしょう。

Object 1
Key Value
背番号 012
NAME Kantaro
SURNAME Makanae
INITIAL_LETTER KM
Object 2
Key Value
背番号 345
NAME Kazuki
SURNAME Matsuya
INITIAL_LETTER KM

ひとによって背番号だったり、出席番号だったり、囚人番号だったりするとなんの役にも立ちません。
が、共通で背番号なので整列させたりどちらが部屋に先に入ってくるかがわかったりします。
Valueは場合によっては重複することができるのもわかると思います。
たとえばイニシャルがKMの人は二人いる可能性があります。

また、Rhinoの他のプロパティ(Name、 Material、 Layer)とは異なり、
一つのオブジェクトに対して複数のKVが並列的に定義可能なことが大きな特徴です。

アンチパターンも示しておきます。

Object 2
Key Value
背番号_345 TRUE
NAME Kazuki
SURNAME Matsuya
INITIAL_LETTER KM

背番号_345に注目するシーンが他の背番号に対してきわめて多いなど特殊な事情があれば別ですが、 ほぼすべての人でValueがFALSEになるうえ、背番号順に並べる際にもつかえないし、いいことがありません。
このようなKeyの付け方は避けましょう。

User Textで情報を付けたい理由

さて、User Textで情報が書けるのはなんとなくわかりました。

一方でKeyもValueも文字だけなので把握しにくく、またインターフェースも奥まった所にあるので、ともすると

「何もかもLayerだけで管理できる方法を考えるべきだ！」

と主張する人が出てきます。

また、Rhinoの場合はNameというのもあり

「LayerとNameで事足りるんじゃない？」

いう人もいるでしょう。

そういう考えの人もいるかもしれませんがここで一石を投じたいと思います。

まず何もかもLayerで管理しようとすると必ずぶち当たるのが、
多重入れ子になった深すぎる階層のLayerによる人為的ミスやコミュニケーションコストの増大です。

例えば建材と所属する部位によってLayerを構成しているとします。

  • ZONE_A
    • MATERIAL_GLASS
    • MATERIAL_STEEL
    • MATERIAL_ALM
  • ZONE_B
    • MATERIAL_GLASS
    • MATERIAL_STEEL
    • MATERIAL_ALM
  • ZONE_C
    • MATERIAL_GLASS
    • MATERIAL_STEEL
    • MATERIAL_ALM

このLayer構成で、STEELだけ、ALMだけ表示したいというシーンを想像してください。 Layerパレットをポチポチ押していくのがだるいですね。

ちょっと詳しい人は「Layer State Managerで*::MATERIAL_STEELだけ表示した状態を保存しよう」というアイディアを出してくるかもしれません。
しかし、Layerが完全に固定された状態でないとその作戦はつかえません。
なぜなら、日々建材が追加されたり、別の階層で管理される要素が出てくるとちまちまLayer Stateを編集しないといけないからです。
一週間もたてばこんな感じになります↓

  • ZONE_A
    • MATERIAL_GLASS
      • 20230115承認
        • t12
          • 飛散防止フィルムあり
          • 飛散防止フィルムなし
        • t18
      • 20230214承認
    • MATERIAL_STEEL
    • MATERIAL_ALM
  • ZONE_B
    • MATERIAL_TIMBER
  • ZONE_C
    • MATERIAL_GLASS
      • 20230115承認
        • 飛散防止フィルムあり
        • 飛散防止フィルムなし
          • t12
          • t8-8(Low-e)
      • 20230214承認
    • MATERIAL_STEEL
    • MATERIAL_ALM

なんて面倒くさいんだ…しかし実務ではこのようなことは避けられません。ZONE_AとZONE_Cで微妙に構成の順番も違うあたりにもこの作戦のダメさがにじみ出ています。

これに対してUser Textで管理すれば

  • ZONE
  • MATERIAL
  • 承認日
  • 飛散防止フィルムあり
  • ガラス厚

のそれぞれを読み書きすることで管理できます。
簡潔ですね。
Layerと違うのは階層性がなく並列に様々なプロパティを保持できる点です（大事なことなので二回目です）。

必要に応じてKeyごとの集合の加減乗除を行えば階層性のある操作も可能です。
Layerの場合は事前に合意された順序で見なければいけませんが、User Textであれば任意の順番で絞り込めます。

Zone=A
  >Material=Glass
  >t=12

または

t=12
   >Material=Glass
   >Zone=A

一方で、User Textで保持されている値は人間の視認性は高くありませんし、
表示/非表示、Lock/Unlock、表示色の変更などもLayerの方が手数が少ない感があります。

Layer原理主義とUserText原理主義を止揚するのであれば、
いくつかのパターンでUser Text からLayerを錬成するGHなりスクリプトを書いて、目的ごとにLayer構成を変換してあげることになります。

長くなってきたので具体的な操作は別記事に譲り、趣旨説明でこの記事は終わろうと思います。 おしまい。

最近のコメント

ryuyu 読者になる

関連記事
コメントを書く