어영부영TA (AI신과함께)

Quality는 High, medium, Low만 있는 것은 아니고 개발에 따라서 단계를 더 많이 나눌 수 있습니다.
그럼...
PC개발의 경우 개인적으로 스팀의 하드웨어 스펙을 기준으로 삼으면 좋지 않을까 싶습니다.
https://store.steampowered.com/hwsurvey/videocard/

저는 medium을 현시점 많이 사용되는 GTX 1060을 기준으로 잡았습니다.
Low는 GTX 970 정도로 High는 3060 정도로...

아래는 제가 개발하던 게임을 각각 하드웨어에서 60fps가 나오도록 체크하면서 세팅한 값입니다.
좋은 기준이 되리라 생각됩니다.(게임 따라 다르겠지만, 비슷하지 않을까 생각됩니다.)
보시면 대략적으로 수치를 낮춘 것이 low이며, High는 높게 설정한 겁니다.
각각의 기능에 대한 내용은 유니티 문서를 참고하시기 바랍니다.
(저는 Foward Only로 설정하였습니다만, Raytracing이 효과적인 게임과 많은 수의 실시간 라이팅이 요구되는 게임은 Deferred Only 세팅을 하는 것이 맞으리라 생각됩니다.)

Max shadow resolution을 256 이하로 지나치게 낮추면 오히려 역효과라는 것이 이 부분에서는 중요한 포인트라고 할 수 있습니다.(이유는 모르겠으나 프레임 저하가 더 많이 발생하였습니다.)

Low의 경우 설정만으로 Frame이 나오질 않아서 폴리곤 외에도 카메라의 TAA설정과 포스트 프로세싱 자체를 꺼서 Low에서 원활히 돌아가도록 설정하였습니다.

☆ 추가내용
정확한 원인은 알수는 없었지만 저희게임은 운동장에 디렉션 라이트가 하나만 있는 상황이었는데 gtx 750에서 deferred 가 forward보다 5~10프레임의 이득인 효과를 보았습니다. 원칙적으로 따지면 조명이 하나라서 포워드가 빨라야한다고 생각했지만 디퍼드가 더 효과가 좋았습니다.

https://github.com/madumpa/URP_StylizedLitShader

마둠파님의 스타일라이즈 셰이더가 참 괜찮더군요.

다만, HLSL기반이라 그런지 코드분석에는 어려움이 있었습니다.(아직도 뭐가뭔지...)

그러다가, 작은 부분에 욕심이 생기어서 마스크맵중에 B채널을 emission으로 사용할 방법이 없을까 고민하였습니다.

어차피 마스크맵중에서 RGBA중에서 R은 matellic고, A는 smoothness이고, G는 AO로 사용하는데... B채널을 emission전용으로 쓰면 좋을거 같다는 생각이 들었습니다.

그래서 이러저리 헤메다가 간단하게 코드하나를 추가하여 마무리 하였습니다.

실제 개발에 사용될지는 알수없으나, 사용하게 되면 마둠파님한테 메일을 보내려고 합니다.

//color += emission; // 원본
color += emission.bbb*_EmissionColor.rgb;// B채널을 사용하기위한 추가사항	
return half4(color, alpha);

Shader "URPTraining/TextureAlpha"
{

	Properties{

	_MainTex("Main Texture", 2D) = "white" {}
	_Transparency("Transparency", Range(0,1)) = 0.5

	}

		SubShader
	{
		Tags
	{
		"RenderPipeline" = "UniversalPipeline"
		"RenderType" = "TransparentCutout"
		"Queue" = "Alphatest"
	}
		Pass
	{
		Name "Universal Forward"
		Tags{ "LightMode" = "UniversalForward" }

		Blend SrcAlpha OneMinusSrcAlpha
		Cull Back
		Zwrite off

		HLSLPROGRAM
#pragma prefer_hlslcc gles
#pragma exclude_renderers d3d11_9x

#pragma vertex vert
#pragma fragment frag


#include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Lighting.hlsl"

#pragma multi_compile _ _MAIN_LIGHT_SHADOWS // sbr batcher

		CBUFFER_START(UnityPerMaterial) // sbr batcher

		float _Transparency;
	float4 _MainTex_ST;
	Texture2D _MainTex;
	SamplerState sampler_MainTex;

	CBUFFER_END // sbr batcher

		struct VertexInput
	{
		float4 vertex : POSITION;
		float2 uv       : TEXCOORD0;
	};

	struct VertexOutput
	{
		float4 vertex  	: SV_POSITION;
		float2 uv      	: TEXCOORD0;
	};

	VertexOutput vert(VertexInput v)
	{
		VertexOutput o;

		o.vertex = TransformObjectToHClip(v.vertex.xyz);
		o.uv = v.uv.xy * _MainTex_ST.xy + _MainTex_ST.zw;

		return o;
	}

	half4 frag(VertexOutput i) : SV_Target
	{
		float4 color = _MainTex.Sample(sampler_MainTex, i.uv);

		color.a *= _Transparency;

		return color;
	}
		ENDHLSL
	}
	}

}

URP의 Quality 셋팅의 연관 관계입니다.

이전에 빌트인 쉐이더와 다르게 Quality 셋팅을 Render Pipleline을 통해서 셋팅되는것을 볼수 있습니다.

(개인적으로 테스트하고 세팅한 값들이라 오류가 있을 수 있습니다.)

HDRP Project setting은 개인적으로 굉장하다고 생각됩니다.(더 많은 옵션이 있으면 좋겠다는...)

URP에서의 Project setting는 뭐랄까 굉장히 제약이 많고 할수 있는게 별로 없다는 느낌이지만, 

HDRP Project setting 정말 많은 부분을 직접 설정할수 있다는게 굉장히 매력적입니다.

Project Setting을 열어 초기 셋팅을 시작합니다.

HDRP는 기본적으로 Linear로 설정이 되어 있지만, 처음에 확인하는 것이 좋습니다.

이게 왜 중요한가는 화면에 보이는 방식과 Shader를 계산할때 수치적으로 정확하게 하기 위함이라고 생각하고 넘어가면 될 거 같습니다.

(감마와 리니어에 대한 장단점은 대마왕님 강의를 검색하셔서 보시는것을 추천합니다.)

그다음은 Graphics인데, 이게 개인적으로는 초기에는 Quality랑 좀 헛갈리는 부분이 있었습니다.

둘다 똑같이 HDRenderPipelineAsset이라는 놈을 사용합니다.

그냥 두시면됩니다. 그냥 기본적인 게임 Quality셋팅이라고 할수 있습니다.

DefaultHDRPAsset을 임의로 설정할수 있는데, 어차피 Quality에서 설정하기 때문에 이부분은 구지 건드릴 필요는 없다고 생각됩니다.(이렇게 말하면서, 본인은 medium HDRenderPipelineAsset을 여기에 바꿔놓았고..)

Quality에서 보면 이렇게 보이는것을 알수 있습니다.

그다음은 HDRP Default Settings로 넘어가서 대부분 그대로 두면되는데,

중요한 부분은 Light Layer names과  Volume Components를 설정하는 것입니다.

Light Layer name은 조명 레이어 설정할때 이름 변경하는 부분입니다.(기본으로 둬도 상관없는데, 은근히 헛갈리기 때문에 이름을 바꿔서 사용합니다. 레이어 이름을 어디서 변경하나 했더니...여기있었군요...)

Volume Components를 확인하면, 기본적으로 뭔가 많이 있습니다.

이부분은 Scene을 구성할 때 기본적으로 설정하는 포스트프로세싱입니다.

전체적으로 어떤 분위기를 잡기 위해서 설정하는 것인데, 스테이지마다 분위기가 다르고 설정해야 할 값이 다르다면

Scene에서 직접 구성하는 것 좋기 때문에 대부분 삭제하는 것 좋습니다.

전 개인적으로 Exposure를 제외하고 다 없애고 사용합니다. 어차피 Scene에서 Exposure(노출)를 따로 조정하기 때문에 이것도 의미가 크게 있진 않지만 통일된 기본셋을 하나는 넣어 두는 것이 좋다고 생각합니다.

(그외에 Shadows 처럼 크게 변경되지 않는 것들을 넣어두면 편리합니다.)

그리고, LookDev Volume이라는 것이 있는데, 이건 임시로 모델링에 포스트프로세싱을 볼 수 있게 해주는 별도의 툴인데,  게임 설정과는 아무런 상관이 없는 부분이라 무시하셔도 됩니다.(이게 뭔지 한참을 찾았다는...)

다음 제일 중요한 퀄리티 셋팅 부분입니다.

이부분을 어떻게 설정하느냐에 따라 고사양 컴퓨터와 저사양 컴퓨터에서 돌아가게 하는것을 결정하는 곳이기 때문입니다. 말그대로 퀄리티를 설정하는 부분인데, 각각 설정을 어떻게 하느냐에 따라서 포스트프로세싱이나 그림자의 퀄리티가 결정이 됩니다. 아래는 기본 HDRP 설정입니다.

근데, Quality 아래에 HDRP가 또 있습니다.

이게 뭐냐면 Quality에 있는 Very low, Medium, Ultra를 각각 컨트롤 하는 부분입니다.

일종에 세부 설정입니다.

근데, 이게 Inspector에서도 수정할수 있는 부분입니다.(편의상 이곳에 해놓은거 같습니다.)

이 퀄리티 파일은 Project에서 우클릭하여 아래처럼 생성할수 있습니다만, 아무래도 유니티에서 제공되는 기본을 가지고 변경하는것이 뭔가 맘이 편합니다.

중요한 Quilty 셋팅은 다음장으로...

using UnityEngine;
using UnityEditor;
using System.Collections;
using System.Collections.Generic;
using UnityEngine.UI;

#if UNITY_EDITOR // 빌드시 제외시키는 기능이다.

public class LayerChanger : EditorWindow
{
    [MenuItem("RHY/LayerChanger", false, priority: 1)]//메뉴생성


    static void ShowWindow()
    {
        // 생성되어있는 윈도우를 가져온다. 
        LayerChanger window = (LayerChanger)EditorWindow.GetWindow(typeof(LayerChanger));

    }


    void OnGUI()
    {

        if (GUI.Button(new Rect(50, 80, 180, 40), "LayerChanger"))
        {
            SkinnedMeshRenderer [] MeshR = FindObjectsOfType(typeof(SkinnedMeshRenderer)) as SkinnedMeshRenderer[]; //SkinnedMeshRenderer를 찾는다.

            List<GameObject> listGO = new List<GameObject>(); // 하나씩 찾는다.
            if (MeshR != null)
            {
                for (int i = 0; i < MeshR.Length; i++)
                    listGO.Add(MeshR[i].gameObject);
            }

            Selection.objects = listGO.ToArray(); // 선택하여준다.

            //  MeshR = GetComponentsInChildren<SkinnedMeshRenderer>();
            foreach (var meshRenderer in MeshR) //각각 물체에 레이어를 넣어준다
            {
                meshRenderer.renderingLayerMask = 1; // 첫번째 레이어 설정

                meshRenderer.renderingLayerMask |= 1 << 1; // 추가 레이어 설정
                
            }


        }
    }

}

#endif

플랫폼 전환 사이에 일어나는 엄청난 리임포트 시간을 줄이기 위한 것으로 캐쉬된 리소스를 이용하여 리임포트 시간을 현저히 줄여준다고 합니다.

참고: https://lunchballer.com/archives/700

https://docs.google.com/document/d/1UX0319CXa29fCFAgg0qa5vnH-U6875jt0KLKUk5mke8/edit

https://www.youtube.com/watch?v=mlNWoROvavY 

SubShader
    {
       Tags { "RenderType" = "Opaque"
              "RenderPipeline" = "UniversalPipeline"
              "UniversalMaterialType" = "SimpleLit" 
              "IgnoreProjector" = "True"
              "ShaderModel"="4.5"}
        Pass
        {
           Name "ForwardLit"
           Tags { "LightMode" = "UniversalForward" }
           …
        }
   
        Pass
        {
            Name "ShadowCaster"
            Tags{"LightMode" = "ShadowCaster"}
          …
        }
       Pass
        {
            Name "GBuffer"
            Tags{"LightMode" = "UniversalGBuffer"}
        …
        }
       Pass
       {
            Name "DepthOnly"
            Tags{"LightMode" = "DepthOnly"}
       …
       }

아무리봐도 그다지 차이가 없는데, 풀 코드를 봐서도 그다지 두개의 차이점을 알아낼수가 없었습니다.

다만, 모바일에는 path를 주어서 path을 막아버릴수 있다는거 외에는 그래서 뭐가 정확히 다른가하고 문의한 결과.

Each shader in the UTS2 mobile version omits the FORWRD_DELTA pass.
This pass functionally handles the toon processing of the real-time point light, but since the real-time point light itself is a heavy function in the mobile environment, we have omitted this pass to reduce the task of shaders.

라고 답변이 왔습니다.

짧은 번역 능력으로 해설하자면, 모바일은 FORWRD_DELTA pass가 빠져있어서, 리얼타임 포인트라이트가 영향을 받지 않도록 설계가 되어있다고.... 

해서 다시 코드를 보니.. 빠져있군요.. 아직 갈길이 멀었군요.. 이정도는 눈치챘어야했는데.ㅋ

글로만 봐서는 뭔가 현실감이 없어서 직접 압출율을 테스트 진행해봤습니다.

상황에 따라 다르지만, RGB Crunched ETC가 좋네요.