반응형

 

 

 

 

 

1. 필레이트(Fillrate)

- 그래픽 카드가 초당 화면에 렌더링할 수 있는 픽셀의 수를 의미한다. (픽셀 처리에 대한 부담)

- 렌더링 해야하는 픽셀의 수가 많거나, 프래그먼트 쉐이더가 무거우면 래스터라이저 스테이지에서 병목이 발생하는데 이것을 필레이트 병목이라고 한다.

- 필레이트 = 픽셀 수 X 프래그먼트 쉐이더 복잡도 X 오버드로우

 

 

 

2. 확인 방법

- 해상도를 변경해서 프레임을 확인해보면 된다. (해상도를 줄이면 렌더링 해야할 픽셀 수가 줄어들기 때문)

 

 

 

3. 해상도를 줄이는 방법

3-1) 코드로 변경하기

- Screen.SetResolution() 메서드를 사용하여 해상도를 변경할 수 있다.

 

3-2) Project setting에서 변경하기(Android, iOS 한정)

- EditProject SettingsPlayer에서 Resolution and PresentationResolution Scaling에서 설정이 가능하다.

- Resolution Scaling Mode가 기본값(Disabled)으로 되어있는데 Fixed DPI로 변경하고 Target DPI 값을 설정해주면 된다.

- Target DPI : 1인치에 몇개의 화소가 들어가는가(수치가 낮을수록 해상도가 낮아짐)

 

 

 

 

※ 하지만 해상도를 줄이면 유저가 알아차리기 쉽기 때문에 업스케일 샘플링을 사용하는데 이 부분은 추후에 작성 예정.

 

 

 

 

 

반응형
반응형

 

 

 

 

유니티에서는 색공간 옵션에 Gamma와 Linear가 존재한다.

Linear의 경우 사실적인 색이 표현되고, Gamma의 경우 사람의 눈에 자연스럽게 느껴지는 색으로 표현이된다.

 

위 그라데이션 이미지는 사람이 보기에 Gamma가 더 자연스러워 보이지만 Linear에서 표현된 색이 진짜 그라데이션 색상이다. 하지만 사람이 볼때 Linear 그라데이션이 어색해보이는데 해당 현상은 베버의 법칙으로 설명할 수 있다.

 

베버의 법칙은 간단하게 설명하면, 자극이 없던곳에 추가된 자극은 민감하게 느끼고(Linear의 검은부분에서 흰색으로 넘어가는 부분) 이미 자극을 받은 상태에서는 자극이 추가(Linear의 회색에서 흰색으로 넘어가는부분)되도 민감하게 느껴지지 않는다는 말이다.

그렇기 때문에 Linear그라데이션에서는 진짜 색인데도 불구하고 사람이 볼때에는 어색해보인다.

 

그렇기 때문에 기존 Linear 색에서 출력을 더 떨어뜨려서 사람이 인지할때 자연스럽게 보이게하는게 Gamma 보정이다.

이렇게 모니터에 출력될 때 Gamma 보정이 들어가기 때문에 기존의 Linear 이미지를 저장할 때 기존 이미지의 색상보다 더 밝게하여 저장한다.(sRGB라 한다.)

 

이걸로 Linear와 Gamma의 차이를 알아보았고, 파이프라인에서의 차이점을 알아보자.

만약 Add 이펙트를 사용한다고 가정했을때 각 파이프라인에서의 처리는 다음과 같다.

 

 

 

Gamma 파이프라인

  • Gamma 파이프라인에서는 sRGB상태에서 Add를 하게된다. 그렇게되면  겹치는 부분에서 너무 밝아져서 해당 부분의 색상 데이터가 날아가버리게된다.
  • 이런 상태에서 Gamma 보정이 들어가면 결과적으로 하얗게 뜨게되어 어색하게보인다.

※ 위 그림에서 Linear는 파이프라인을 뜻하는게 아니라, 원본 이미지라고 생각하면 된다.

 

 

 

Linear 파이프라인

  • Gamma 파이프라인과 다르게 sRBG 영역에서 더하지 않고 Add 연산을 하기전에 엔진에서 어둡게 샘플링을 한다음 Add처리를 한다. (Linear를 지원하는 하드웨어에서는 샘플링시에 코스트가 들어가지 않는다.)
  • 해당 결과를 sRBG로 밝게해서 저장한 뒤 디스플레이로 출력하게되기 때문에 Gamma 파이프라인과 다르게 자연스럽게 출력되는 것을 확인할 수 있다.

 

 

결과적으로 Add 연산을 밝게한 상태에서 연산을 하느냐 어둡게한 상태에서 연산을하느냐의 차이가 Gamma와 Linear의 차이점이다.

그래서 URP나 HDRP의 경우 컬러 스페이스의 기본설정이 Linear로 되어있고 레거시의 경우 Gamma로 되어있다.

 

왜 레거시 파이프라인에서 Gamma가 기본설정이냐면, 구형 하드웨어에서는 Linear를 지원하지 않기때문인데 Linear를 지원하는 디바이스 조건은 다음과 같다.

 

 

 

Android

  • Graphics API : OpenGL 3.0 이상
  • Minimum API Level  : 4.3(API Level 18) 이상

 

 

iOS

  • Graphics API : Metal
  • iOS Version : 8 이상

 

 

외국의 경우 구형 디바이스를 사용하는 곳도 있기 때문에, 구형 디바이스도 서비스 대상에 포함되어있으면 어쩔 수 없이 Gamma 파이프라인밖에 선택지가 없지만 그렇지 않으면 Linear 파이프라인으로 사용하는것이 좋다.

※ Gamma로 작업하다가 Linear로 바꾸는것이 아닌 프로젝트 초반부터 Linear로 시작해야 번거로움을 덜수있다.

 

 

 

※ 이해가 가지 않으면 다음 영상 참고

 

 

 

 

 

 

 

반응형
반응형

 

 

 

 

배칭(Batching)

- 드로우콜을 줄이는 작업 (1개의 드로우콜이 1개의 배치가 되는데, 여러개의 배치를 하나로 묶어서 하나의 배치로 만드는 것을 배칭이라고 한다.)

 

 

 

스태틱 배칭(Static Batching)

- 정적(움직이지 않는) 오브젝트를 위한 배칭 기법.

- 주로 배경 오브젝트들에 사용되며 게임 오브젝트의 인스펙터 창에서 StaticBatching Static플래그를 활성화 시켜준다.

- 해당 플래그를 활성화하면 해당 게임 오브젝트는 이동, 회전, 스케일 조절이 되지 않는다.

- 스태틱 배칭은 다이나믹 배칭보다 효율적이다. (매 프레임마다 버텍스 연산을 수행하지 않기 때문이다.)

- 메시의 폴리곤 수 제한에 영향을 받지 않고 동일한 머티리얼을 사용하는 메시를 그릴 시, 드로우콜을 줄일 수 있다.

- 스태틱 배칭은 오브젝트들을 합쳐서 내부적으로 하나의 메시로 만들어주기 때문에 1개의 메시만 사용하더라도 해당 메시로 여러개의 오브젝트를 만들면 오브젝트들을 합친만큼의 추가 메모리가 필요하게된다.

- 이렇게 만들어진 메시를 GPU가 그대로 화면에 그리기 때문에 오브젝트마다 드로우콜을 거치지 않고 한번의 드로우콜로 처리되는 것이다.

- 스태틱 배칭 오브젝트들은 처음부터 씬에 존재해야한다.

- 런타임에 추가하게되면 StaticBatchingUtility.Combine() 메서드를 사용해야 배칭처리를 해준다.

 

 

 

다이나믹 배칭(Dynamic Batching)

- 동적으로 움직이는 오브젝트들끼리 배칭하는 기능

- 스태틱 배칭과 다르게 런타임상에서 배칭처리가 이루어진다.

- 다이나믹 배칭은 Batching Static 플래그가 활성화 되어있지 않은 오브젝트들이 대상이다.

- 동일한 머티리얼을 사용하고 특정 조건들을 만족하는 다이나믹 오브젝트들은 자동으로 배칭이 이루어진다.

- 배칭 처리는 엔진이 알아서 처리해주며, 별도의 추가 작업은 필요없다.

- Player settings에서 Dynamic batching플래그만 활성화시켜주면 된다.

- 다이나믹 오브젝트는 매 프레임 씬에서 Vertex들을 모아서 합쳐주는 과정을 거치고 다이나믹 배칭에 쓰이는 Vertex buffer와 Index buffer에 담으면 GPU는 이를 가져가서 렌더링한다.

- 이러한 과정을 거치기 때문에 다이나믹 배칭은 매 프레임마다 오버헤드가 발생한다.

 

 

 

다이나믹 배칭의 제약

  • Skinned Mesh에는 적용 불가

- 캐릭터의 경우 Skinned Mesh를 사용하는데 이러한 스키닝은 GPU나 SIMD(Single Instruction Multiple Data)에서 고속 연산을 수행한다.

- 이를 다이나믹 배칭으로 묶으면 CPU 연산효율이 떨어지기 때문에 다이나믹 배칭의 영향을 받지 않는다.

※※ 일반적으로 메시가 렌더링 될때에는 Vertex 쉐이더(GPU)에서 월드 스페이스로의 변환이 이루어지는데, 다이나믹 배칭은 이러한 연산이 CPU에서 이루어진다. 따라서, 이러한 연산이 드로우콜보다 더 많은 시간을 잡아먹게 되면 오히려 효율이 떨어지게 된다.

  • Vertex가 많은 메시는 배칭 대상에서 제외됨

- 다이나믹 배칭은 메시의 Vertex를 일일이 수집하여 연산하기 때문에 너무 많은 Vertex를 수집하게 되면, 오히려 오버헤드가 드로우콜의 비용보다 높아질 가능성이 있다.

- Position, Normal, UV를 사용하는 모델이라면 300이하의 Vertex를 가진 모델만 다이나믹 배칭 적용이 가능하다.

 

 

 

추가

- 특정 오브젝트의 배칭 오버헤드가 더 크다고 판단되면 해당 오브젝트가 배칭이 되지 않도록 쉐이더에서 강제설정이 가능하다.

SubShader{
    Tags { "DisableBatching" = "True" }
}

 

 

드로우 콜 배칭 - Unity 매뉴얼

드로우 콜 배칭은 Unity가 더 적은 드로우 콜로 렌더링할 수 있도록 메시를 결합한 드로우 콜 최적화 메서드입니다. Unity는 두 가지 빌트인 드로우 콜 배칭 메서드를 제공합니다.

docs.unity3d.com

 

 

 

 

반응형
반응형

 

 

 

 

동적 오브젝트인 경우 라이트맵을 사용하기 힘들다. (라이트 프로브를 안쓴 경우..)

그렇기 때문에 동적으로 생성하는 오브젝트는 라이트를 이용하는 쉐이더를 사용해야하는데 모바일 단말에서는 드로우콜 부하가 영향을 주므로 쉐이더 사용을 최소한으로 해야한다.

다음은 유니티가 제공하는 모바일용 기본 쉐이더에 대한 설명이다.

※※ 현재 사용하는 것 위주로 작성

 

 

 

Mobile/Particles/Additive

- 보통의 파티클 쉐이더와 다르게 알파 테스트, 컬러마스크, 소프트 파티클 등의 기능을 지운 경량판이다.

- 전체적으로 더해진 상태로 표시된다.

※※ Fog 사용시 수치조절을 잘 하지 않으면 비정상적으로 렌더링된다. (이런 경우 그냥 레거시 쉐이더에 있는 Additive사용함..)

 

 

 

Mobile/Particles/Alpha Blended

- 보통 파티클 쉐이더와 비교해서 알파 테스트, 컬러마스크, 소프트 파티클 등의 기능을 지운 경량판이다.

- 반투명으로 표시되므로 투과 이미지를 설정해야한다.

- Transparent와 비슷하지만, 이것은 양면 폴리곤으로 표시한다.

 

 

 

Mobile/Particles/Multiply

- 보통 파티클 쉐이더와 비교해서 알파 테스트, 컬러마스크, 소프트 파티클 등의 기능을 지운 경량판이다.

- 전체적으로 곱해진 상태로 표시된다.

 

 

 

Mobile/Paricles/VertexLit Blended

- 반투명의 양면 폴리곤으로, 그려지는 것 외에는 전후 관계를 갖지 않으므로 보통 VertexLit과는 역할이 다르다.

- 파티클에 라이트를 적용시키고자 할 때 사용한다.

 

 

 

Mobile/Diffuse

- 다양한 라이트를 지원한다.

- 정점(Vertex) 단위로 음영을 넣으므로 고속으로 동작한다.

- 하나의 라이트만 정확히 그려지고 나머지 라이트는 정밀도를 낮춰서 그린다.

 

 

 

Mobile/Bumped Diffuse

- Point light, Directional light 외에는 지원하지 않는 픽셀 단위로 음영을 넣는다.

- 노멀 맵을 사용할 수 있어서 표현의 폭이 넓다.

- 하나의 라이트만 정확하게 그려지고 나머지 라이트는 정밀도를 낮춰서 그린다.

 

 

 

Mobile/Bumped Specular (1 Directional Light)

- Bumped Diffuse와 차이는 거의 없는데 라이트를 1개만 지원함으로써 경량화한 것이다.

 

 

 

 

반응형
반응형

 

 

 

 

기본 개념은 다음 글에서 참고

 

[유니티] 오클루전 컬링 - 기본 개념

오클루전 컬링 - 오클루전 컬링은 어떤 게임 오브젝트가 다른 게임오브젝트에 의해 카메라 뷰에서 완전히 가려진 게임 오브젝트에 대한 렌더링 계산을 수행하지 못하도록 하는 프로세스이다. -

srdeveloper.tistory.com


 

 

 

다음은 오클루전 컬링 설정을 위한 예시이다.

위 그림에서 Wall 게임 오브젝트는 정적 게임오브젝트, Ball은 동적 게임오브젝트로 오클루전 컬링을 설정해 볼것이다.

 

 

 

카메라 설정

- 카메라 컴포넌트에서 Occlusion Culling 플래그를 활성화 시켜준다.

 

 

 

Wall 게임오브젝트

- 정적 게임오브젝트로 컬링 데이터를 베이크할 것이기 때문에 렌더러에서 Dynamic occlusion 플래그를 활성화시켜줄 필요는 없다.

- 게임 오브젝트의 Static 옵션에서 Occluder StaticOccludee Static 선택해준다.

※※ 일반적으로 정적 오브젝트는 일일이 선택하기보다는 모든 종류의 Static을 선택해주는데 여기서는 그렇게 하지 않았다.

 

 

 

Ball 게임 오브젝트

- 동적 게임오브젝트로 설정해야하므로 렌더러에서 Dynamic occlusion 플래그를 활성화 시켜준다.

 

 

 

 

오클루전 컬링 창

- 상단 메뉴에서 WindowRenderingOcclusion Culling을 눌러 오클루전 컬링 창을 연다.

- Bake 카테고리를 눌러 각 옵션을 설정해주는데 옵션별 기능은 다음과 같다.

 

  • Smallest Occluder

- 다른 게임 오브젝트를 가릴 수 있는 가장 작은 게임 오브젝트의 크기(M단위)이다.

- 일반적으로 가장 작은 파일 크기와 가장 빠른 베이크 시간을 위해 씬에서 최상의 결과를 제공하는 가장 높은 값을 선택해야한다.

  • Smallest Hole

- 카메라가 들여다 볼 수 있는 가장 작은 간격의 직경(M단위)이다.

- Smallest Occluder와 같이 최상의 결과를 제공하는 높은 값을 선택하는 것이 좋다.

  • Backface Threshold

- 베이크 된 크기를 줄여야 하는 경우 유니티는 베이크할 때 씬을 샘플링하고, 표시되는 오클루더 지오메트리가 특정 비율의 후면 이상으로 구성된 씬의 일부를 제외할 수 있다.

- 높은 비율의 후면이 있는 영역은 지오메트리 아래 또는 내부에 있을 가능성이 높으므로, 런타임 시점에 카메라가 있을 가능성이 낮다.

- 기본값 100은 데이터에서 영역을 제거하지 않는다. 값을 낮추면 파일 크기가 작아지지만, 시각적 결함이 발생할 수 있다.

 

 

 

베이크

- 가볍게 사용법을 파악하기 위한 글이니, Smallest Occluder값을 1로 하고 베이크를 한다.

- 베이크를 하게 되면, 프로젝트 창에는 씬의 이름으로 폴더가 생성되고 그 안에 컬링 데이터가 생성되어있는것을 확인할 수 있다.

- 오클루전 컬링이 적용된것을 눈으로 확인하고 싶으면 오클루전 컬링 창에서 Visualization을 선택하면 컬링 화면을 확인할 수 있다.

- 다음 사진과 같이 씬 뷰에서는 컬링된 결과를, Status창에서는 BatchesSaved by batching의 수치가 줄어든 것을 확인할 수 있다.

※※ 만약 Visualization을 눌러도 컬링이 되지 않는다면 카메라가 컬링 범위(노란색 범위)에 있는지 확인해볼 것. 카메라가 범위 밖으로 나가면 컬링 연산을 하지 않는다.

 

 

 

 

동적 오클루전(Dynamic Occlusion)

- 동적 게임오브젝트의 경우 오클루전 컬링을 하려면 Dynamic Occlusion 플래그를 활성화해야 한다고 언급했다.

- 만약 해당 플래그를 비활성화한 뒤, Visualization으로 확인해보면 다음과 같이 컬링이 되지않는것을 확인할 수 있다.

 

 

 

결과

 

 

 

 

추가 주의점

- Smallest Occluder의 값은 작을수록 컬링 정밀도가 올라가지만, 정밀도가 올라갈수록 데이터 크기가 늘어나고 연산 오버헤드가 발생하므로 적절한 수치를 적용하는것이 좋다. (이러한 경험적으로 얻는 수치를 매직 넘버라고 부른다.)

- 야외 씬과 같은 경우 폐쇠되지 않고 오픈되어있는 환경이기 때문에 오클루전 컬링이 그다지 효율적이지 않다.

 

 

 

 

 

반응형

+ Recent posts