BIM・IFC・USD の基礎

koyu の位置づけを述べる文章は、この分野の語彙を前提にしている。この頁はその語彙だけを説明する。建築情報の実務に慣れている読者は IFC・USD との比較へ飛んでよい。

BIM

Building Information Modeling — 建物の三次元形状と属性情報を一体で扱う手法。

実務では Revit や Archicad といったオーサリングツール (設計者がモデルを作成するソフトウェア) が中心にあり、モデルの実体は各ツールの独自データベースの中にある。

ここが koyu との一つ目の分岐点である。原本がツールの独自データベースにある限り、モデルにできることはそのツールの UI と API が許す範囲に限られる。テキストの原本なら、その制約は無い。

IFC

Industry Foundation Classes — buildingSMART が策定する交換用のオープン標準。BIM ツールの間でモデルを受け渡すための共通語である。

標準的なシリアライズ形式は SPF (STEP Physical File、拡張子 .ifc) で、次のような姿をしている。

#42=IFCWALLSTANDARDCASE('1a2b3c...',#5,'Wall-001',$,$,#43,#51,$);
#43=IFCLOCALPLACEMENT(#12,#44);

行番号でエンティティを相互参照する。この一点が版管理に効く — 同じモデルを書き出し直すだけで行番号が振り直され、ファイル全体の差分が壊れる。どのファイルを最新とみなすかは、データではなく人の運用が決めることになる。実務の CDE (共通データ環境) も、突き詰めればその運用の器である。

規模の目安として、IFC のスキーマ (IFC2x3/4/4x3 統合) は約 1,140 のエンティティを持つ。うち幾何・形状表現系が約 250、構造解析系が約 45、設備系が約 150、土木系が約 50、関係を表す IfcRel* が約 60 である。

IfcSpace

IFC において室や領域を表すエンティティ。規格上は存在する。

しかし多くの現場では、部材が囲んだ結果として導かれる二次的な情報として扱われ、書き出されないことも珍しくない。空間境界を表す IfcRelSpaceBoundary は規格にあるが、境界の接続ジオメトリが省略されることが最も多い箇所でもある。

koyu の主題はここを一次要素へ格上げすることである。IfcSpace が二級市民であり続けているのは規格の不備ではなく、形を原本にしたことの帰結である (空間中心のモデル)。

IFC5 と IFCX

現在開発中の次世代規格が IFC5 で、そのファイル形式が IFCX である。

IFCX は素の JSON を採る。ノードは { path, children?, inherits?, attributes? } だけの小さな構造で、children が名前 → UUID の辞書として階層を張り、inherits が USD の reference 相当としてプロトタイプ (窓インスタンス → 窓の型) を参照する。属性の語彙は bsi::ifc::prop::FireRating のように名前空間で切られる。

そして合成 (composition) を持つ。同じパスのノードを複数書けば重なり合い、ファイルをまたいでも同じ機構で上書きできる。差分レイヤーが数百バイトで書けることが、この機構の価値のすべてである。

形式の問題は、標準の側で解かれつつある。テキストになり、差分が読めるようになり、レイヤーが重なるようになった。

しかしその形式が運ぶ中身は、依然として建築物のオントロジーである。場面の主語は IfcWall のままで、ファイルの大半は頂点座標列 — つまりビルド成果物がソースに同梱されている分 — である。形式の刷新は、対象の取り替えではない。

OpenUSD

Universal Scene Description — もともと映像制作のために作られたシーン記述の枠組み。composition (合成) と呼ばれる仕組みを中核に持つ。

複数のレイヤーを重ね、上のレイヤーが下のレイヤーの値を非破壊的に上書きする。パス名前空間 (/World/Building/Room) が背骨になる。

現在の IFC に相当する概念は無い。そして USD の側には建築の意味論が無い。

建築の意味論を持つ形式は合成を持たず、合成を持つ形式は建築の意味論を持たない。

koyu が両方を持とうとしているのは、この空白に対してである。ただし USD から借りるのは機構だけである — パス名前空間を背骨にしたレイヤーの非破壊的な重ね合わせ、名前空間つきの語彙、外部レイヤー参照の発想。借りないのは UUID を主キーにした同一性 (koyu は人間可読パス)、メッシュの同梱 (形は生成物)、そして建築物のオントロジーそのものである。

オントロジー

ある領域に何が存在し、それらがどういう関係にあるかを形式的に定義したもの。

koyu の主題はまさにこの問い — 建築において何を「存在するもの」として数えるか — そのものである。IFC は部材を数える。koyu は空間と、その間の関係を数える。

近い形をした既存の体系がいくつかある。

W3C BOT (Building Topology Ontology) — bot:Space と bot:Interface (二つの Zone の界面) を持つ。koyu の境界は bot:Interface の、人が書ける表面記法だと言える
IndoorGML — セル空間と双対グラフ
CityGML / PLATEAU — 都市スケールの三次元都市モデル

近さは隠すべき弱点ではなく、設計上の狙いである。近い形をしているからこそ、それらへの射影が自明になる。

建築と建築物

日本語は建築と建築物を区別する。

建築物は建築基準法上のカテゴリであり、物としての対象である。IFC も CityGML も、規格の名が示すとおり (IfcBuilding)、この側のオントロジーである。

建築の側 — 空間の分節・接続・序列 — は、そこに含まれていない。空いているのはこちら側である。

英語には対応する語の区別が無いので、koyu の英語の文書ではこれを "the building" と "architecture" で書き分けている。

BIM​

IFC​

IfcSpace​

IFC5 と IFCX​

OpenUSD​

オントロジー​

建築と建築物​

この先​

BIM

IFC

IfcSpace

IFC5 と IFCX

OpenUSD

オントロジー

建築と建築物

この先