위 사진은 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..

결론: Vertex-Bounded인 상황에서 메쉬 셰이더 파이프라인의 하한이 더 높다. 즉 메쉬 셰이더 파이프라인을 사용한 Meshlet 단위 처리 방식의 처리율이 기존 Mesh Instance 단위 그리고 Vertex Shader 기반의 전통적인 파이프라인의 처리율 보다 높다. 또한 Vertex-Bounded가 아닌 상황에서도 Meshlet 단위의 Culling 연산으로 인한 추가 비용을 성능적 이점이 넘어선다.장면 설정동적 점광원 2.7만개구 메쉬 인스턴스 6.4만개 (Transformation 실시간 업데이트)LOD 0 기준 구 메쉬의 유니크한 정점은 6144개, 그리고 유니크한 삼각형 프리미티브는 3072개(LOD 0 기준, 장면 내 정점 수 = 약 3.93억개/삼각형 수 = 약 1.96억개)테스..

모던 그래픽스 API로 넘어오면서 생긴 변화 중 하나는, 더 이상 GPU로의 Command Submission이 즉각적(immediately)으로 이루어 지지 않는다는 점 이다. 물론 D3D11이나 OpenGL에서도 실제로는 즉각적으로 이루어 지진 않고, 드라이버 단에서 명령어들을 모아서 GPU로 넘기긴 했지만, 어쨋거나 어플리케이션의 입장에선 즉각적으로 이루어 지는듯한 환상을 보여주기에 큰 차이는 없다고 생각한다.이 사실을 바탕으로, 대부분의 모던 그래픽스 API의 튜토리얼에선 여러개의 프레임이 동시에 GPU에서 렌더링 되는, 소위 Frames In Flight(Inflight frames)의 개념을 소개한다.문제는 위와 같은 개념이 실제 의도하는 바와는 다르게 이해되었다는 점 이다. 더 정확하게는, ..

현재 엔진에서 구현 중인 렌더러(또는 렌더링 시스템 전반)는 GPU 주도적 설계를 따르고 있다.그렇다 보니 렌더링 가능한 물체에 대한 모든 정보를 GPU에 업로드 해두고, 바뀌는 정보를 감지하여 GPU 메모리에 데이터를 반영 해주도록(Replication) 구현 되어 있다.문제는, 이들을 프로파일링 하였을 때 CPU 타임이 만만치 않았다는 것 이다. 물론 이 사실을 구현 초기에 프로파일링을 통해 인지 할 수 있었고 극도로 병렬화 될 수 있는 구조로 설계 및 서로 연관이 없는 데이터의 경우 서로 동시적(또는 병렬적)으로 처리 될 수 있도록 구현 하였다. 덕분에 CPU 타임은 생각보다 크게 줄일 수 있었다.이중 특히 Transform의 경우 모든 렌더링 가능한 물체가 포함 하고 있는 만큼, 가장 큰 처리 시..

1. Scene Collection에서 Armature의 최상위 이름을 Armature로 설정 할 것2. Export 옵션에서 Geometry->Smoothing = Edge3. Export 옵션에서 Armature->Add Leaf Bones = False

명조(Wuthering Wave)에서 SSR(Screen Space Reflection)을 통해 물 표면 반사를 구현한 예시동굴 내부 환경 인지라 원래라면 하늘이 물의 표면에 반사되서는 안되지만 반사되는 모습을 확인 할 수 있는데. 이는 SSR에서 화면 공간상에서의 렌더 타겟의 유효한 공간 외로 레이 트레이싱이 실패하였을 경우 fallback으로 static environment map을 사용하기 때문이다.