이펙트에 입체적으로 라이팅을 적용하는 기술이다.

기존에 이펙트 시스템에서는 라이팅에 자연스럽게 반응하지 않는 미스 매치가 되는 상황이 종종 발생할수 밖에 없었다고 한다.
이번에 6-way lighting을 적용하면 환경에 자연스럽게 반응하는 이펙트를 제작할수 있게 됬다고 한다.

6-way lighting의 구조는 노말맵을 6방향(위, 아래, 앞, 뒤, 좌, 우)으로 2장의 텍스쳐를 사용해서 6면을 커버하는 방식이라고 한다.

텍스쳐 2장을 사용하여 각각의 RGB 채널에서 6방향을 담당하고
한장의 알파채널에서는 투명값 알파값을 담당하고
다른 한장의 텍스쳐에서는 emissive나 기타 여러가지등을 담당하는 구조로 되어있다고 한다.

Ouput Particle 영역을 선택하고 인스펙터 창을 보면 Lighting 영역의 Material Type에 Six Way라는 옵션이 있다.
이 옵션을 선택하게 되면 앞서 말한대로 2장의 텍스쳐를 이용해 6면을 담당하기 때문에 Positive, Negative의 텍스쳐 2장을 세팅할수 있게 된다.

그리고 2개의 텍스쳐중 하나의 텍스쳐 알파채널에서는 emissive와 같은 처리를 담당한다고 했다 옵션을 보면 Emissive Mode를 Single Channel을 통해서 적용할수 있다.

여러 빛에 반응해서 이펙트가 발생하는 만큼 퀄리티는 확실히 더 좋아질수 있지만 그만큼 고려하고 계산해야 되어지는 양이 많아지기 때문에 모든 이펙트를 6-way lighting 방식으로 적용하기에는 성능 이슈가 있을수 있다.

그래서 이 방식을 사용할때는 개발 과정에 있어서 이펙트의 중요도 혹은 환경에 따라 잘 고려해서 사용해야 할 필요성이 있다.

라이팅의 색깔, 카메라가 보고 있는 방향등의 변화에 따라 잘 적용되어 표현해주는걸 볼수 있다.

Adaptive Probe Volumes 이하 줄여서 APV라 하겠다.
유니티에서 제공하는 새로운 Light Probe 시스템이다.

장점으로는
- 멀티플랫폼 지원.
- 사용 방법이 쉽다.

특히 사용방법이 쉬워졌다라는 점은
이전 Light Probe Groups의 경우 이하 LPG는 개별 Probe들을 그림자 영역이라던지, 밝은 영역이라던지 여러 요소를 고려해서 수동으로 잘 배치해줘야 효과를 잘 볼수 있는 많은 작업량과 시간이 필요로 하는 힘든점이 있었다.

하지만 APV에선 볼륨 기반 시스템으로 Probe의 볼륨 영역만 잘 배치해주면 나머지는 유니티가 알아서 맡게끔 배치해주는것이다. 특히 지오메트리 정보를 기반으로 밀도가 필요한부분 덜한부분 이러한 정보를 바탕으로 알아서 Probe를 자동으로 배치해주기 때문에 최적화된 배치를 알아서 해준다는것이다.

그리고 기존 LPG는 연산이 CPU영역에서 이루어진 반면 APV에선 GPU영역에서 이루어지기 때문에 연산도 훨씬 빠르다는 장점이 있다.

그리고 APV에선 Per Pixel Lighting을 지원한다.

기존의 LPG에선 Per Object Lighting으로써 라이팅이 오브젝트에 일괄적으로 균일하게 적용되는 방식이였다.
그래서 균일하게 적용되는 부분이 오히려 위 사진의 왼쪽 트럭처럼 왼쪽 문만 하얗고 본체는 그림자가 져 버리는것처럼 보이는게 어색한 부분이 있다.

하지만 APV에선 픽셀별로 라이팅이 계산되서 위 사진의 오른쪽 트럭처럼 자연스럽게 적용되는 부분이 확연하게 보인다.
물론 픽셀당 연산이 효과는 확실히 좋지만 픽셀마다 계산해야되는 부분이 부담이 될수 있기 때문에. 그보다 좀 더 부담을 줄이고 적용할수 있도록 버텍스 정점을 기준으로 계산될수 있게 Per Vertex 옵션도 있다.

아직까지는 이 APV 기능의 개발과 최적화가 계속 진행중이라는 점에서 현재 개발이 상당히 진행된 프로젝트에는 적용하기 쉽지는 않을거 같고, 신규 개발과 같은곳에서 한번 적용해볼법 한것 같다.

시네머신은 직접 프로그래밍을 하지 않더라도 인스펙터에 있는 속성들을 세팅만 해주면 피사체의 움직임 혹은 사용자의 컨트롤에 따른 카메라 움직임 처리를 쉽게 할수있도록 유니티에서 제공하는 패키지 이다.

현재 최신 정식배포가 된 버전은 시네머신2 인데. 시네머신2에서 아쉬운 부분은 인스펙터의 복잡한 속성들과 모르는 용어들도 많아서 처음 접하여 사용하는 느낌은 난감한 부분이 많다.

이러한 부분들을 좀 더 개선해서 업그레이드 되서 나온것이 시네머신3 이다.

다만 현재 시네머신3는 유니티 2023.2버전부터 사용이 가능하며 프리버전 즉 아직 베타버전 이라 문제점이 있을수도 있다라는 부분을 유의해야 할것 같다.

기본적으로 크게 시네머신의 구성은 시네머신 카메라, 시네머신 컴포넌트, 시네머신 익스텐션 으로 나뉜다.

우리는 메인 카메라가 있고 이 메인카메라를 컨트롤할수 있어야하는데 그 역할이 시네머신 카메라이다.

동시에 이 메인카메라가 피사체를 따라가거나 회전하거나 그러한 역동적인 추가적인 기능을 할수있도록 하는 역할이 시네머신 컴포넌트이다.

시네머신 컴포넌트를 이용해서 우리가 촬영하는 피사체를 다양한 기능을 통해 이쁘게 촬영할수 있지만 이러한 기능을 좀더 효율적이고 확실하게 제어할수 있도록 몇가지 자그만한 확장도구를 추가할수 있는데 이것이 시네머신 익스텐션이다.

컴포넌트는 예를들어 포지션이면 포지션 로테이션이면 로테이션 1대1로만 붙을수 있지만. 익스텐션은 한꺼번에 여러개를 붙일수 있다.

종류는 아래 링크에서 확인해볼수 있다.

https://docs.unity3d.com/Packages/com.unity.cinemachine@3.0/api/Unity.Cinemachine.CinemachineExtension.html

또 시네머신3 에서 달라진점은 기존 시네머신에서는 돌리 트랙을 이용해서 카메라가 이 트랙을 따라 이동하면서 장면을 비춰 주기 위해서 제공되는 기능인데. 하지만 돌리 트랙에는 약간의 제한이 있다.

트랙의 곡률 이라던지 직각적인 움직이라던지 이런것이 안되고 내부적으로 자체 개선을 하여 트랙을 자연스럽게 만들어 주기 때문이다.

시네머신3 에서는 스플라인 패키지를 제공해서 좀 더 자연스럽게 트랙을 세팅할수 있도록 제공한다.

스플라인은 직선과 곡선 데이터를 쉽게 만들수 있도록 제공하는 패키지이다.

확실히 시네머신3까지 와서 2보다 간결해졋고 더 쉽게 사용할수 있는 기능이 많이 제공되는듯 하다.

다만 아직 베타버전이라는 점에 유의해서 사용해야 할것 같다.

무압축 RGBA

압축하지 않은경우 R, G, B, A 채널에 각 8비트를 사용하여 알파가 존재하는 경우 픽셀당 32비트, 알파가 없는 경우 픽셀당 24비트를 사용한다.

2048x2048 RGBA 이미지의 용량 : 2048 * 2048 * 32 = 134.217,728 (약 16MB)
2048x2048 RGB 이미지의 용량 : 2048 * 2048 * 24 = 100,663,296 (약 12MB)

* 유니티는 텍스처를 자체적으로 한번 더 압축하기 때문에 원본 텍스쳐의 용량과 형식에 관계없이 용량이 동일하다. 때문에 PSD나 TGA등을 써도 무방하지만 대부분의 경우 프로젝트 자체의 로컬 용량을 줄이기 위해 보통 PNG를 사용한다. 

밉맵

텍스쳐가 그려질 때 카메라와 거리가 멀 경우 원래 사이즈로 표시하여도 자세히 보이지 않으니 메모리가 낭비될 것이다. 이를 위해 밉맵이라는 최적화 기술이 존재한다.  

- 텍스쳐의 작은 버전을 미리 생성해놓고, 카메라에 표시되는 텍스쳐의 크기가 작을경우 작은 버전의 텍스쳐를 불러와서 대역폭을 절약한다.

- 원본이 2048x2048 이라면, 1024x1024, 512x512, 256x256.... 순으로 절반의 크기를 재귀적으로 생성한다.

- 미리 생성해놓기 때문에 텍스쳐의 용량이 약 33% 증가한다. 

- 유니티에서는 Generate MipMaps 를 체크하면 자동으로 생성되며, default값이 체크이기 때문에, 밉맵이 필요없는 2D 프로젝트에서는 체크해제해야 용량을 절약할 수 있다.

모바일 기기의 텍스쳐 압축 종류

ASTC가 압도적으로 좋은 품질과 적은 용량을 사용하지만 유니티에서 기본설정이 아직도 ETC2 인 이유는 구형 디바이스에서는 ASTC를 사용할 수 없기 때문이다.

ASTC의 지원 기준은 다음과 같다.

글로벌 서비스를 하는 2D 게임이라면 ETC2 유저를 포기할 수 없겠지만, 3D게임의 경우에는 갤럭시 S6 보다도 낮은 기기는 과감하게 버려서 ASTC를 선택하는 경우가 많아지고있다.

구글 공식 개발자 페이지에서 제공하는 안드로이드 OpenGL ES 기기 비율은 아래 주소에서 확인할 수 있다.

http://developer.android.com/about/dashboards/index.html#Platform

2의 승수만 압축하는 ETC, PVRTC

ETC와 PVRTC는 2의 승수(Power of two) 형식만 압축가능하기 때문에, 기본 압축설이 ETC2나 PVRTC라면 POT가 아닌 텍스쳐를 사용할 때 메모리 폭탄을 맞을 수 있다. (ASTC는 2의 승수와 관계없이 압축이 가능하다)

아래의 예시에서

왼쪽은 609x1024로 NPOT 라서, 압축을 하지 못해 무손실 형식으로 2.4 MB가 되었고
오른쪽은 1024x1024로 POT 라서, 왼쪽의 이미지보다 큰데도 압축이 가능해져서 1.0 MB의 용량만을 차지한다. 

* 작은 이미지라면 텍스쳐 아틀라스를 사용하여 강제로 POT이미지에 포함시키면 이를 방지할 수 있다.

가변 블록을 지원하는 ASTC

ASTC는 압축블록의 크기를 자유롭게 조정이 가능하며, 블록크기가 작을수록 품질이 좋아진다.
UI 이미지는 4x4, 3D 오브젝트 텍스쳐 등에는 6x6, 이펙트 등에는 8x8 이상을 사용하면 좀 더 메모리를 절약할 수 있다. 
(기본 값은 6x6)

* ETC2의 기준 용량은 1 MB

예시 사진을 보면 좌측 상단부분의 압축별로 선이 뭉개지는 것을 확인할 수 있다.
특히나 PVRTC는 iOS의 기본 포맷인데도 ETC2에 비해 심하게 뭉개지는 것을 확인할 수 있다.

ASTC 6x6 는 ETC2와 비슷한 품질을 보여주지만 용량은 절반수준을 보여주는것을 알수 있다.

결론은, 안드로이드에서는 3D 게임이거나 팀내에 TA가 있다면 ETC2대신 ASTC를 고려하고,
iOS에서는 PVRTC대신 ASTC를 사용하는 것을 고려해볼만 하다.

출처 :https://mentum.tistory.com/583

모니터의 색상 변환

• 모니터는 디스크에 저장된 이미지를 화면에 출력할 때 Pow(color, 2.2) 연산을 적용해서 더 어둡게 출력한다.

• 이유?
  • 베버의 법칙(Weber’s law)
  • 사람의 시각은 어두운 부분의 밝기 변화를 부드럽지 않고 단절되게 감지한다.
  • 그래서 어두운 부분의 화질이 떨어져 보이는 현상이 발생한다.
  • 따라서 이를 부드럽게 감지하도록 하려면 어두운 부분을 더 풍부하게 표현할 필요가 있다.
  • 따라서 모니터 하드웨어적으로 이런 변환을 해준다.
• Pow(color, 2.2)이면 감마(Gamma)가 2.2라고 한다.

Gamma Correction(감마 보정)이란?

• 이미지를 디스크에 저장할 때 Pow(color, 1/2.2) 연산을 적용해서 더 밝게 저장한다.
• 모니터의 색상 변환에 대응하여, 원본 색상을 화면에 제대로 출력하기 위해 수행한다.
• 1/2.2 = 0.4545....

색 공간(Color Space) 종류

Note

• 색 공간은 어디까지나 상대적인 개념이다.

sRGB

• 원본보다 밝아진 상태의 색 공간
• 감마 보정(Pow(color, 1/2.2))을 통해 밝게 저장된 이미지의 색 공간을 의미한다.

Linear

• 원본 색상을 저장하는 상태의 색 공간

Gamma

• 감마 보정에 의해 어두워진 상태의 색 공간
• 모니터 출력 결과

유니티의 색 공간 파이프라인

설정 방법

• [Edit] - Project Settings - Player - Other Settings - Rendering

Gamma Pipeline

• 다른 짓 안하고 그냥 쉐이더 연산 결과를 바로 모니터로 보낸다.

• 텍스쳐가 sRGB로 밝게 저장된 상태 그대로(원본과 값이 다른 상태에서) 연산을 해버린다.
• 근데 텍스쳐를 사용하지 않는 쉐이더 연산(라이팅 등)에서는 정확한 값(Linear)으로 연산을 수행한다.
• 따라서 텍스쳐는 sRGB, 라이팅 연산 결과는 Linear인 불일치 상태에서 서로가 연산되는 참사가 발생한다.
• 그리고 심지어 Linear에서 이루어진 쉐이더 연산 결과가 그대로 모니터에 출력되므로, 의도보다 더 어두워진다는 것이 치명적이다.

Linear Pipeline

• sRGB로 저장된 텍스쳐를 다시 어둡게(원본으로) 바꾸고, 그 상태에서 정확한 값을 사용해 연산한다.
• 그리고 그 연산 결과를 다시 sRGB로 저장하여, 모니터에서는 다시 어두워져서 원본이 출력되도록 한다.

• sRGB로 저장되었던 텍스쳐, 그리고 순수한 쉐이더 연산 모두 동일한 Linear 공간에서 같이 계산되므로 정확히 계산된다.
• 또한 Linear에서 계산된 결과를 sRGB로 올려서, 결과적으로 모니터에서는 통해 Linear로 내려져서 출력되므로 의도한 색상이 출력된다.

• 결과적으로, Linear Pipeline이 더 정확한 그래픽 결과를 얻을 수 있다.
• 구형 기기(OpenGLES 2.0까지만 지원하는 기기)에서는 사용할 수 없다.

Gamma vs. Linear

• 화면의 모든 색상이 Gamma는 밝고 대비가 높으며, Linear는 비교적 차분하다.
• Gamma는 비교적 화질이 떨어져 보이고, Diffuse 같은 연속된 음영에 대해 특히 뚝뚝 끊기는 느낌을 준다.
• Linear는 더 부드러운 음영을 표현하며, Gamma보다 더 현실에 가까운 그래픽 연산 결과를 보여준다.
• 구형 기기를 지원하지 않아도 된다면 대부분의 경우 그냥 Linear Pipeline을 선택하는 것이 좋다.
• 색 공간 파이프라인을 Linear로 한다고 해서 성능 상 손해보지는 않는다.

유니티 렌더 파이프라인별 기본 색 공간 파이프라인

• Built-in : Gamma Space
  • Linear 파이프라인을 지원하지 못하는 구형 기기들을 모두 호환하기 위해서 기본 색공간이 Gamma로 설정된다.
• SRP(URP, HDRP) : Linear Space

유니티 텍스쳐의 sRGB 토글

• Gamma 파이프라인은 어차피 싹다 그대로 연산하니까 달라지는 것이 없고, Linear 파이프라인일 경우 달라진다.
• 색상 텍스쳐는 sRGB 색공간 텍스쳐로 간주하고, 연산을 위해 Linear로 끌어내려서(^2.2) 연산한다.
• 그런데 정확한 값이 요구되는, 데이터 텍스쳐의 경우(노말 맵, 메탈릭 맵, 플로우 맵, 렌더 텍스쳐 등) 끌어내리면 오히려 부정확해지므로 Linear 그대로 사용해야 한다.
• 따라서 데이터 텍스쳐는 인스펙터 설정에서 sRGB 체크 해제하면 Linear로 간주하고, 정확한 값으로 사용할 수 있다.
• 근데 sRGB는 R, G, B 채널에만 적용된다.
• sRGB에 체크를 해도 A 채널은 언제나 Linear로 인식된다.

결론 : Gamma vs. Linear 파이프라인

• 위와 같은 단순 라이팅 결과만 보자면 Gamma 파이프라인 쪽이 더 부드럽고 예뻐 보일 수 있다.
• 하지만 Gamma 파이프라인은 애초에 치명적인 색공간 불일치 문제가 있다. (색상 텍스쳐는 sRGB, 쉐이더 연산 공간은 Linear)
• 더 정확하고 현실적인 그래픽을 보여주는 것은 Linear 파이프라인이며 어두운 부분에서도 더 높은 화질을 제공한다.

추가 : 쉐이더 그래프 유의사항

URP의 쉐이더 그래프에서 RGB 0.5의 색상 노드 두개를 더해주면 1.0으로 완전한 흰색이 되어야 하지만,

위와 같이 완전한 흰색이 되지 않는다.

색상 노드의 색 자체를 sRGB로 간주하고 ^2.2로 변환된 상태에서 연산한다는 의미이다.

따라서 이런 경우 정확하게 연산하려면

색상마다 Colorspace Conversion으로 ^0.45 연산을 적용해준 뒤 사용해야 한다.

참고 하기 좋은 영상 링크 :