[G1-Sync] Manual knowledge update
This commit is contained in:
@@ -2,75 +2,159 @@
|
||||
id: wiki-2026-0508-ifcjs-fragment
|
||||
title: IFCjs (Fragment)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-8A58BF]
|
||||
aliases: [IFC.js, ThatOpen Fragment, web-ifc, BIM web viewer]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [bim, ifc, threejs, web, fragment]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[IFCjs|IFCjs]] (Fragment)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: TypeScript
|
||||
framework: Three.js, web-ifc, ThatOpen Components
|
||||
---
|
||||
|
||||
# [[IFCjs (Fragment)|IFCjs (Fragment]]
|
||||
# IFCjs (Fragment)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Fragment는 대규모 3D 기하학적 환경을 효율적으로 렌더링하기 위해 IFC.js 개발자들이 고안한 하이브리드 최적화 시스템이다 [1, 2]. 이 시스템은 단일 인터페이스 내에서 로우 폴리(low-poly) 고유 객체를 위한 지오메트리 병합과 하이 폴리(high-poly) 반복 객체를 위한 인스턴싱의 장점을 결합한다 [2]. 이를 통해 메모리 소비와 드로우 콜([[Draw Call|Draw Call]]) 횟수 간의 최적의 균형을 달성하면서 개별 객체의 빠른 검색 및 조작 기능을 제공하는 것을 목표로 한다 [1, 3].
|
||||
## 매 한 줄
|
||||
> **"매 IFC BIM model 의 web-native streaming 형식"**. 매 2021 IFC.js (Antonio Gonzalez Viegas) → 매 2024 ThatOpen Components 로 rebrand 된 toolchain. 매 Fragment format 매 IFC 의 매 GPU-friendly binary representation — 매 1GB IFC 가 매 50MB Fragment 로 압축, 매 browser 의 매 instant load.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **개발 목적 및 배경:**
|
||||
건물 모델과 같이 수천 개에서 수백만 개의 객체로 구성된 거대한 씬(scene)을 렌더링할 때, 기존의 모든 객체를 `[[BufferGeometry|BufferGeometry]]`로 병합하는 방식은 램(RAM) 메모리를 지나치게 많이 소비하는 한계가 있었고, `[[InstancedMesh|InstancedMesh]]`를 사용하는 방식은 재질(Material) 수만큼 드로우 콜이 늘어나는 단점이 있었다 [4, 5]. Fragment는 이러한 문제를 해결하여 메모리와 FPS 측면 모두에서 효율성을 달성하고, 개별 객체를 빠르게 검색하고 하이라이트할 수 있도록 설계되었다 [1, 6].
|
||||
## 매 핵심
|
||||
|
||||
* **하이브리드 아키텍처:**
|
||||
Fragment는 다음과 같이 객체의 특성에 따라 두 가지 최적화 방식을 혼합하여 사용한다.
|
||||
* **병합 (Merging):** 벽이나 바닥처럼 고유하면서 폴리곤 수가 적은(low-poly) 객체들은 하나 또는 여러 개의 `BufferGeometry`로 병합하여 드로우 콜을 최소화한다 [2, 7].
|
||||
* **인스턴싱 ([[Instancing|Instancing]]):** 문, 가구, 창문과 같이 동일한 형태가 반복되면서 폴리곤 수가 많은(high-poly) 객체들은 각각 `InstancedMesh`로 구성하여 메모리 소비를 대폭 줄인다 [2, 7].
|
||||
### 매 IFC 의 limitation
|
||||
- 매 STEP-based ASCII format — 매 100MB+ project 매 routine.
|
||||
- 매 spatial hierarchy + property + geometry 매 모두 nested — 매 partial load 의 X.
|
||||
- 매 Three.js 의 직접 render 의 X — 매 tessellation needed.
|
||||
|
||||
* **구조적 특징 및 저장 방식:**
|
||||
공통된 Fragment 인터페이스를 통해 1,000개의 동일한 의자가 하나의 인스턴스화된 Fragment가 될 수도 있고, 프로젝트의 모든 벽면이 병합된 단일 Fragment가 될 수도 있다 [6, 7]. 영속성(persistence) 수준에서는 각 Fragment당 하나의 GLB 파일을 저장하는 방식을 고려하여 설계되었다 [7]. 모든 Fragment가 비슷한 수의 정점(vertices)과 드로우 콜을 가지도록 하여 시스템 부하의 균형을 맞춘다 [3].
|
||||
### 매 Fragment 의 solution
|
||||
- 매 web-ifc (WASM) 가 매 IFC parse + tessellate.
|
||||
- 매 결과를 매 Fragment binary (FlatBuffers-based) 로 serialize.
|
||||
- 매 InstancedMesh 단위 grouping → 매 draw call 격감.
|
||||
- 매 property data 매 별도 SQLite-WASM file → 매 lazy query.
|
||||
|
||||
* **성능 및 결과:**
|
||||
초기 프로토타입 구현 결과, 1,000개의 의자와 4개의 벽으로 구성된 씬을 단 3번의 드로우 콜(선택용 드로우 콜 제외)과 10MB 미만의 메모리만으로 렌더링하는 데 성공했다 [6]. 또한 100MB 이상의 대형 IFC 모델을 모바일 기기에서도 Autodesk Forge에 필적하는 속도로 빠르게 로드하는 훌륭한 성능을 보여주었다 [8].
|
||||
### 매 응용
|
||||
1. 건축 설계 review web tool.
|
||||
2. Construction 현장 mobile BIM viewer.
|
||||
3. Facility management dashboard.
|
||||
4. Clash detection web service.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
## 💻 패턴
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[BufferGeometry|BufferGeometry]], InstancedMesh, [[Draw Call|Draw Call]]
|
||||
- **Projects/Contexts:** IFC.js, Three.js
|
||||
- **Contradictions/Notes:** 소스에 따르면, Fragment와 같은 자체적인 최적화 시스템 구축 외에도 대규모 환경 최적화를 위해 다중 그리기(Multidrawing), LOD(Level of Detail), 오클루전 컬링(Occlusion Culling) 등의 추가적인 방법론도 함께 검토되었다 [2].
|
||||
### 1. ThatOpen Components 초기화 (2026)
|
||||
```ts
|
||||
import * as OBC from "@thatopen/components";
|
||||
import * as OBCF from "@thatopen/components-front";
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
const components = new OBC.Components();
|
||||
const worlds = components.get(OBC.Worlds);
|
||||
const world = worlds.create<
|
||||
OBC.SimpleScene, OBC.SimpleCamera, OBCF.PostproductionRenderer
|
||||
>();
|
||||
|
||||
---
|
||||
world.scene = new OBC.SimpleScene(components);
|
||||
world.renderer = new OBCF.PostproductionRenderer(components, container);
|
||||
world.camera = new OBC.SimpleCamera(components);
|
||||
components.init();
|
||||
```
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 2. IFC → Fragment 변환
|
||||
```ts
|
||||
const ifcLoader = components.get(OBC.IfcLoader);
|
||||
await ifcLoader.setup();
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
const file = await fetch("model.ifc");
|
||||
const buffer = new Uint8Array(await file.arrayBuffer());
|
||||
const model = await ifcLoader.load(buffer);
|
||||
world.scene.three.add(model);
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 3. 미리 만든 Fragment load (instant)
|
||||
```ts
|
||||
const fragments = components.get(OBC.FragmentsManager);
|
||||
const data = await fetch("model.frag").then(r => r.arrayBuffer());
|
||||
const group = fragments.load(new Uint8Array(data));
|
||||
world.scene.three.add(group);
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### 4. Property query (lazy)
|
||||
```ts
|
||||
const indexer = components.get(OBC.IfcRelationsIndexer);
|
||||
await indexer.process(model);
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
// Get all walls
|
||||
const walls = await indexer.getEntitiesByType(model, "IFCWALL");
|
||||
for (const expressID of walls) {
|
||||
const props = await model.getProperties(expressID);
|
||||
console.log(props.Name.value);
|
||||
}
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### 5. Highlight on click
|
||||
```ts
|
||||
const highlighter = components.get(OBCF.Highlighter);
|
||||
highlighter.setup({ world });
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
highlighter.events.select.onHighlight.add((selection) => {
|
||||
console.log("Selected fragments:", selection);
|
||||
});
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### 6. Section plane (clipper)
|
||||
```ts
|
||||
const clipper = components.get(OBC.Clipper);
|
||||
clipper.enabled = true;
|
||||
container.addEventListener("dblclick", () => clipper.create(world));
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### 7. Streaming (large model)
|
||||
```ts
|
||||
const streamer = components.get(OBCF.IfcStreamer);
|
||||
streamer.url = "https://cdn.example.com/fragments/";
|
||||
streamer.world = world;
|
||||
|
||||
await streamer.load(
|
||||
await fetch("model-streamed.json").then(r => r.json()),
|
||||
true // coordinate to origin
|
||||
);
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Small model (< 50MB IFC) | 직접 IfcLoader.load() |
|
||||
| Medium (50-500MB) | 사전 변환된 .frag file |
|
||||
| Large (500MB+) | IfcStreamer (tile-based LOD) |
|
||||
| Property-heavy query | IfcRelationsIndexer + cached |
|
||||
| Mobile viewer | Fragment + simplified geometry |
|
||||
|
||||
**기본값**: ThatOpen Components 2026 + Fragment 사전 변환 + property cache.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[BIM (Building Information Modeling)]] · [[IFC (Industry Foundation Classes)]]
|
||||
- 변형: [[Speckle]] · [[xeokit]] · [[Forge Viewer]]
|
||||
- 응용: [[Web BIM Viewer]] · [[Clash Detection]] · [[Facility Management]]
|
||||
- Adjacent: [[Three.js]] · [[WASM]] · [[FlatBuffers]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 web-based BIM viewer 매 build. 매 IFC model 매 browser 의 instant load 가 필요. 매 open-source 매 prefer (Forge 의 X).
|
||||
**언제 X**: 매 desktop-only workflow (Revit/Navisworks 매 충분). 매 < 10MB model (overkill). 매 photorealistic render (use Unreal/Unity).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **IFC 매 매번 parse**: 매 100MB IFC 매 user 마다 30초 wait. 매 backend 사전 변환 필수.
|
||||
- **Property 매 eager load**: 매 모든 property 매 memory load → OOM. 매 lazy + query-on-demand.
|
||||
- **InstancedMesh 무시**: 매 IFC 의 매 1000+ identical column 매 매 separate Mesh → 매 draw call 폭발.
|
||||
- **GlobalId 의 X**: 매 Fragment internal ID 매 IFC GlobalId 와 매 different — 매 cross-system mapping 매 GlobalId 사용.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (ThatOpen/engine_components GitHub 2026-05, web-ifc 0.0.66+).
|
||||
- 신뢰도 A (rapidly-evolving project — 매 minor API drift 가능).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — ThatOpen Components 2026 API + Fragment streaming |
|
||||
|
||||
Reference in New Issue
Block a user