DirectX/[팀플] Death's Door 모작10 Deferred Rendering 1. Forward Rendering 1.1 Forward Rendering이란, - 한 마디로, 기존의 Rendering 방식. 개체 A가 Render Target에 그려지려면 Vertex Shader와 Pixel Shader의 연산이 이뤄지는데, 기존에는 Pixel Shader에서 빛 연산을 진행함. 1.2 Forward Rendering의 문제점 - 개체 X1, X2, ..., Xn이 모두 Pixel Shader에서 빛 연산을 진행함. 어떤 개체는 이미 가려져서 빛 연산을 진행할 필요가 없는데도 개체의 개수만큼 빛 연산을 진행하는 비효율이 발생함. 2. Deferred Rendering 2.1 Deferred Rendering 구조 - Render Target을 여러 개 만듦. Light를 구현하는.. 2022. 12. 19. Post Process Effects 1. 클래스 구조 1.1 현재의 랜더링 구조 - 카메라가 랜더링을 담당함. 카메라에는 메인 카메라와 UI 카메라가 있음. - 각 카메라가 Render Target을 가지고 있음. 즉, 메인 카메라도 본인만의 Render Target을 UI 카메라도 본인만의 Render Target을 가지고 있음. 그래서 마지막에 Back Buffer의 Render Target->Merge(MainCameraRenderTarget) 또 Merge(UICameraRenderTarget)을 실행해서 합치는 것. - GameEngineLevel::Render()에서 카메라에 종속된 랜더러들을 모두 그린뒤, 각 카메라의 Post Process Effects가 적용되게끔 코드가 작성되어 있음. 대략 이런식으로 Post Proces.. 2022. 11. 24. 프로젝트 내의 셰이더 구조 고찰 1. 클라 팀원이 에디터에서 셰이더의 종류를 고르고, 해당 셰이더의 세기, 횟수 등을 조절할 수 있게끔 하고자 함. 근데 문제는 여러가지 셰이더를 동시에 적용 되게끔 하는 것. 1.1 셰이더 조절 관련 랜더러 클래스를 셰이더마다 만들고자 함. 그럼 에디터에서 다양한 랜더러 클래스 관련 코드와의 동기화?가 필요함. 즉, 코드 제너레이터 같은 느낌의 기능이 필요해져서 너무 배꼽이 큰듯하여 포기했음. 1.2 셰이더 조절 관련 랜더러 클래스는 딱 하나만 만듦. 셰이더 파일도 한 개만 작성해서, 거기에 셰이더별 코드를 모아둔다? 너무 길어지고, 가독성이 낮아질듯. 1.3 셰이더 조절 관련 랜더러 클래스도 딱 하나, 셰이더 헤더 파일을 여러 개. 셰이더 조절 관련 랜더러 클래스에서의 멤버 값을 보고 해당 셰이더 함.. 2022. 11. 21. 나름대로 큰? 규모의 소스코드에서의 shared_ptr 고찰 0. 어제자로 프로젝트의 거의 모든 raw pointer가 shared_ptr로 교체되었음. 이는 엔진 팀장님(선생님)이 모두 진행 하심. 1. Actor라는 부모 클래스를 상속 받는 Player 자식 클래스가 있었음. 2. Player 개체는 게임이 진행되는 와중에 단 한명이기에(서버 안 붙힌 게임이라) static 키워드를 통한 싱글톤 패턴으로 구현했음. 3. 강제로 Player 개체를 delete 하면 메모리 릭이 나지 않음. 그리고 엔진 팀장님의 코드에서도 릭이 안남. 근데 차이라면 상속 관계에 차이가 있음. 엔진 팀장님의 Player 클래스는 Player -> EngineObject 컨텐츠 팀원들의 Player 클래스는 Player -> Actor -> EngineObject 4. 다른 클래스를.. 2022. 11. 11. 이전 1 2 3 다음
