기록

버전 : Unity 6

구글 계정에 연동과정

Google Sign In SDK에서 ID 토큰, 액세스 토큰을 받는다.

Firebase Authentication으로 Google ID 토큰을 Firebase로 전달하고 이를 인증한다.

Google Sign In SDK는 구글 계정으로 로그인할 수 있지만 이후 로그인한 사용자를 앱의 인증 시스템에서 관리할 방법이 없다.

또한 Google ID 토큰을 앱에서 직접 검증하는 것은 보안상 위험하기 때문에 파이어베이스를 통해서 토큰을 검증하고 관리하여 안전하게 관리할 수 있고 파이어베이스의 다양한 기능과 연계하여 사용할 수도 있다.

1. 파이어베이스 인증 SDK 설치

Firebase Authentication SDK

다운로드한 압축 파일에서 FirebaseAuth.unitypackage 패키지를 프로젝트에 임포트

2. Google-Signin-Unity

Google-SignIn-Unity

최신버전 1.0.4 사용

* 프로젝트에 임포트하면 Unity.Task 관련해서 충돌 에러가 발생하는데 Assets > Parse  폴더를 지우면 해결 가능하다.

설치 후 패키지 문제 없는지 테스트 빌드를 진행

gradle 에러가 발생해서 빌드에 실패한다. 안드로이드 빌드 시 자주 발생하는 에러로 이런 경우 프로젝트 세팅의 최소 타겟 API를 올리면 해결되는 경우가 많은데 먼저 이 부분을 확인해서 다시 빌드해 본다.

Minimum API Level 23 -> 24로 변경 후 다시 빌드하니 해결되었다.

3. Key Store 생성

파이어베이스에서 인증 정보를 저장하고 관리할 프로젝트를 생성해야 하는데 이때 유니티 프로젝트의 SHA 키가 필요하다.

먼저 유니티에서 키스토어를 생성하고 SHA를 확인해 둔다.

1. 키스토어 생성

2. SHA 확인

키스토어를 열어보기 위해서는 keytool을 사용해야 하는데 유니티 에디터를 설치하면 포함되어 있기 때문에 에디터 설치 경로에서 

keytool.exe 파일이 위치한 경로에서 명령 프롬프터를 켜서 'keytool -list -keystore [키스토어 경로]' 를 실행한다.

* 구글 계정 인증에는 SHA-1 이 필요한데 Unity 6 버전의 keytool을 사용했더니 256만 뜨고 나머지 지문들은 생략된다.

   다른 에디터 버전의 keytool을 사용해서 SHA-1을 확인하고 메모해 둔다.

해당 키는 잠시 메모해 둔다.

4. 파이어베이스 프로젝트 세팅

Firebase

로그인 인증을 처리할 프로젝트를 생성한다.

유니티 플랫폼을 선택해서 앱을 추가한다.

여기서 디지털 지문 추가에서 키스토어의 SHA 키를 입력한다.

Authentication 항목으로 들어가서 로그인 제공업체를 추가한다.

Google을 선택하고 사용설정을 해준다.

5. 클라이언트 ID 확인

Google Cloud

구글 클라우드에 접속하면 파이어베이스에서 생성했던 프로젝트와 동일한 정보로 프로젝트가 생성되어 있다.

이 중에서 사용자 인증 정보 항목에서 OAuth 2.0 클라이언트 ID를 사용해서 유니티에서 접속을 시도한다.

6. 로그인 스크립트

유니티로 돌아가서 로그인 스크립트를 구현한다.

* 에러

SignIn 함수 호출 시 계정 선택 UI 팝업이 뜬 후 계정을 선택하고 나서 반응이 없는 현상이 있었는데 결과를 받아서 처리하는 콜백에서 에러가 발생했었다.

이때 메인스레드에서 처리되도록 Dispatcher 함수를  구현해서 처리하니 문제가 해결되긴 했는데 정확한 원인은 확인을 못한 부분이다.

using System.Collections.Generic;
using UnityEngine;

public class MainThreadDispatcher : MonoBehaviour
{
    private static MainThreadDispatcher instance;
    private readonly Queue<System.Action> executionQueue = new Queue<System.Action>();

    private void Awake()
    {
        if (instance == null)
        {
            instance = this;
            DontDestroyOnLoad(gameObject);
        }
        else
        {
            Destroy(gameObject);
        }
    }

    private void Update()
    {
        lock (executionQueue)
        {
            while (executionQueue.Count > 0)
            {
                executionQueue.Dequeue()?.Invoke();
            }
        }
    }

    public static void RunOnMainThread(System.Action action)
    {
        if (instance != null)
        {
            lock (instance.executionQueue)
            {
                instance.executionQueue.Enqueue(action);
            }
        }
    }
}

디스패처를 사용해 SignIn 함수 결과를 처리한다.

using Google;
using System.Collections.Generic;
using System.Threading.Tasks;
using UnityEngine;

public class GoogleLogin : MonoBehaviour
{
    private string web_client_id = "구글 클라우드의 클라이언트 ID";

    private void Awake()
    {
        Init();
    }

    private void Init()
    {
        GoogleSignIn.Configuration = new GoogleSignInConfiguration
        {
            WebClientId = web_client_id,
            UseGameSignIn = false,
            RequestEmail = true,
            RequestIdToken = true
        };
    }

    public void SignIn()
    {
        DebugMessage.Instance.ShowMessage("Calling SignIn");
        Debug.Log("Calling SignIn");
        GoogleSignIn.DefaultInstance.SignIn().ContinueWith(
          OnAuthenticationFinished);
    }

    internal void OnAuthenticationFinished(Task<GoogleSignInUser> task)
    {
        Debug.Log("Authentication finished, processing on main thread");
        MainThreadDispatcher.RunOnMainThread(() => ProcessAuthResult(task));
    }

    private void ProcessAuthResult(Task<GoogleSignInUser> task)
    {
        Debug.Log("Auth Result");
        if (task.IsFaulted)
        {
            using (IEnumerator<System.Exception> enumerator = task.Exception.InnerExceptions.GetEnumerator())
            {
                if (enumerator.MoveNext())
                {
                    GoogleSignIn.SignInException error = (GoogleSignIn.SignInException)enumerator.Current;
                    DebugMessage.Instance.ShowMessage("Got Error: " + error.Status + " " + error.Message);
                    Debug.Log("Got Error: " + error.Status + " " + error.Message);
                }
                else
                {
                    DebugMessage.Instance.ShowMessage("Got Unexpected Exception?!?" + task.Exception);
                    Debug.Log("Got Unexpected Exception?!?" + task.Exception);
                }
            }
        }
        else if (task.IsCanceled)
        {
            DebugMessage.Instance.ShowMessage("Canceled");
            Debug.Log("Canceled");
        }
        else
        {
            DebugMessage.Instance.ShowMessage("Welcome: " + task.Result.DisplayName + "!");
            DebugMessage.Instance.ShowMessage(task.Result.Email + "!");
            DebugMessage.Instance.ShowMessage(task.Result.IdToken + "!");

            Debug.Log("Welcome: " + task.Result.DisplayName + "!");
            Debug.Log(task.Result.Email + "!");
            Debug.Log(task.Result.IdToken + "!");
        }
    }
}

폰트에 한글이 지원되지 않아서 깨진 것 빼고는 로그인 성공 후 들어오는 리턴 정보를 로그로 찍은 값들이 잘 출력되는 게 확인된다.

최근에 UI 애니메이션을 작업하다 정리가 필요한 부분이 있어서 작성한다.

2D Sprite

2D 스프라이트의 애니메이션은 리소스와 Animator를 가지고 만들 수 있다.

원하는 프레임마다 스프라이트를 변경하는 방식으로 애니메이션을 만들 수 있다.

UI Animation

UI 경우에도 애니메이션으로 컨트롤하는 경우에는 동일한 방식으로 처리된다.

Effect

Sprite Renderer를 사용하는 상황에서 뭔가 발산하는 이펙트를 사용한다면 어떻게 하는 게 좋을까 생각하면서 파티클 시스템과 오브젝트를 직접 제어하는 방법 두 가지를 사용해 보았다.

있는 리소소 가지고 대충 테스트만 하려고 만들다 보니 별로 이뻐 보이진 않는다.

이러한 상황에서는 오브젝트를 가지고 직접 제어하는 게 나은 방식인 거 같다.

실제로 사용한다면 풀링을 해서 쓰겠지만 그럼에도 상당히 많은 오브젝트를 뿜어낸다면 파티클을 쓰는 게 적합하다고 보인다.

상황에 맞게 잘 조율하는 게 필요하다.

위에서 사용한 코드

using UnityEngine;

public class Coin : MonoBehaviour
{
    private const float power = 10f;
    private void OnEnable()
    {
        transform.position = Vector3.zero;
        ApplyForce();
    }

    private void ApplyForce()
    {
        var rb = GetComponent<Rigidbody2D>();
        float randomHorizontal = Random.Range(-1f, 1f); // -1 to 1 for left/right
        Vector2 direction = new Vector2(randomHorizontal, 1f).normalized;
        rb.AddForce(direction * power, ForceMode2D.Impulse);
    }
}

using UnityEngine;

public class Coin : MonoBehaviour
{
    private const float power = 10f;
    private void OnEnable()
    {
        transform.position = Vector3.zero;
        ApplyForce();
    }

    private void ApplyForce()
    {
        var rb = GetComponent<Rigidbody2D>();
        float randomHorizontal = Random.Range(-1f, 1f); // -1 to 1 for left/right
        Vector2 direction = new Vector2(randomHorizontal, 1f).normalized;
        rb.AddForce(direction * power, ForceMode2D.Impulse);
    }
}

대충 동전이 뿜어지는 듯한 모습을 중점으로 만들었다.

Coin 간에는 충돌처리하면 초기 한 위치에 모여있을 때 서로 부딪혀서 Physics2D > Layer Collision Matrix를 꺼두었다.

바닥에 충돌 후 튕기는 것과 미끄러지는 정도는 Phsics Material로 조절한다 (Friction 마찰력, Bounciness 탄성력)

UI Effect

위 내용들은 겸사겸사로 같이 정리한 내용이고 이 글을 쓰기 시작한 이유는 이 부분 때문이었다.

상황은 대충 이렇다.

간단한 퍼즐 게임을 만드는 중에 스프라이트 렌더러를 쓰기에는 귀찮은 부분들이 있어서 간단하게 만들려고 UI를 베이스로 해서 게임 로직들을 만들었고 그렇게 진행하다 보니 효과를 추가하는 과정에서 물리적인 부분을 사용할 수 없어 직접 위치를 이동시켜서 유사하게 재현할 수밖에 없었다.

using UnityEngine;

public class UICoinMaster : MonoBehaviour
{
    [SerializeField] UICoin[] uiCoins;

    bool isOn = false;
    public void OnClick_UICoinMaster()
    {
        if (isOn)
        {
            foreach( var coin in uiCoins)
            {
                coin.gameObject.SetActive(false);
            }
            isOn = false;
        }
        else
        {
            foreach (var coin in uiCoins)
            {
                coin.gameObject.SetActive(true);
            }
            isOn = true;
        }
    }
}


using UnityEngine;

public class UICoin : MonoBehaviour
{
    [SerializeField] private float initialForce = 10f;
    [SerializeField] private float gravity = 9.8f;
    [SerializeField] private float bounceForce = 0.5f;
    [SerializeField] private bool isMoving = false;

    private RectTransform rect;
    private Vector2 velocity;
    private Vector2 originPos;
    private void Awake()
    {
        rect = GetComponent<RectTransform>();
        originPos = rect.position;
    }

    private void OnEnable()
    {
        ApplyPower();
    }

    private void OnDisable()
    {
        rect.position = originPos;
    }

    private void ApplyPower()
    {
        float randomX = Random.Range(-1f, 1f);
        velocity = new Vector2(randomX, 1f).normalized * initialForce;
        isMoving = true;
    }

    private void Update()
    {
        if (!isMoving) return;

        velocity.y -= gravity * Time.deltaTime;

        rect.anchoredPosition += velocity * Time.deltaTime;

        if (rect.anchoredPosition.y < 0)
        {
            rect.anchoredPosition = new Vector2(rect.anchoredPosition.x, 0);
            velocity.y = -velocity.y * bounceForce;
            velocity.x *= 0.8f;
            
            if (Mathf.Abs(velocity.y) < 0.1f)
            {
                isMoving = false;
            }
        }
    }
}

UI 크기에 맞춰서 값들을 적절하게 세팅하면 그럴듯해 보인다. 구현하는 데는 크게 무리가 없지만 UI 가지고 이래도 되나 싶은 생각이 들기도 한다.

개인적으로는 필요한 기능만 직접 구현해서 쓰는 걸 선호하는 편이라 잘 쓰진 않지만 위처럼 UI를 제어하는 데는 DoTween을 사용하는 게 더 간단하고 다양한 동작들도 처리할 수 있을 것이다.

UI Particle System

한 번쯤은 'UI위에 파티클 뿌리기'에 대해서 많은 고민과 탐구를 해보았을 것이다. 이 경우 나는 주로 카메라의 렌더링 모드를 Screen Space - Camera로 세팅해서 파티클을 보이게 하는 방법을 사용했다. 그런데 이 방법은 원하는 파티클을 사용할 때나 좌표계를 다룰 때 은근히 귀찮고 까로운면이 있었다.

그래서 이번에 좀 더 찾다 보니 좋은 방법을 알게 되었다.

https://github.com/Unity-UI-Extensions/com.unity.uiextensions.git

UI Extensions 라이브러리로 여기에서 UIParticle System을 사용하면 파티클을 UI 위에 렌더링 할 수 있는 상태로 만들 수 있다.

해당 라이브러리에 대해서는 알고는 있었는데 파티클 관련 기능이 있었다는 건 이번에 알게 되었다.

이와 관련해서 UIParticle System 사용방법과 파티클의 기본 사용방법을 배우기 좋은 영상을 메모해 둔다.

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

파티클을 조금 참고해서 만들어 적용시켜 본다.

효과를 주고 싶은 UI의 자식에 파티클을 할당하면 UI와 동일한 렌더링 우선순위로 처리가 된다는 점에서 원하는 기능 그 자체였다.

Performance

겸사겸사로 추가된 내용들이 많지만 결국 UI로 동작들을 구현해 버리면 성능상에 좋지 않은 건 사실이고 권장되는 방식도 아니다.

가장 큰 이유는 UI는 변경될 때마다 캔버스가 리빌드를 돌리기 때문에 이러한 동작이 과도하게 발생되며 이 연산은 CPU에서 처리하기 때문에 신경이 안 쓰일 수 없지만 어느 정도 타협해서 사용한다면 괜찮지 않을까 생각도 든다.

UI로 만들어봤자 엄청나게 복잡한 게임도 아닐 것이고 퍼즐 게임 정도면 성능상에 이슈를 발생시킬 만큼은 아닐 것이라고 감히 예상한다.

정말 괜찮은지는 프로파일링을 해봐야겠지만 궁금하기도 하니 나중에 시간 날 때 게임 오브젝트와 UI로 구현한 것을 각각 최대한 비슷하게 만들어 놓고 성능을 한 번 비교해 보는 것이 괜찮을 것 같다.

유니티에서 개발을 하면서 에셋을 이것저것 가져와서 필요한 걸 골라서 사용하기도 한다.

여러 가지 사운드 리소스를 틀어가면서 적당한 걸 고르는 경우나 이미지를 돌려가며 잘 어울리는 걸 선택하는 경우가 있다.

하지만 에셋을 여러 경로에서 다운로드하다 보면 폴더의 경로나 파일의 네이밍이 제각각이기 때문에 하나씩 틀어보는 게 쉽지 않다.

이럴 때 특정 유형의 리소스만 모아서 보는 게 편한데 프로젝트 창의 검색 기능을 활용하여 특정 유형의 파일만 모아서 볼 수 있다.

- 텍스처 파일 검색 : 't:Texture2 D'

- 오디오 파일 검색 : 't:AudioClip'

- 프리팹 검색 : 't:Prefab'

- 스크립트 파일 검색 : 't:Script'

- 머티리얼 검색 : 't:Material'

- 애니메이션 검색 : 't:AnimationClip'

- 모델 검색 : 't:Model'

't:<타입>'은 특정 타입의 에셋을 검색하는 키워드이다.

<타입>에 원하는 유형으로 검색하여 원하는 에셋을 찾기 쉽다.

그 밖에도 유니티 검색창에서 사용할 수 있는 특정 키워드가 존재한다.

'l:<레이블>' : 특정 레이블이 있는 에셋을 검색한다.

레이블은 에셋을 그룹화하는 데 사용할 수 있는 태그 같은 것으로 에셋을 선택하고 인스펙터 창의 하단에 있는 UI를 통해서 레이블을 확인하고 변경하거나 추가할 수 있다.

새로운 레이블을 추가하는 방법은 원하는 이름을 작성하고 엔터를 입력하면 추가된다.

이 기능들은 검색창의 옆에 있는 토글들을 통해서도 사용할 수 있다.

바이너리와 텍스트(YAML) 비교

비주얼 스튜디오에서 바이너리를 볼 수 있는 확장 툴을 설치해서 해당 파일을 분석해 본다.

프로젝트 설정 중에서 에셋 데이터를 관리하는 방식인 바이너리와 텍스트 두 가지에 대해서 몇 가지 테스트를 해볼 것이다.

두 방식을 비교해 보기 위해서 프로젝트에서 모든 컴포넌트의 데이터가 동일한 오브젝트를 생성해 보고 차이점을 비교한다. 

하이어라키에서 큐브를 생성하고 프리팹으로 만들어 파일을 확인해 본다.

파일의 크기는 3kb이며 파일 내용은 YAML 형식으로 오브젝트의 모든 컴포넌트의 정보가 저장되어 있다.

길이는 100줄 정도 된다.

데이터 내용을 그대로 보아도 어떤 정보를 담고 있는지 파악하기 쉽다.

그대로 프로젝트 세팅에서 Asset Seriailization 모드를 Force Binary로 변경한다.

용량이 더 줄어들었을 거라고 예상했지만 반대로 증가했다.

파일의 마지막은 다음과 같이 정보를 보여준다.

좌측의 메모리주소와 우측의 아스키코드에 대응하는 문자는 편집기의 기능으로 데이터에 포함되지 않는 정보일 것이다.

맨 앞의 8자리 숫자+알파벳의 조합은 16진수로 보인다.

이 주소가 16 단위로 증가하고 뒤에 오는 정보는 8 + 8 총 16으로 정보의 개수를 의미하는 것 같다.

메모리 주소 뒤에 오는 행렬 형태의 정보는 아스키코드로 보이는데 아스키 테이블에서 20은 공백, 3C는 < 로 확인할 수 있다. 따라서 맨 우측에는 테이블에 대응하는 문자를 확인된다.

마지막 주소가 2030으로 10진법으로 변환 시 8240이다. 즉 총 8240개의 데이터가 담겨있으며 파일의 크기가 9kb인 것으로 생각해 볼 때 하나에 1byte로 떨어지고 각 데이터가 아스키코드이므로 1byte라고 생각하면 얼추 맞아떨어지는 거 같다.

파일크기는 9kb로 나오는데 해당 파일을 속성을 열어서 자세히 보면

더 근접한 크기임을 알 수 있다. 

좀 더 정밀하게 계산하면 마지막 줄에는 데이터 4개가 빠져있어서 8236이다. 즉 최종적으로 16byte가 모자라다.

만약 마지막 메모리가 온전히 16을 차지한다고 해도 8240이 최대일 텐데 그래도 12byte가 채워지지 않는다.

어디서 계산이 잘못된 건지 이 부분은 다시 확인해 볼 필요가 있다.

다시 본래의 목적으로 돌아가서 YAML 형식이 바이너리보다 용량이 적은 것은 의문이 들어서 프리팹의 크기를 키워보기로 한다. 기존의 큐브 프리팹에 자식으로 큐브를 추가해서 수정해 결과를 확인해 본다.

바이너리의 경우 768 byte 가 추가되었다.

모드를 변경해서 Text의 크기를 확인해 보니 6kb로 처음 경우에서 2배로 사이즈가 커졌다. 증가량만 따졌을 때는 엄청난 크기 차이가 있다.

몇 번 더 큐브를 추가해 보면서 살펴본다.

프리팹에 오브젝트가 많이 포함되어 있을수록 파일의 사이즈는 확연히 차이가 난다.

게임을 만들다 보면 프리팹 하나에 여러 오브젝트들이 붙어있게 되는 경우는 많기 때문에 거의 일반적으로 Text 모드가 용량이 크다고 보인다.

비교

테스트 결과로 비교해 보면 바이너리를 사용하는 것이 데이터의 크기를 줄여주기 때문에 프로젝트를 열고 데이터를 저장하는 과정에서 시간이 단축될 수 있다.

하지만 유니티를 사용한 프로젝트를 협업할 때에는 바이너리보다는 Text 가 권장된다. Github에서는 공식문서에서 해당 부분에 대하여 Force Text로 설정해야 한다고 명시해 두었다.

Github - Git and Unity

유니티에서도 기본값은 Force Text이며 이렇게 Force Text를 권장하는 이유는 바이너리 형식으로는 파일을 수정하고 병합하는 것이 불가능하다. 따라서 변경된 사항을 파악하는 것이 불가능한데 협업뿐만 아니라 개인 프로젝트 또한 버전 컨트롤을 사용하는 것이 일반적인데 해당 기능을 사용하지 못하는 Mixed 또는 Binary 모드는 더 이상은 사용되지 않는 기능으로 생각된다.

에디터 버전 : 2021.3.28f1 (LTS)

유니티 에디터의 전체적인 설정을 변경할 수 있는 항목이다.

Unity Remote [Depricated]

Android, iOS 등 앱을 개발할 때 사용하기 위한 기능으로 유니티 플레이 모드에서 화면 출력과 입력이 디바이스와 연결되도록한다. 따라서 빌드 이전 단계에서 타겟 디바이스를 통한 테스트가 가능하다.

2020.1 및 이후 버전에서는 depricated 되었으며 Device Simulator Package가 기능을 대신한다.

Device Simulator Package

2020 이후 버전이라면 에디터에 기능이 포함된 상태로 Window > General > Device Simulator 를 통해 사용할 수 있다.

이전 버전의 경우 패키지를 설치해 주어야 창을 열 수 있다.

패키지 매니저를 통해서 설치가 가능하며 이 때 패키지가 검색해도 나오지 않는 경우 

패키지 매니저 창에서 어드밴스 설정에 들어가서 

Pre-release Package 옵션을 활성한 이후에 패키지를 검색하면 찾을 수 있다.

Asset Serialization

프로젝트를 저장할 때 에셋들의 정보를 저장하는 방식에 대해서 설정할 수 있는 옵션이다.

Serialization 옵션에는 세가지가 있다.

Mixed

에셋이 바이너리와 문자열 각각의 저장된 상태로 유지된다. 새로 추가되는 에셋의 경우 바이너리가 적용된다.

Force Binary

에셋을 바이너리로 저장한다. 

임의의 프리팹을 생성하고 파일을 열어보면 바이너리로 저장된걸 확인할 수 있다.

비주얼 스튜디오에서 파일이 열리지 않는 경우 Extensions > Manage Extensions 에서 HexVisualizer 를 설치하면 된다. 이때 실행중인 비주얼 스튜디오는 모두 종료해야 설치가 진행된다.

Force Text

에셋을 문자열로 저장한다.

저장된 정보는 텍스트 기반으로 데이터 직렬화 언어로 많이 사용되는 YAML 형식이다.

프리팹의 정보가 키&밸류 형태로 정리되어있어  바이너리와 달리 사람이 쉽게 읽을 수 있도록 표현되었다.

Force Text 모드에서 프리팹을 생성하고 Mixed 모드로 변경시 기존 프리팹은 텍스트, 새로 생성된 프리팹은 바이너리로 저장된다.

Mixed 또는 Force Text 를 선택한 경우 Serialize Inline Mappings On One Line 토글이 활성화된다.

이 옵션은 참조 및 인라인 맵핑을 한 줄에 쓸것인지 여부를 정한다. 비활성화시 한 줄의 총 문자가 80자 이상이 되면 텍스트가 분할된다.

Default Behaviour Mode

프로젝트를 처음 생성시 2D 또는 3D를 선택하는데 프로젝트 생성 이후에도 해당 설정에서 변경이 가능하다.

유니티에서는 프로젝트가 Full 2D 인 경우 이외에는 모두 3D 로 작업환경을 정할 것을 추천한다.

2D와 3D 설정에는 프로젝트의 몇가지 기본세팅에서 차이가 있다.

2D

- Import 하는 모든 영상은 2D 이미지로 간주되며 Sprtie로 설정된다.

- Scene View 가 2D로 세팅된다.

- 게임 오브젝트가 기본적으로 실시간 Directional light 의 광원을 받지 않는다.

- 카메라의 기본 위치가 0, 0, -10 으로 설정된다.

- 카메라가 Orthographic 으로 설정된다.

- Lighting 창의 옵션의 경우

   * 새로운 씬에 대해서 Skybox가 비활성화

   * Ambient Source 는 Color(54, 58, 66) 로 설정

   * Realtime Global Illumination(Enlighten) 꺼짐 상태

   * Baked Global Illumination 꺼짐 상태

   * Auto-Building 꺼짐 상태

3D

- Import 한 모든 이미지가 2D 이미지로 간주되지 않는다.

- Sprite Packer 가 비활성화된다.

- Scene View 는 3D로 설정된다.

- 기본 게임 오브젝트가 리얼 타임 Directional Light 광원을 받는다.

- 카메라의 기본 포지션은 0, 1, -10 으로 설정된다.

- 카메라가 Perspective 로 설정된다.

- Lighting 창의 경우

  * Skybox 는 built-in Default Skybox 로 설정

  * Ambient Source 는 Skybox 로 설정

  * Realtime Global Illumination (Enlighten) 켜짐 상태

  * Baked Global Illumination 켜짐 상태

  * Auto-Building 켜짐 상태

차이점을 보면 2D에서 3D 작업을 한다고 해서 치명적인 문제가 발생하지는 않는다.

하지만 몇가지 기본 설정들은 각 상황에서만 사용하는 경우가 많기 때문에 맞춰서 작업하는것이 권장된다.

에디터 버전 : 2021.3.28f1 (LTS)

Audio

오디오 시스템을 구성하는 데 사용되는 설정으로 모든 Audio 컴포넌트에 영향을 미치는 전역적인 설정을 제공한다.

Global Volume

오디오 시스템의 볼륨을 전역으로 적용한다.

볼륨의 초기값에 곱해주는 수로 AudioListner.volume과 동일하다.

Volume Rolloff Scale

볼륨이 감쇠되는 정도를 전역으로 조절한다. 

단 Logarithmic Volume Curves 인 경우에만 적용된다.

Logarithmic Volume Curves는 로그 함수 곡선형태로 사운드가 감쇠되는 경우에만 적용되는데 이 사운드는 Audio Source 컴포넌트의 속성값 중에 3D Sound Settings의 Volume Rolloff에서 선택할 수 있는 옵션이다.

( 기본으로 Logarithmic Rolloff 설정 )

값은 기본적으로 1로 되어있는데 이 값이 현실에 가장 가까운 수치이다.

Doppler Factor

소리에 도플러 효과(Doppler Effect)를 적용시키기 위한 수치이다. 

원하는 도플러 효과를 얻기 위해서 해당 수치를 조절할 수 있다.

Doppler Effect

도플러 효과란 파동의 진동수가 왜곡되는 현상이다. 음원(소리의 근원지)가 움직이면서 파원이 다가오고 있을 때 정지한 관찰자에게는 파동의 파장이 실제보다 짧게 느껴지고 다시 멀어지게 되면 파장이 실제보다 길게 느껴지는 것이다.

예를 들어 멀리서부터 소방차가 사이렌을 켜고 달려오고 있다. 이때 멀리서부터 나에게 가까워지는 동안에는 사이렌의 소리가 점점 높아지는 것처럼 들리다가 내 옆을 지나쳐 멀어질 때는 낮아지는 것처럼 느껴진다. 하지만  이는 상대적인 효과로 관찰자만 느끼는 현상이고 소방차에 탑승한 사람에게는 일정한 소리로 들린다.

유니티의 프로젝트 세팅에서 Doppler Factor 수치는 기본적으로 1이다. 이 수치는 소리의 움직임이 실제 도플러 효과와 거의 동일하게 시뮬레이션되며 값이 0에 가까워질수록 도플러 효과가 감소하고 값이 높아질수록 강조된다.

Default Speaker Mode

프로젝트의 오디오 출력을 설정할 수 있는 옵션이다. 유니티 엔진에서 오디오가 재생될 때 사용되는 스피커의 타입을 지정할 수 있다.

옵션의 종류는 다음과 같다.

Mono

채널 개수가 1개이다.

오디오를 단일 스피커에서 재생한다. 오디오 소스는 좌우 채널이 결합된 단일 스피커로 재생된다. 

주로 모노 오디오 효과나 음성 등 단일 채널 오디오를 재생하는 데 사용된다.

Stereo

채널 개수가 2개이다.

좌우 스피커에서 각각의 채널이 재생된다. 대부분의 오디오에서 사용되는 일반적인 스테레오 효과를 재생할 때 사용되며 기본으로 선택된 설정이다.

Quad

채널 개수가 4개이다.

전후좌우  4개의 스피커에 각각의 채널이 재생되며 3D 오디오 효과를 표현할 수 있다.

Surround

채널 개수는 5개이다.

전면 좌우, 중앙, 후면 좌우 5개의 스피커를 사용한다. 더 입체적인 공간 음향 효과를 재생할 수 있다.

Surround 5.1/7.1

채널 개수는 5개 이상이다.

전면 좌우, 중앙, 후면 좌우 + 서브 우퍼 채널을 통해 사운드가 재생된다.

Prologic DTS(Digital Theater System)

채널 개수는 2개이다.

스피커는 스테레오로 출력되지만 데이터는 Prologic/Prologic2 디코더에서 인식하고 5.1 채널 스피커로 분리되도록 인코딩 된다.

System Sample Rate

출력되는 샘플 레이트를 설정한다. 해당 수치를 조절하면 오디오 주파수의 표현 범위를 조정할 수 있다. 0으로 설정하면 시스템의 샘플 레이트를 사용하고 0 이외의 값을 설정하면 입력한 값을 샘플 레이트로 사용하게 된다. iOS나 Android와 같은 특정 플랫폼에서 샘플 레이트를 변경할 수 있는 경우에만 해당한다.

Sample Rate

샘플의 빈도수 즉, 1초당 추출되는 샘플의 개수를 뜻한다. 샘플 레이트의 수치가 높을수록 정확한 음원을 저장할 수 있지만 그만큼 용량이 기하급수적으로 증가한다. 이에 따라 적당한 타협선인 44.1kHz의 샘플 레이트가 일반적으로 사용된다. 

DSP Buffer Size

Digital Signal Processing 버퍼 크기

실시간으로 들어오는 오디오 데이터를 처리하고 재생하기 위해서 일시적으로 저장하는 공간의 크기를 설정한다.

해당 저장공간이 작으면 오디오 데이터가 빠르게 처리되지만 CPU 부하가 증가하고 지연 시간이 감소한다. 반면에 공간이 큰 경우에는 한 번에 더 많은 오디오 데이터가 처리되므로 CPU부하가 감소하고 지연 시간이 증가한다.

Default

유니티의 기본 DSP 버퍼 크기를 사용한다. 대부분의 경우 적절한 응답성과 지연 시간을 제공하는 안정적인 설정이다.

Best latency

지연 시간을 고려하여 성능을 절충한다. 더 낮은 지연 시간이 요구되는 실시간 애플리케이션에 적합하다. CPU 부하가 증가할 수 있고 낮은 CPU 성능에서는 문제가 발생할 수 있다.

Good latency

지연 시간과 CPU 성능의 균형을 유지한다. 일반적인 오디오 처리 요구 사항을 충족하는데 적합하다.

Best performance

CPU 성능을 유리하도록 지연시간을 맞춘다. 높은 오디오 처리 요구 사항이 있거나 더 많은 CPU 성능을 활용해야 하는 경우에 적합하며 지연 시간이 증가할 수 있다.

Max Virtual Voices

오디오 시스템이 관리할 수 있는 최대 사운드의 개수를 설정한다. Real Voices의 수보다 크게 설정되어야 하며 그렇지 않은 경우 콘솔에서 경고 메시지가 표시된다. 가장 큰 소리들 중에서 Max Real Voices 수만큼만 실제로 재생되고 나머지 소리들은 재생 위치만 업데이트된다.

Max Real Voices

게임에서 동시에 재생 가능한 실제 음성의 수를 설정한다. 매 프레임마다 가장 큰 음성이 선택된다.

Spatializer Plugin

공간화된 오디오 처리를 수행하기 위한 플러그인이다. 오디오를 공간적으로 위치시키고 음향 효과를 적용하여 3D 소리의 현실감을 높이는 데 사용된다.

일반적으로 게임 엔진이나 오디오 미들웨어에서 제공되며 다양한 기능과 설정을 제공한다. 오디오 원본의 위치, 방향, 거리 등을 고려하여 소리를 공간 내에서 정확하게 재생할 수 있으며 일반 스피커 시스템이나 헤드폰을 사용하는 경우, 소리가 사용자 주변에서 움직이거나 공간의 특정 위치에서 들리는 것처럼 느껴지게 된다.

해당 기능을 사용하기 위해서는 해당 플러그인의 최신 SDK 설치가 필요하다.

현재 버전을 기준으로 공식문서에서 안내되는 플러그인 다운링크

Ambisonic Decoder Plugin

Ambisonic을 Binaural 필터링하기 위한 플러그인을 설정할 수 있다.

유니티에서 제공되는 빌트인 디코더는 없으며 일부 VR 하드웨어 제조사의 경우 오디오 SDK에 유니티용 빌트인 디코더가 있다. 타깃 플랫폼 제조사의 문서를 통해 프로젝트에 적합한지 확인할 수 있다.

Ambisonic 오디오 클립을 임포트 하려면 임포트 한 파일의 Ambisonic 옵션을 체크해야 한다.

Ambisonic 클립을 사용하기 위해서는 Audio Source 컴포넌트의 Spatialize 옵션을 비활성화해야 하고 해당 클립이 재생될 때 자동으로 프로젝트에서 선택된 플러그인을 통해서 디코딩된다.

Ambisonic

다중 마이크로폰 배열을 사용하여 소리의 공간 정보를 캡처하는 방법이다. 소리의 방향, 거리, 공간 위치 등을 캡처하여 공간적으로 정확한 사운드 재생을 가능하게 한다. 일반적으로 360도 환경 음향을 재현하거나 VR 및 3D 오디오 환경에서 사용된다. 다중 채널 포맷으로 저장되고 Ambisonic을 사용하면 각 채널을 특정 스피커에 매핑하지 않고 사운드필드가 더 전체적인 방법으로 표현된다. 

Binaural

인간의 이중귀를 모방하여 소리를 전달하는 기술이다. 두 개의 이어폰 또는 헤드폰을 사용해서 소리를 개별적으로 각 귀에 전달함으로 공간적인 사운드 경험을 제공한다. 3D 오디오를 더욱 현실적이고 공간적으로 인지할 수 있도록 한다.

Disable Unity Audio

런타임에 출력 장치를 할당하지 않도록 설정한다. 내장된 오디오 시스템 이외의 다른 사운드 시스템을 사용하는 경우에 활성화하는 옵션이다. 

Enable Output Suspension (editor only)

출력이 오랜 시간 동안 정지된 것이 감지되면 자동으로 오디오 출력을 일시 중단시킨다. 오디오 시스템을 중단하면 컴퓨터가 절전 모드로 전환되는 것을 방지하는 운영 체제의 기능이 비활성화되고 이를 통해 오랜 시간 동안 정지된 오디오 출력으로 인해 컴퓨터가 절전 모드로 전환되는 것을 방지할 수 있다. 주로 배터리 수명을 연장하거나 오디오가 정지된 상태에서 시스템의 에너지 소비를 최소화하기 위해 사용된다.

해당 설정은 기본적으로 활성화되어 있다.

Visualize Effects

컬링 되는 오브젝트의 Audio Source에서 Spatializer를 동적으로 비활성화하여 CPU를 절약한다. 

즉 카메라에 의해 렌더링 되지 않는 오브젝트에 대한 오디오 처리를 제한시킨다.

에디터 버전 : 2021.3.28f1 (LTS)

Adaptive Performance

모바일 장치와 같은 저사양의 플랫폼에서 자동으로 프레임률을 관리하고 최적화할 수 있도록 기능을 제공한다.

기능이 활성화되면 하드웨어 자원을 최대한 활용하여 최적의 성능을 얻을 수 있다. 

기능을 사용하기 위해서는 Adaptive Performance 패키지부터 설치해야 한다. 아래의 인스톨 버튼을 클릭하면 해당 패키지의 최신 버전의 설치가 진행된다.

패키지 설치가 끝나면 다음과 같이 화면이 변경된다.

Adaptive Performance Docs

공식 문서부터 살펴본다.

view documentation

해당 패키지의 설명은 이렇다.

Adaptive Performance allows you to get feedback about the thermal and power state of your mobile device and react appropriately.
(Adaptive Performance를 사용하면 모바일 장치의 발열과 전원 상태에 대한 피드백을 가지고 적절하게 대응할 수 있다.)

여기서 전원 상태란 모바일 장치의 전력 상태를 의미한다.

(전력이 낮은지, 충분한지 또는 충전 중인지 등의 상태)

For example, you can create applications that react to temperature trends and events on the device, to ensure constant frame rates over a longer period of time and prevent thermal throttling.
(장치의 온도 추세나 이벤트에 반응해서 일관된 프레임률을 장기간 유지하고 열 제한을 방지하는 애플리케이션을 만들 수 있다.)

온도 추세는 모바일 장치의 온도 변화를 뜻한다. 모바일 장치는 사용자가 앱을 실행하거나 다양한 작업을 수행할 때 온도가 상승할 수 있다. 이벤트는 앱의 실행과 종료, 배터리 잔량 변화, 충전 상태 변화, 네트워크 상태, 알림, 회전 등과 같이 여러 상태 변화를 뜻한다. 

열 제한은 모바일 장치가 과열될 때 발생하는 현상으로 온도가 높아짐에 따라 장치의 성능이 저하되거나 충전이 중단되는 등의 문제가 발생한다. 따라서 열 제한을 방지한다는 것은 장치의 온도가 올라가서 열 제한을 발생시켜 성능이 저하되지 않도록 온도추세와 이벤트에 반응하여 프레임률 관리를 통해서 모바일 장치의 과열을 방지하는 것을 의미한다.

Thermal Throttling 

Provider

Adaptive Performance를 활용하기 위해서는 정보를 제공할 장치가 필요하다. 이 장치를 Provider라고 하며 빌드 대상에 맞는 Provider가 제공된다. PC 플랫폼인 경우 별도의 Provider는 제공되지 않으며 Simulator라는 가상 장치를 사용할 수 있다. Simulator는 Adaptive Performance 패키지가 설치될 때 함께 다운로드되며 Provider의 경우 선택될 때 패키지 설치가 진행된다. 하지만 선택을 해제해도 해당 패키지가 삭제되진 않으며 삭제하고 싶은 경우 패키지 매니저를 사용해야 한다.

Simulator = PC, Provider = Mobile (android, ios)