BIM・IFCブログに戻る
Web上でのIFCのレンダリングは、すでに解決済みの問題です。ただし、それはライブラリが前提としているパターンに従った場合に限ります。素朴なアプローチ（.ifcを読み込み、解析し、メッシュを構築する。これを毎回行う）を試した開発者は、最初の実務モデルで壁にぶつかります。WebAssemblyがファイルを処理する間、タブが1分以上フリーズするのです。解決策は、より速いパーサーではありません。一度だけ解析し、二度と解析しないことです。
技術スタック
web-ifc
That Openが開発したWebAssemblyのコアで、ブラウザーやNode上でネイティブに近い速度でIFCを読み書きします。他のすべての土台となるライブラリです。
Fragments
That Openが開発した、最適化されたジオメトリ形式です。IFCからFragmentsへの変換は一度だけ行い、以降は.fragを読み込めば、IFCを再解析するよりも圧倒的に高速です。
three.js
シーンを描画するWebGLレンダラーです。Fragmentsはthree.js互換のジオメトリを生成するので、他のメッシュと同じようにシーン、カメラ、コントロールに追加できます。
素朴なアプローチ（と、それが問題になる理由）
import * as WebIFC from "web-ifc";
const api = new WebIFC.IfcAPI();
await api.Init();
// Parsing the raw IFC at runtime — fine for tiny files, painful for real ones
const data = new Uint8Array(await file.arrayBuffer());
const modelID = api.OpenModel(data);
// ...extract geometry, build meshes... (slow, blocks the main thread)
本番向けのパターン：一度変換して、何度も読み込む
- IFCからFragmentsへの変換は1回だけ行います（アップロード時、ワーカー内、またはビルドステップで）。
- .fragの出力を、キャッシュ、OPFS、オブジェクトストレージなどに永続化します。
- 以降の読み込みでは、毎回Fragmentsを取得して描画するだけで、IFCの解析は一切行いません。
- 重い処理はWeb Workerで実行し、メインスレッドの応答性を保ちます。
import * as OBC from "@thatopen/components";
const components = new OBC.Components();
const fragments = components.get(OBC.FragmentsManager);
const ifcLoader = components.get(OBC.IfcLoader);
await ifcLoader.setup();
// First time only: IFC → Fragments
const model = await ifcLoader.load(ifcBytes);
// Serialize once, reuse forever
const frag = fragments.export(model.group);
await saveToCache(frag); // OPFS / IndexedDB / server
// Subsequent loads: skip IFC entirely
const cached = await loadFromCache();
fragments.load(cached); // fast
よくある落とし穴
- 「memory access out of bounds」：大きなファイルで、web-ifcのWASMがメモリ不足になっています。ワーカー内で変換する、利用可能なメモリを増やす、または分割して処理してください。
- 原点から遠いジオメトリが揺れる：実際の地理座標でモデリングされたモデルは、浮動小数点の精度を失います。ローカル原点に基準を移してください（「IFCの座標がずれる」を参照）。
- サーバーサイドレンダリングはできない：web-ifcはブラウザー／Node上で動作するもので、JavaScriptを使わないSSRのステップとしては動きません。リクエスト時のSSRではなく、クライアントサイドでの処理か、ビルド時の変換を前提に計画してください。
- 読み込みの最適化：大規模なモデルはタイル化とカリングを行い、カメラの近くにあるものだけを描画します（「大きなIFCファイルでブラウザーがクラッシュする理由」を参照）。
あるいは、自分で作らないという選択
これはまさに、このビューアーが実行しているパイプラインです。解析にはweb-ifc、Fragments方式の一度だけの変換ステップ、2回目以降の読み込みを約10倍高速にするOPFSキャッシュ、そしてその上に検証機能を載せています。目的がビューアーを作ることではなく、IFCを表示してチェックすることなら、開発の手間を省いてファイルを開くだけで済みます。
パイプラインの動作を見る
本番規模のIFC4モデルを、まさにこの「一度変換してキャッシュする」パイプラインで読み込みます。開いたあとで再読み込みしてみてください。2回目の読み込みはほぼ一瞬です。
IFC4 · 14 MB
インタラクティブなIFCビューアーを開く
自分のページに埋め込む
IFCを公開された場所（CORSを有効にしたバケット、リポジトリのrawリンク、共通データ環境（CDE）など）に置いていれば、このビューアーをそのまま、ブログ記事、ドキュメントページ、CDEのパネルにiframe1つで埋め込めます。ビルドステップは不要です。下にURLを貼り付け、レイアウトを調整して、スニペットをコピーしてください。モデルは訪問者のブラウザー内で取得されるため、私たちのもとには何もアップロードされません。
IFCの埋め込みコードを作成
公開されているIFCのURLを貼り付け、レイアウトを選んで、iframeをコピーします。ライブプレビューは入力に合わせて更新されます。
IFC Viewerを開く
three.js、web-ifc、FragmentsでブラウザーにIFCを表示する方法
