← 전체 프로젝트

엔진 & 도구 / Direct3D 11 · C++

Custom Engine & Editor

렌더러, 공간 질의와 선택 시스템, 에디터 입력 및 게임 실행 흐름을 담당

Notion 원본 보기 ↗
Custom Engine & Editor 프로젝트 화면

JS Engine 에디터 실행 화면 (11주차 Release 빌드)

프로젝트 개요 / Overview

  • 프로젝트 제목 | Custom D3D11 Engine & Editor

  • 프로젝트 분류 | C++ / Direct3D 11 기반 자체 게임 엔진 및 에디터

  • 개발 기간 | 2026.03 ~ 2026.06 (14주)

  • 인력 구성 | 주차별 팀 프로젝트

  • 프로젝트 소개

    빈 main 함수에서 시작해 렌더링, 씬 편집, 입력과 게임 실행 흐름을 구성한 자체 엔진 프로젝트

    • 1·9·14주차 게임잼에서 실제 게임을 제작하며 엔진의 실행 흐름과 사용성을 확인

기술 스택 / Tech Stack

  • Language : C++, HLSL, Lua
  • Graphics : Direct3D 11, Win32 API
  • Tools : Visual Studio, Git, ImGui, RmlUi

기여 / Contribution

렌더러, 공간 질의와 선택 시스템, 에디터 입력 및 게임 실행 흐름을 담당

  • RenderBus → RenderCollector → Renderer 기반 렌더링 명령 수집 및 패스 실행 구조 설계
  • ID Buffer / Ray Picking 기반 선택 시스템과 BVH / Octree 공간 질의 구현
  • 뷰포트, 카메라, Gizmo와 PIE의 입력 처리 및 전환 구조 설계
  • Projection Decal, Shadow Atlas 할당과 디버그 UI 구현
  • 게임잼의 상태 전환, HUD와 카메라·연출 통합

Key Features

  • 렌더링 명령과 패스 실행 분리
    • RenderBus → RenderCollector → Renderer 흐름으로 Scene / Editor 명령 수집과 GPU 실행 책임 분리
    • Material, Texture, Camera 데이터와 HLSL Constant Buffer 연결
    • Grid, Outline, Overlay 등 에디터 피드백을 렌더 패스에 통합
  • Editor Workflow 및 PIE 실행 흐름
    • Outliner 선택, Details 속성 편집, Gizmo와 Local / World Transform을 연결한 씬 편집
    • 다중 뷰포트의 카메라·입력과 UI Capture 경계를 구분
    • Scene 저장·불러오기와 PIE 진입·종료, 플레이어 입력 전환을 연결
    • 팀의 Actor / Component, Asset / Scene 구조 위에서 에디터 실행·입력·선택 경로를 담당
  • BVH 기반 Ray Picking과 ID Buffer Picking
    • World 공간 후보 → Mesh BVH → Triangle Intersection 순서로 질의 범위 축소
    • ID Buffer로 화면에 보이는 객체를 역조회하고 Ray Picking과 함께 선택 시스템 구성
    • Visible Cache와 공간 인덱스를 렌더 명령 제출 및 선택 질의에 활용
  • Projection Decal 및 Shadow Atlas Scheduling
    • Decal Component / SceneProxy / Pass / HLSL을 연결해 표면 피격 표현 구성
    • Shadow Request와 Atlas 할당을 분리하고, 설정과 디버그 화면으로 리소스 사용 상태 확인
  • Runtime 기능과 제작 도구 연동
    • Animation Sequence Viewer의 Timeline / Preview / Bone Weight 표시 구현
    • 팀의 Particle / Cloth / Depth of Field 기능에 UI와 렌더링 경로 연동
    • Symbol Server 도구 구성

문제 해결 사례 / Trouble Shooting

문제

  • 인스턴싱 없이 50,000개 StaticMesh를 다루는 최적화잼에서, 화면 선택과 렌더링 후보 탐색을 전체 객체 순회에 의존하기 어려움

원인 분석

  • 마우스 Ray와 모든 Mesh의 Triangle을 직접 검사하면 객체 수와 모델 복잡도에 따라 질의 비용 증가
  • 렌더링과 선택 시스템이 같은 월드를 각자 탐색하면 공간 질의가 중복됨

해결 방법

  • WorldRenderProxy와 Octree / World BVH로 후보를 먼저 좁히고, StaticMesh BVH에서 Triangle Intersection 수행
  • Ray-AABB 조기 제외와 Near Distance 기반 탐색 순서 적용
  • Frustum Visible Cache와 Ray Picking 후보 캐시를 관리하여 렌더링·선택 경로에 활용
  • ID Buffer Picking과 Ray Picking을 하나의 선택 서비스로 연결

결과

  • 전체 객체·삼각형을 직접 탐색하던 선택 경로를 단계별 공간 질의로 재구성
  • 에디터의 선택 피드백과 렌더 명령 제출을 공통 공간 데이터 위에서 관리

배우고 느낀 점 / Retrospective

엔진을 만들면서 각 기능이 씬 편집과 게임 실행으로 이어져야 실제 제작에 사용할 수 있다는 점을 체감했습니다. UI를 조작하는 동안 카메라나 선택 기능이 함께 반응하지 않도록, 뷰포트와 UI, PIE의 입력 처리 기준을 정리했습니다.

게임잼을 반복하며 에디터에서 만든 데이터가 실제 플레이와 화면으로 이어지는 흐름을 확인했습니다. 이후 기능을 추가할 때도 누가 데이터를 관리하고 어느 시점에 상태가 바뀌는지 먼저 정리하는 습관을 갖게 되었습니다.

관련 자료 / Links

계속 둘러보기The Developer ↗

원본 ↗