가장 기본적인 API 설계로 'AudioSystem'과 'AudioSourceComponent' 두 가지 요소를 추가하였다. 이 두가지를 만드는데 있어서 고민했던 점이 어떤 시점에 FMOD API를 호출하도록 할 것인가였다.예를 들어, 단순히 Entity-Component 모델의 관점에서 보았을때는 단순히 아래와 같은 형태를 상상 할 수 있다.audioSource->Play();audioSource->Stop();status = audioSource->GetStatus();...하지만 ECS에서의 Component는 로직을 제외한 순수한 데이터만을 저장하는 형태를 띄기 때문에 위와 같이 직접적으로 로직을 포함한 함수를 구현하는 것은 적절지 못하다.현재의 가장 초기 버전의 경우는 ECS의 원칙에 따라 컴포..

기본적으로 현재 엔진에서 핸들 기반 리소스 관리는 '단일 소유권' 만을 인정하고, 소유권을 가진 객체가 철저하게 핸들을 발행하는 주체인 시스템에 핸들을 반환/해제할 책임을 지는 것을 기반으로 하고 있다. 단순하게 말하자면, 이미 해제된 핸들을 통해 실제 리소스의 메모리 공간에 접근할려고 하는 시도는 피할 수 있지만. 기본적으로 해제된 핸들에 대한 실제 메모리 주소를 얻고자 하는 시도 뿐 아니라 해제된 핸들에 대한 중복 반환, 소유권을 가지는 객체의 핸들 미반환(메모리 릭/핸들 릭) 문제는 여전히 남아 있다. 소유권을 가지는 객체의 핸들 미반환의 경우, Debug 빌드에 한해서 핸들을 할당할 때의 callstack을 저장 및 핸들 스토리지가 소멸하는 시점의 런타임 체크 및 어설션에 의해서 반환되지 않은 핸..

프로젝트의 목표(실제로 게임을 만들 수 있는 엔진 개발하기)를 위해서라면, 아래의 순서 대로 집중해서 구현 할 것 같다.오디오 시스템 (1순위)물리 라이브러리의 통합 (1순위)Console Variable 시스템 (2순위)Light 타입의 확장 (Directional/Point/Spot)Cascaded Shadow Map (Directional Light)Disney Principled MaterialAtomospheric Scattering (A Scalable and Production Ready Sky and Atmosphere Rendering Technique; [Hillaire20])Tone Mapping (ACES)카툰 렌더링 ( [INDEX] 카툰 렌더링 참고하기)Skeletal Anima..

아주 유연하진 않아도 최대한 많은 종류의 재질을 지원하고 싶다. (정확히는 여러 종류의 BRDF를 위한 Material 데이터를 통합적으로 관리하고 싶다.)이 상황에서, 가장 쉽게 처리하는 방법은 재질 타입 enum (또는 플래그)를 공통 데이터로 하고, 실제 데이터는 union으로 정의하면 최소한의 데이터 크기로 여러 종류의 데이터 묶음을 통합하여 관리할 수 있다.아쉽게도, HLSL에서는 아직 union을 지원하지는 않는다( Unions | hlsl-specs). 하지만 ByteAddressBuffer를 사용한다면 동일한 처리 방식을 취할 수 있다.여기서 좀 더 유연하게 만들고 싶은 경우, 엔진에 존재하는 모든 재질당 하나의 저장소를 할당하고, Scene Data를 GPU에 동기화 시켜주는 과정에서 실..

기존에 Scene 데이터를 GPU로 replicate 해주는 작업과 렌더링 작업들의 명령어 기록(record)과 제출(submit)은 모두 직렬화되어 실행되고 있었다.  그렇다 보니, Scene 데이터를 복제하는데 들어가는 CPU 작업이 끝나기 전 까지는 Scene 데이터를 직접적으로 사용하지 않는 렌더링 패스라고 하더라도, 아무런 작업을 시작 할 수가 없었다.예를 들어, Hi-Z Occlusion Culling을 위해 이전 프레임 Depth Buffer의 복사, Depth Pyramid(Min/Max Filter 기반 Mipmap chain) 생성과 같은 작업들은 분명히 현재 프레임에서의 Scene Data와는 전혀 관련없이 작업을 수행 할 수 있다. 덕분에 Hi-Z Occlusion Culling을 ..

위 사진은 GPU에 있는 Scene 데이터를 CPU의 데이터와 동기화 시키기 위해, 변경점들을 Upload Heap에 있는 Staging Buffer에 기록 한 다음, Async Copy Queue(엔진에선 Frame Critical Copy Queue; 현재 Copy Queue를 2개를 활용하여 렌더링에 당장 필요한 데이터를 다루기 위한 Copy Queue와 에셋 업로드 또는 스트리밍등 무거운 작업을 담당하는 Copy Queue(Non Frame Critical Copy Queue)를 따로 분리 하였습니다. 이는 ExecuteCommandLists의 특성, 더 나아가서 GPU에서 명령어를 실행하고 Fence(barrier)에 신호를 주는 방식에 기인한 조치 입니다.)를 통해 데이터를 실제 Scene D..