# HmEG → WebGPU 포팅 가능성 분석

> 작성일: 2026-04-10  
> 배경: HmEG(Helix Toolkit 변형, SharpDX, Compute Shader 집약) 엔진을 웹 브라우저에 이식하는 방안 검토

---

## 1. WPF 3D 엔진을 웹에 탑재하는 방법

WPF는 Windows 전용 스택(Win32 HWND, DirectX COM, WPF 렌더링 루프)이므로 브라우저에 직접 탑재는 불가능하다.

### 현실적 대안

| 방법 | 난이도 | 설명 |
|------|--------|------|
| WebAssembly 포팅 | 매우 높음 | 렌더링 코어를 C++/Rust로 재작성 → WASM + WebGL/WebGPU 컴파일 |
| 서버 스트리밍 | 중간 | 서버에서 앱 실행 → WebRTC/H.264로 스트리밍 → 브라우저는 뷰어만 |
| 씬 데이터 REST API | 낮음 | 엔진 상태를 HTTP로 노출 → three.js/Babylon.js로 독립 렌더링 |
| Blazor Hybrid | 중간 | WPF + WebView2 조합 (역방향, 앱 안에 웹 UI) |

---

## 2. WebGPU 선택 시 가능한 것들

### WebGL2 대비 WebGPU의 핵심 추가 기능

| 기능 | WebGL2 | WebGPU |
|------|--------|--------|
| Compute Shader | ❌ | ✅ `@compute` |
| Indirect Draw | ❌ | ✅ `drawIndirect` |
| Storage Buffer (SSBO) | 제한적 | ✅ 완전 지원 |
| Multi-draw Indirect | ❌ | ✅ (extension) |
| Timestamp Query | ❌ | ✅ |
| Wave Intrinsics | ❌ | ⚠️ `subgroups` extension, 불안정 |

### 브라우저 지원 현황 (2026-04 기준)

| 브라우저 | 지원 |
|---------|------|
| Chrome 113+ | ✅ 기본 활성화 |
| Edge 113+ | ✅ 기본 활성화 |
| Firefox | ⚠️ Nightly 실험적 |
| Safari | ⚠️ 기술 프리뷰 |

엔터프라이즈 내부 도구라면 Chrome/Edge 고정으로 충분히 현실적이다.

---

## 3. HmEG 스택 분석 (SharpDX + Helix Toolkit 변형)

```
HmEG
├── C# 코드 (비즈니스 로직, 씬 그래프)
├── SharpDX (DirectX 11 C# 바인딩)
├── Helix Toolkit 변형 (WPF 렌더링 루프)
└── HLSL Compute Shaders (병렬 연산 핵심)
```

**핵심 문제**: SharpDX는 DirectX 11 COM API의 thin wrapper — WASM에서 DirectX COM을 호출할 방법이 없다.

### C# → WASM 경로 (Blazor WebAssembly)

| 컴포넌트 | Blazor WASM 이식성 |
|---------|------------------|
| 비즈니스 로직 C# | ✅ 거의 그대로 |
| SharpDX 렌더링 | ❌ DirectX COM 불가 |
| WPF UI 계층 | ❌ 완전 교체 필요 |
| HLSL Compute Shader | ⚠️ WGSL 재작성 필요 |

---

## 4. HLSL → WGSL 셰이더 변환

### 변환 파이프라인

```
HLSL → DXC --spirv → SPIR-V → naga/Tint → WGSL
```

- **naga** (Rust, wgpu 프로젝트) — 가장 성숙한 변환 도구
- **Tint** (Google) — WGSL 레퍼런스 컴파일러

### Compute Shader 1:1 대응 예시

```hlsl
// HLSL (SharpDX)
[numthreads(64, 1, 1)]
void CSMain(uint3 id : SV_DispatchThreadID,
            uint  gi : SV_GroupIndex)
{
    groupshared float4 cache[64];
    cache[gi] = inputBuffer[id.x];
    GroupMemoryBarrierWithGroupSync();
    outputBuffer[id.x] = cache[gi] * 2.0;
}
```

```wgsl
// WGSL (WebGPU)
var<workgroup> cache: array<vec4f, 64>;

@compute @workgroup_size(64, 1, 1)
fn cs_main(@builtin(global_invocation_id) id: vec3u,
           @builtin(local_invocation_index) gi: u32) {
    cache[gi] = input[id.x];
    workgroupBarrier();
    output[id.x] = cache[gi] * 2.0;
}
```

구조는 1:1 대응된다. 알고리즘 재설계가 아니라 문법 변환이다.

### 주요 변환 난관

- `SV_Position` vs `gl_Position` — 좌표계 Y축 반전 필요
- `cbuffer` → `uniform block` 구조 재정렬
- `groupshared`, `numthreads` Compute 확장 — WGSL에서 직접 지원
- 행렬 규약 차이 (row-major vs column-major) — 암묵적 가정 수동 확인 필요

---

## 5. AI를 통한 코드 포팅 가능성

### 컴포넌트별 AI 포팅률

| 컴포넌트 | AI 포팅률 | 이유 |
|---------|----------|------|
| HLSL Compute → WGSL | **90%+** | 1:1 구조 매핑, 패턴 명확 |
| HLSL Vertex/Pixel → WGSL | **95%+** | 가장 단순한 변환 |
| SharpDX API → WebGPU (TS/Rust) | **85%** | API 문서 명확, 대응표 존재 |
| 씬 그래프 / 지오메트리 C# → TS/Rust | **75%** | 로직 자체는 언어 무관 |
| 렌더링 루프 / 파이프라인 재구성 | **60%** | 아키텍처 판단 필요 |
| 최적화 로직 (배치, 컬링 등) | **50%** | 알고리즘은 번역, GPU 특성 차이 보정은 수동 |

> **주의**: 최적화 로직 50%는 "절반만 작동한다"는 뜻이 아니다.  
> 알고리즘 코드는 AI가 번역하고, GPU 튜닝 파라미터(워크그룹 크기 등)를 WebGPU 환경에서 재측정하는 작업이 수동이다.  
> 최적화 알고리즘 자체는 100% 이식된다.

### 실제 포팅 흐름

```
1단계 — AI 일괄 변환 (자동화 가능)
  ├── 전체 .hlsl 파일 → WGSL 변환 (AI)
  ├── SharpDX 초기화 코드 → WebGPU 초기화 (AI)
  └── C# 수학/지오메트리 유틸 → wgpu-matrix (AI)

2단계 — AI 지원 + 인간 검토
  ├── 렌더링 파이프라인 재구성 (AI 초안 → 인간 검토)
  ├── 좌표계/행렬 규약 맞춤 (AI 탐지 → 인간 확인)
  └── 바인딩 그룹 레이아웃 설계 (AI 제안 → 인간 결정)

3단계 — 인간 주도
  ├── GPU 프로파일링 및 최적화 튜닝
  └── 엣지 케이스 버그 수정
```

### 전체 공수 추정 (50,000줄 규모 가정)

| 작업 | 비율 |
|------|------|
| AI 자동 변환 가능 | ~60-70% |
| AI 초안 + 인간 검토 | ~20% |
| 인간이 처음부터 재작성 | ~10-20% |

---

## 6. 나나이트 유사 기능 WebGPU 구현 가능성

### 나나이트 핵심 기능별 WebGPU 가능 여부

| 나나이트 기능 | WebGPU | 비고 |
|-------------|--------|------|
| 클러스터 기반 BVH | ✅ | Storage Buffer로 구현 |
| GPU-side LOD 선택 | ✅ | Compute Shader로 완전 구현 |
| Indirect Draw | ✅ | `drawIndirect` 지원 |
| 소프트웨어 래스터라이저 | ⚠️ | Storage Texture 쓰기로 구현 가능, 성능 제한 |
| **Mesh Shader** | ❌ | WebGPU 미지원 (2026 현재) |
| Wave Intrinsics | ⚠️ | `subgroups` extension, 불안정 |
| Visibility Buffer | ✅ | 완전 구현 가능 |

**Mesh Shader 없이**: Compute + Indirect Draw 조합으로 알고리즘 동일, GPU 효율 15~30% 낮음.

**BIM 모델러 용도**: 수백만 폴리곤 건축 모델 실시간 가시화 수준은 WebGPU + 나나이트 유사 구현으로 충분히 가능.

---

## 7. DirectX 12 기능 → WebGPU 전체 대응표

### 렌더링 파이프라인

| DX12 기능 | WebGPU | 상태 |
|-----------|--------|------|
| Command List / Queue | `GPUCommandEncoder` | ✅ |
| Render Pass | `beginRenderPass` | ✅ |
| Descriptor Heap | Bind Group Layout | ✅ |
| Root Signature | Pipeline Layout | ✅ |
| PSO | `createRenderPipeline` | ✅ |
| Multi-queue (Graphics/Compute/Copy) | 단일 queue | ⚠️ |
| Swap Chain 직접 제어 | 브라우저 관리 | ❌ |

### 셰이더 / 연산

| DX12 기능 | WebGPU | 상태 |
|-----------|--------|------|
| Compute Shader | `@compute` | ✅ |
| Mesh Shader | — | ❌ |
| Amplification Shader | — | ❌ |
| Ray Tracing (DXR) | — | ❌ |
| Wave Intrinsics | `subgroups` extension | ⚠️ |

### 메모리 / 리소스

| DX12 기능 | WebGPU | 상태 |
|-----------|--------|------|
| Explicit Memory Management | — | ❌ 브라우저 관리 |
| Placed Resources | — | ❌ |
| Resource Aliasing | — | ❌ |
| Tiled/Sparse Resources | — | ❌ |
| Resource Barriers | 암묵적 자동 처리 | ⚠️ |

### 고급 렌더링

| DX12 기능 | WebGPU | 상태 |
|-----------|--------|------|
| Variable Rate Shading | — | ❌ |
| Conservative Rasterization | — | ❌ |
| DirectML | WebNN (별도 표준) | ⚠️ |
| FSR (upscaling) | Compute로 구현 가능 | ⚠️ |
| Indirect Draw/Dispatch | `drawIndirect` | ✅ |
| Timestamp Query | ✅ (약간 흐릿) | ✅ |

### 커버리지 요약

```
DX12 기능 집합
┌─────────────────────────────────────────┐
│  WebGPU 커버 (~60-65%)  │  DX12 전용    │
│  ─────────────────       │  ─────────    │
│  Compute ✅              │  Ray Tracing  │
│  Indirect Draw ✅        │  Mesh Shader  │
│  Visibility Buffer ✅    │  VRS          │
│  Instancing ✅           │  Sparse Res   │
│  MRT ✅                  │  Explicit Mem │
│  (≈ DX11.1 ~ DX12 하위) │               │
└─────────────────────────────────────────┘
```

**WebGPU ≈ DirectX 11.1 ~ 12 하위집합**

### BIM 모델러 관점 실질 영향

| 기능 | BIM 필요도 | WebGPU 대안 |
|------|-----------|------------|
| Ray Tracing | 선택적 | Screen Space 기법 |
| Mesh Shader | 나나이트 성능 | Compute + Indirect 80% |
| Sparse Resources | 초대형 텍스처 스트리밍 | 수동 Texture Atlas |
| Multi-queue | 백그라운드 로딩 | Web Worker + Staging Buffer |

---

## 8. 권장 포팅 아키텍처

```
┌─────────────────────────────────────────────┐
│  Blazor WebAssembly                          │
│  ┌─────────────────┐  ┌───────────────────┐  │
│  │  HmEG C# Core   │  │  새 렌더링 백엔드  │  │
│  │  (씬그래프,      │◄─┤  Silk.NET.WebGPU  │  │
│  │   지오메트리,    │  │  또는             │  │
│  │   물리 등)       │  │  JS Interop +     │  │
│  └─────────────────┘  │  WebGPU API       │  │
│                        └───────────────────┘  │
│  HLSL Compute → WGSL (naga 자동 변환)         │
└─────────────────────────────────────────────┘
```

또는 C++ 기반으로 재타깃:

```
HmEG C++ Core
    ↓
Dawn (C++ WebGPU 구현) 백엔드 추가
    ↓
Emscripten 컴파일 → WASM
    ↓
브라우저 (Chrome/Edge)
```

---

## 결론

- **단순 이식 불가**: WPF/SharpDX는 Windows 네이티브 스택, 브라우저 직접 탑재 불가
- **WebGPU는 현실적 선택**: Compute Shader 집약적인 HmEG와 잘 맞음, DX11.1 수준 기능 커버
- **AI 포팅 효과**: 셰이더·API 변환 60~70% 자동화 가능, 성능 튜닝은 수동
- **나나이트 유사**: 알고리즘 80% 구현 가능, Mesh Shader 부재로 완전 동일 성능은 어려움
- **BIM 용도**: 충분히 현실적, 건축 모델 수백만 폴리곤 실시간 가시화 가능