티스토리 뷰

728x90

learn.unity.com/course/3d-art-optimization-for-mobile-gaming-5474

 

Arm & Unity Presents: 3D Art Optimization for Mobile Applications - Unity Learn

In this intermediate course, participants will learn how to produce performance-optimized 3D assets and scenes for mobile applications. Topics will cover tips on optimizing Geometry, Textures, Materials, Shaders, and Lighting. This course was created with

learn.unity.com

Shaders and Materials

셰이더는 화면에 개체를 그리는 방법과 개체를 그리기 위해 발생해야하는 모든 계산을 GPU에 알려주는 작은 프로그램입니다.

셰이더는 해당 오브젝트의 모양을 정의하는 머티리얼을 통해 게임 오브젝트에 적용됩니다.

머티리얼은 셰이더에서 사용할 수있는 매개 변수를 설정하는 데 사용됩니다. 예를 들어 머티리얼은 셰이더가 참조하는 색상, 텍스처 및 숫자 값을 지정할 수 있습니다.

Lit vs. Unlit Shaders

unlit 쉐이더는 가장 빠르고 계산 저렴한 쉐이딩 모델입니다. 저가형 장치를 대상으로하는 경우 사용하십시오. 고려해야 할 핵심사항은 다음과 같습니다.

  • 조명은 조명이없는 음영 모델에 영향을주지 않습니다. 이는 반사광 계산과 같은 많은 계산이 필요하지 않음을 의미합니다. 결과는 더 저렴하거나 더 빠른 렌더링입니다.
  • 만화와 유사한 스타일 화 된 아트 디렉션을 사용하면 조명이 없는 음영이 잘 작동합니다.

lit셰이더는 라이팅되지 않은 셰이더보다 더 많은 처리 능력을 사용합니다.

  • 라이트는 라이팅 된 셰이더에 영향을 미치고 표면이 반사성을 갖도록합니다.
  • 이것은 아마도 오늘날 모바일 게임에서 가장 많이 사용되는 음영 모델 일 것입니다.

Transparencies

투명 머티리얼 설정을 사용할 때 성능영향을 고려하는 것이 중요합니다. 특히 모바일 플랫폼에서는 가능할 때마다 불투명 머티리얼을 사용하는 것이 좋습니다.

투명도가있는 개체를 렌더링하면 항상 불투명 개체를 렌더링하는 것보다 더 많은 GPU 리소스를 사용합니다. 많은 투명 개체를 사용하면 모바일 플랫폼의 성능에 영향을 미칩니다. 특히 투명 개체가 서로 위에 여러 번 렌더링 될 때 오버드로 라고하는 프로세스 입니다.

 

셰이더에서 투명도를 구현하는 방법에는 여러 가지가 있습니다. 각각 장단점이 있습니다.

가장 일반적으로 사용되는 투명도구현은 알파테스트와 알파블렌드 입니다.

  • 알파테스트는 머티리얼을 완전히 불투명하거나 완전히 투명하게 만듭니다. 마스크의 컷 아웃 임계 값을 설정할 수 있습니다. Unity에서는이를 Cutout 이라고 합니다. 알파 테스트는 GPU 내의 일부 최적화 기능을 비활성화하므로 필요한 경우가 아니면 피하는 것이 가장 좋습니다.
  • 알파블렌드는 머티리얼이 다양한 투명도를 가질 수 있도록하여 오브젝트를 부분적으로 투명하게 만듭니다. Unity는이 블렌드 모드를 Transparent라고 합니다. 모바일 플랫폼의 경우 Unity는 알파 테스트보다 알파 ​​블렌드를 사용할 것을 권장 합니다.

Additional Material and Shader Best Practices

오버드로를 피할 수 없는 경우 셰이더를 가능한 한 간단하게 만드십시오. 다음 원칙에 유의하십시오.

- 가능한 가장 간단한 셰이더 (예 : unlit셰이더)를 사용하고 불필요한 기능을 사용하지 마십시오.

- 특별히 설계된 Unity의 내장 파티클 셰이더를 사용하세요.

- 오버 드로를 최소화하려면 게임에서 파티클의 갯수/크기를 줄이십시오.

 

정점 셰이더는 모든 정점에서 작동하는 반면 픽셀 셰이더는 모든 픽셀에서 실행됩니다. 일반적으로 화면의 정점보다 렌더링되는 픽셀이 더 많습니다. 이것은 픽셀 셰이더가 버텍스 셰이더보다 더 자주 실행된다는 것을 의미합니다. 이 때문에 가능하면 계산을 픽셀 셰이더에서 정점 셰이더로 이동하는 것이 좋습니다.

이것은 일반적으로 좋은 생각이지만 병목 현상이 발생할 경우 tiler에 주의를 기울여야합니다.

(vertex단계에서 계산하므로 fragment계산이 일부영역이 타일처럼 똑같아 지는 현상을 말하는것 같다.)
평소와 같이 최적화 작업을 마친 후에는 특정 상황에 가장 적합한 솔루션을 결정하기 위해 추가 프로파일 링을 수행해야합니다.

 

셰이더 내의 수학적 연산은 원하는 모양과 동작을 사용자 지정합니다.

그러나 이러한 수학 연산은 성능 비용 측면에서 동일하지 않습니다. 따라서 사용에주의를 기울여야합니다.

복잡한 연산에는 sin(), pow(), cos(), divide(), noise() 등이 포함됩니다.

덧셈 및 곱셈과 같은 기본연산은 처리 속도가 더 빠릅니다. 느린 수학 연산의 수를 가능한 한 적게 유지하는 것이 가장 좋습니다. 사용되는 복잡한 수학의 양은 GLES 2.0을 사용하는 장치와 같은 구형 장치에서 더 낮게 유지되어야합니다.

 

URP의 SRPBatcher를 적극 활용하여 batching을 절약할 수 있다.

Lighting

Unity에서 사용할 수있는 다양한 조명 모드가 있습니다. 이러한 모드는 씬내에서 사용되는 방식과 관련이 있습니다. 다양한 모드는 성능면에서 다르므로 조명을 구현할 때 중요한 고려 사항입니다. 

Baked 라이트 모드는 정적 조명을 제공하므로 런타임 중에 변경되지 않습니다. 베이킹은 게임을 실행하기 전에 텍스처 맵에 조명 데이터를 저장하는 프로세스입니다.

Baked 모드의 주요 주의 사항은 다음과 같습니다.

  • 조명과 그림자는 라이트 맵에 구워 지므로 런타임에 수정할 수 없습니다. 이 처리는 조명이 Unity에서 생성 될 때 수행되므로 런타임 성능에 영향을주지 않습니다.
  • 그림자는 정적이므로 게임 플레이 중에 동적 또는 움직이는 물체가 있으면 이상하게 보일 수 있습니다.
  • baked 라이트 모드는 이 가이드에서 논의하는 계산 비용이 가장 저렴한 방법입니다.

Realtime 라이트 모드는 동적 또는 이동 가능한 조명을 제공합니다. 실시간 조명 모드의 주요 기능은 다음과 같습니다.

  • 동적 조명과 그림자는 라이트 맵에 구워지지 않고 런타임에 수정할 수 있습니다.
  • 실시간 조명 모드는이 가이드에서 논의하는 가장 계산 비용이 많이 드는 조명 모드입니다.

Mixed 조명 모드는 고정 조명과 움직이는 물체를 결합합니다. 다른 두 가지 방법의 혼합으로 간주 할 수 있습니다.

혼합 조명 모드의 주요 기능은 다음과 같습니다.

  • 동적 직접 조명과 그림자를 제공합니다.
  • 라이트는 정적 오브젝트에 대한 라이트 맵 계산에 포함될 수 있습니다.
  • 빛은 이러한 개체에 대한 그림자 생성을 포함하여 동적 개체에 영향을줍니다.
  • 강도는 런타임에 변경할 수 있으며 직접 조명 만 업데이트됩니다.
  • 혼합 조명 모드는 값비싼 계산 방법입니다.

실시간 조명을 사용해야하는 경우 사용할 실시간 조명 유형을 고려해야합니다. 유형마다 계산 비용이 다릅니다.

  • Directional 라이트 : 방향이 균일한 디렉셔널 라이트는 가장 저렴한 실시간 조명입니다. 일반적으로 전체 씬을 비출 수 있기 때문에 하나의 디렉 셔널 라이트 만 필요합니다. 즉, 포워드 렌더링에서 Unity는 항상 하나의 디렉셔널 라이트를 렌더링합니다. 씬에 디렉셔널 라이트가없는 경우에도 마찬가지입니다.
  • Spot 라이트 : 스포트 라이트 는 구형 포인트 라이트보다 더 많은 물체를 컬링하기 때문에 다음으로 저렴한 실시간 조명 유형입니다. 원뿔 너비를 좁게 유지하고 최상의 성능을 얻으려면 선택한 개체에만 맞춥니다.
  • Point 라이트 : 포인트 라이트는 공간의 한 지점에 위치하며 모든 방향으로 동일하게 빛을 보냅니다.

그림자 계산은 조명에서 가장 비용이 많이드는 부분 일 수 있으므로 다양한 방향으로 빛을 비추면 그림자계산에 사용되는 계산 능력이 많아집니다.

실시간조명은 렌더링 비용이 많이 들기 때문에 모바일 게임에서는 피하는 것이 가장 좋습니다. 때때로 3D 엔진은 사용되는 장치 및 그래픽 API에 따라 사용에 제한을 둡니다. 예를 들어 Unity 유니버설 렌더 파이프 라인 포워드 렌더러에서는 오브젝트 당 조명이 8개 (또는 OpenGL ES 2.0을 사용하는 조명 4 개)로 제한됩니다.

Lighting for Static Objects

모바일 장치 용 애플리케이션을 개발할 때 정적 조명을 사용하는 것이 중요합니다. 정적 조명은 모바일 장치에서 더 빠르게 실행되며 사용자에게 더 나은 경험을 제공합니다. 움직이지 않는 오브젝트에 대한 정적 조명 정보는 베이킹 이라는 프로세스를 통해 저장할 수 있으며 ,이 과정에서 Unity는 런타임 전에 조명 계산을 수행하고 결과를 저장합니다.

이에 비해 동적 또는 실시간 조명과 같은 비 정적 조명은 모든 프레임에서 계산되고 업데이트됩니다. 이것은 장면에 드라마를 추가하고 몰입감을 높일 수 있지만 훨씬 더 비쌉니다. 따라서 비 정적 조명을 사용할 때 미적 목표와 성능 간의 균형을 염두에 두십시오.

 

베이킹 은 조명 효과에 대한 정보를 저장 하는 라이트 맵 이라는 별도의 텍스처를 생성합니다 . 이 정보는 캐시되므로 런타임에 추가 성능 비용이 없습니다. 모바일 플랫폼 용으로 빌드 할 때 가능한 한 많이 라이트 맵으로 베이킹해야합니다.

미리 구운 조명은 장면의 동적 측면에 맞게 조정되지 않습니다. 그러나 베이크 된 조명에는 장면의 모든 정적 요소에 대한 전역 조명이 포함되어있어 각 정적 요소가 간접 반사광을주고받을 수 있습니다. 이것은 조명을보다 사실적으로 만듭니다.

 

다음 이미지는 완전히 구운 장면을 보여줍니다.

Unity를 사용하면 조명을 쉽게 구울 수 있습니다. 사전에 취해야 할 두 단계가 있습니다.

1. 토글하려는 조명 구성 요소가 포함 된 게임 오브젝트를 클릭합니다. 모드를 Mixed 또는 Baked 로 설정합니다 .

모바일 플랫폼의 경우 Baked가 옵션 중 가장 저렴하므로 가능하면 혼합 대신 Baked를 선택하십시오.

2. 베이크 된 라이트를받는 GameObject를 Static으로 표시합니다 .

개체를 표시 할 수있는 여러 정적 플래그가 있지만 설정에서 Everything을 선택하는것이 일반적 입니다. 오브젝트가 Static 으로 표시 되면 Unity는 베이킹 프로세스에 포함하는 것을 알고 있습니다.

(참고 : 개체에 대해 정적 일괄 처리가 활성화 된 경우 해당 개체를 이동하거나 애니메이션 할 수 없습니다.)

조명을 베이킹 할 때 데이터는 베이킹을 시작할 때 활성화 된 씬을 기반으로 저장된다는 것을 기억하십시오.

활성 장면과 이름이 같은 폴더가 생성됩니다. 이 폴더는 베이킹 된 조명에 대한 모든 구성 요소와 데이터가 저장되는 곳입니다. 프로젝트에서 한 번에 로드되는 여러 씬을 사용하는 경우 각 씬에 개별적으로 조명을 구워야합니다. 장면에서 조명이나 오브젝트를 조정하는 경우 변경사항을 적용하려면 조명을 다시 구워야합니다. 다음 이미지는 기본 씬에 대한 조명 데이터를 보관하는 폴더의 예를 보여줍니다.

베이킹을 위해 조명을 구성한 후에는 베이킹 된 라이트 맵이 최적화되었는지도 확인해야합니다.

 

라이트 맵은 베이킹 된 설정에 따라 크기가 다릅니다. 모바일 플랫폼에서 메모리 사용량을 최소화하는 것이 가장 좋으므로 라이트 맵 크기에 세심한주의를 기울이십시오. 아래 예제 이미지에서 7 개의 1024x1024 픽셀 라이트 맵이 있음을 알 수 있습니다.

라이트 매핑 설정 (Windows> 렌더링> 조명 설정)의 다음 옵션과 실제 맵의 크기에 따라 사용되는 메모리 양이 결정됩니다.

Lightmapper

Unity의 Lightmapper는 씬에서 조명을 굽는 세 가지 방법을 제공합니다.

  • Enlighten (Unity 2019 LTS부터 deperecited되었지만 여전히 사용 가능)
  • 프로그레시브 CPU
  • 프로그레시브 GPU

프로그레시브 라이트 매퍼는 점진적으로 라이트 맵을 생성하므로 시간을 절약합니다. 경우 우선 순위 지정보기를 선택하면 씬뷰의 영역은 우선 순위. 뷰 우선 순위 지정은 씬에 대한 조명을 설정할 때 반복 속도를 높입니다.

CPU와 GPU 프로그레시브 라이트 매퍼의 주요 차이점은 라이트 맵이 CPU에서 생성되는지 GPU에서 생성되는지 여부입니다. 결과는 동일하지만 강력한 GPU가있는 경우 프로그레시브 GPU가 훨씬 빠를 수 있습니다. GPU 옵션에 대한 추가 요구 사항 및 설정은 여기 에서 찾을 수 있습니다.

Texels

A texel, or texture element, is an individual pixel in a Texture map

텍셀은 라이트가 라이트 맵의 객체에 닿는 각 지점의 조명 정보를 저장합니다. 텍셀 수를 세어 조명을 굽는 데 필요한 작업량을 측정 할 수 있습니다. 텍셀이 무엇인지, 텍셀이 조명 품질, 베이크 계산 시간, 디스크 스토리지 및 VRAM 비용에 어떻게 영향을 미칠 수 있는지 이해하는 것이 중요합니다.

필요한 라이트 맵 데이터의 양을 최소화하려면 라이트 맵 설정에서 베이킹의 각 단위에 대한 텍셀 수를 조정해야합니다. 이러한 설정을 사용하면 예제 이미지에 표시된 것처럼 각 오브젝트가 베이킹에 사용하는 텍셀 수를 포함하여 라이트 맵을 제어 할 수 있습니다.

라이트 매핑 설정에는 라이트 맵 해상도 라는 옵션도 포함되어 있습니다 . 이 옵션은 라이트 맵의 각 단위에 사용되는 텍셀 수를 결정합니다.

장면에서 텍셀이 어떻게 배치되는지 확인하려면 :

  • 씬뷰의 왼쪽 상단 모서리에 있는 Shading Mode드롭 다운을 클릭합니다 .
  • Lightmap Indices를 찾아 클릭 합니다.

구운 개체는 이제 바둑판 오버레이로 덮여 있습니다. 이것이 조명을 구울 때 텍셀이 분산되는 방식입니다.

다음 스크린 샷은 라이트 맵 해상도 설정이 다른 큐브를 보여줍니다. 

왼쪽 이미지는 1로, 중간 이미지는 2로, 오른쪽 이미지는 5로 설정

해상도가 높을수록 필요한 작업량이 어떻게 증가하는지 확인할 수 있습니다. 5에서 10 사이의 낮은 라이트 맵 해상도로 시작하고 씬에 필요한 것에 따라 확대 또는 축소해야합니다. 라이트 맵 해상도를 높이면 반복 할 때마다 크기가 엄청나게 증가합니다.

예를 들어 라이트 맵 해상도를 15에서 12로 줄이면 아래 스크린 샷과 같이 필요한 라이트 맵 수가 7 개에서 4 개로 줄어 듭니다.

라이트 매핑 설정을 사용하여 씬의 텍셀 수를 설정할 수 있지만, 더 적은 텍셀을 원하는 일부 오브젝트가 있습니다.

Unity를 사용하면 각 개체가 사용할 수있는 텍셀 수를 제어 할 수 있습니다. 오브젝트의 메시 렌더러 (Inspector>Mesh Renderer)로 이동하면 Scale In Lightmap 이라는 매개 변수가 있습니다. 이 설정을 조정하여 오브젝트가 라이트 맵에서 사용하는 텍셀 수를 변경할 수 있습니다.

다음 스크린 샷에서 왼쪽에는 라이트 맵 해상도가 5로 설정되어 있기 때문에 각 베이킹 단위에 대해 5 텍셀의 조명 정보를 얻는 평균 오브젝트가 있습니다. 오른쪽에는 Scale In Lightmap이 0.5로 설정된 상자가 있습니다.

오른쪽에있는 상자는 왼쪽에있는 상자보다 라이트 맵에서 훨씬 적은 공간을 사용합니다. 다음 스크린 샷에서 메시 렌더러 구성 요소에서 사용할 수있는 라이트 맵 설정을 볼 수 있습니다.

다음 요소에 텍셀을 사용하지 않도록하십시오.

  • 사용자가 볼 수없는 표면 및 객체. 이렇게하면 화면에 표시되지 않는 세부 사항을 위해 더 큰 라이트 맵에서 메모리를 낭비하는 것을 방지 할 수 있습니다.
  • 빛의 변화가 거의없는 표면 (예 : 그림자 속의 물체 또는 단일 빛에 닿는 물체).
  • 작거나 얇은 물체. 작거나 얇은 물체가받는 조명의 양은 장면의 최종 렌더링에 많이 추가되지 않습니다.

 

LODs and Lightmaps

모델에서 LOD를 사용하면 베이크 된 조명에 영향을줍니다. LOD 그룹에서 가장 세부적인 모델만 정적 오브젝트인 것처럼 조명이 켜지고 동일한 그룹의 나머지 모델은 동적으로 조명됩니다. 직접/간접 조명과 실시간 전역 조명에 별도의 라이트 맵이 사용됩니다.

Enlighten 라이트 매퍼를 사용할 때 시스템은 직접조명 만 베이킹합니다. 간접조명을 샘플링하려면 장면에서 라이트 프로브를 사용해야합니다.

다음 이미지는 LOD 모델의 예입니다. 라이트 프로브가 씬 주변에 배치되지 않았기 때문에 첫 번째 이미지의 LOD 0 모델 만 올바르게 조명됩니다. 두 번째 이미지는 라이트 프로브로 올바르게 조명 된 LOD를 사용하는 모델의 예입니다.

LOD 모델이 베이크 된 조명에 올바르게 적용 되도록하려면 정적 확인란 옆의 드롭 다운 메뉴에서 LOD 게임 오브젝트를 Contribute GI 로 표시해야합니다.

Light Probe Use Cases

라이트 프로브에는 두 가지 주요 용도가 있습니다.

  • 주된 용도는 씬에서 움직이는 오브젝트에 고품질 조명 (간접 반사광 포함)을 제공하는 것입니다.
  • 두 번째 용도는 풍경이 Unity의 LOD (Level of Detail) 시스템을 사용할 때 정적 배경에 대한 조명 정보를 제공하는 것입니다.

라이트 프로브는 게임을 실행하기 전에 계산할 수있는 조명 데이터를 저장한다는 점에서 라이트 맵과 동일한 이점이 많습니다. 라이트 맵은 씬의 표면에 대해 주어진 텍셀에서 받은 조명을 인코딩하는 반면, 라이트 프로브는 빈 공간을 통과하는 조명을 저장합니다. 그런 다음이 데이터를 사용하여 동적 오브젝트를 비추는 데 사용할 수 있으므로 씬 전체에서 라이트 맵 오브젝트와 시각적으로 통합 할 수 있습니다.

 

라이트 프로브는 static 씬의 빛과 그림자에 대한 정보만 저장합니다. 라이트프로브가 미리 베이킹되기 때문입니다. 동적개체, 실시간 조명 또는 셀프섀도잉에서 조명을 만드는 솔루션이 아닙니다. 그래도 라이트 프로브는 씬에 대부분의 조명을 제공 할 수 있습니다.

사용중인 라이트 프로브의 예

라이트 프로브는 정적 씬의 조명을 캡처하고 실시간 글로벌 일루미네이션보다 저렴한 비용으로 런타임에 움직이는 객체에 데이터를 적용하는 간단한 방법입니다.

Shadow

실제 그림자는 렌더링하는 데 계산 비용이 많이 듭니다. 동적 조명에 의존하는 대신 동적 개체에 가짜 그림자를 구현하는 것이 좋습니다 .

실시간 그림자는 Shadow Map이라는 기술을 사용하여 가장 자주 생성 됩니다. 그림자맵에 렌더링되는 씬지오메트리 비용은 그려지는 정점 수와 비슷합니다. 이 비용 때문에 씬에서 실시간 그림자 투사 조명의 양뿐만 아니라 ShadowCasting 지오메트리의 양을 제한하는 것이 중요합니다.

 

가짜 그림자를 구현하는 몇 가지 방법은 다음과 같습니다.

  • 캐릭터 아래에 배치 된 3D 메시, 평면 또는 쿼드를 사용하고 블러링 된 텍스처를 적용합니다.
  • 사용자 지정 셰이더를 작성하여 보다 정교한 blob그림자를 만듭니다.

그림자 메시를 사용한 그림자 구현

위 구현은 조명 정보를 텍스처에 직접 그리는 것보다 좋습니다. 이렇게하면 실시간 조명에 필요한 추가 계산이 줄어 듭니다. 채색된 조명은 또한 씬에서 라이트 맵에 필요한 텍스처 메모리가 줄기 때문에 장면에서 조명을 베이킹 할 때 메모리를 절약합니다.

 

가능한 경우 셰이더 또는 머티리얼을 사용하여 조명을 시뮬레이션합니다. 커스텀 머티리얼을 사용하여 다양한 종류의 조명 효과를 시뮬레이션 할 수 있습니다. 예를 들어 캐릭터의 가시성과 시각적 모양을 개선하기 위해 rim-light을 사용하도록 할 수 있습니다. 

 

씬에서 사용하는 조명의 종류에 관계없이 메시렌더러 설정이 올바른지 확인하는 것이 중요합니다.

좋은 원칙은 사용하지 않을 모든 것을 끄는것입니다. Cast Shadows 와 같은 설정 은 오브젝트가 꺼져 있어도 장면 렌더링에 추가 비용을 추가 할 수 있습니다. 다음 스크린 샷은 메시 렌더러 설정의 예를 보여줍니다.

스크린 샷에 표시된 옵션은 가장 가까운 프로브의 조명 정보를 혼합하여 반사가 아닌 조명을 받도록 설정되어 있습니다. Blob 메서드를 사용하고 있기 때문에 Cast Shadows 가 꺼져 있습니다. 씬이 구워지고 실시간그림자를 드리우는 것이 없기 때문에 Receive Shadow도 선택 해제됩니다.

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/09   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30