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

 

2D Sprite

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

Sprite Renderer Animation

 

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

 

UI Animation

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

UI Animation

 

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를 베이스로 해서 게임 로직들을 만들었고 그렇게 진행하다 보니 효과를 추가하는 과정에서 물리적인 부분을 사용할 수 없어 직접 위치를 이동시켜서 유사하게 재현할 수밖에 없었다.

 

UI Animation

 

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

 

GitHub - Unity-UI-Extensions/com.unity.uiextensions

Contribute to Unity-UI-Extensions/com.unity.uiextensions development by creating an account on GitHub.

github.com

 

 

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

 

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

 

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

 

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

 

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

 

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

 

 

Performance

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

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

 

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

 

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

 

728x90
반응형

Player 세팅에서 Input System Package만 사용하는 상태

 

게임 뷰 창에서 버튼이 클릭되지 않는 문제가 발생했다.

 

하지만 시뮬레이터 창, 빌드 후에는 정상적으로 동작이 되는 문제가 있었다.

 

이런저런 방법을 시도해 보다가 혹시나 해서 시뮬레이터 창을 닫고 다시 플레이해 보니

 

정상적으로 동작이 되었다.

 

두 창이 모두 활성화된 상태에서 플레이될 때 에디터루프에서 인풋시스템이 초기화하면서 문제가 생긴 건지 별거 아닌 문제 때문에 꽤 시간을 빼앗긴 일이 생겨서 메모해 둔다.

728x90
반응형

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

 

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

 

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

 

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

 

Unity - Project Window

 

 

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

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

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

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

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

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

- 모델 검색 : 't:Model'

 

Unity - Project Window / Sreaching

 

 

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

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

 

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

 

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

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

 

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

Assets Labels

 

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

 

Unity - Search by Type / Search by Label

 

728x90
반응형

에디터 버전 : 2021.3.28f1 (LTS)

Asset Pipeline

예전 에디터 버전에서는 Asset Pipeline 은 version 1, 2를 구분하여 선택하여 사용할 수 있었지만 최근 버전에서부터는 Asset Pipeline 2로 자동설정되며 선택할 수 없다.

 

Asset Pipeline

 

에셋을 처리하는 과정에 대한 설정을 관리하는 항목들이다.

 

Remove unused Artifacts on Restart

재실행시 사용하지 않는 아티팩트들을 삭제할지 여부에 대한 토글로 기본으로 활성화된 상태이다.

Remove unused Artifacts on Restart

 

유니티는 에디터가 실행될 때 라이브러리 폴더의 artifact 파일과 에셋 데이터베이스 엔트리에서 제거한다.

가비지 콜렉션의 형태로 이 설정을 비활성화하면 에셋 데이터베이스의 가비지 컬렉션이 비활성화된다.

즉 더 이상 사용하지 않는 수정된 아티팩트가 에디터가 재실행될 때에도 계속 보존되기 때문에 예상하지 못한 임포트 결과를 디버그 할 때 유용하다.

 

하지만 계속해서 사용하지 않는 데이터들이 쌓여갈 수 있기 때문에 일반적인 상황에서는 활성화해두는게 나을 것 같다.


라이브러리 폴더

유니티에 임포트 된 에셋은 두 가지 버전으로 구분된다. 하나는 사용자가 사용하기 위한 것이고 다른 하나는 유니티가 사용하기 위한 것이다. 이 유니티가 사용하기 위한 에셋은 프로젝트의 라이브러리 폴더에 캐시로 생성된다. 즉 라이브러리 폴더 내의 캐시들은 로컬에서 에디터가 빠르게 작업을 처리하기 위해 사용하는 정보들로 많은 정보들을 계속해서 저장하기 때문에 용량이 큰 편이다.

 

로컬에서만 필요한 이 정보들은 프로젝트가 켜질 때마다 확인하는 과정을 거치며 폴더가 없으면 다시 생성하기 때문에 프로젝트를 공유하는 경우에는 제외시켜도 되는 파일들이다.


 

Parallel Import

Parallel Import

 

에셋을 임포트 할 때 동시에 진행하도록 하는 설정이다.

 

Parallel Import tip

 

해당옵션은 기본으로 비활성화되어있고 이 경우 에셋을 순차적으로 임포트 하게 된다.

 

이 기능은 특정 유형의 에셋에서만 지원되며  에디터가 프로젝트 폴더에서 에셋이 새로 임포트 되거나 수정된 에셋을 감지하고 자동으로 임포트 할 때 발생하는 에셋 데이터베이스가 새로고침을 수행할 때만 실행된다. 이때 에셋은 하위 프로세스에서 임포트가 실행된다.

 

특정유형

- Texture Importer로 가져온 이미지 파일

- Model Importer 로 가져온 모델 파일

 

특정 유형은 임포트 시간이 오래 걸리는 두 가지로만 구성되며 현재 버전까지는 별도의 스크립터블이 가능한 API는 마련된

지 않은 상태이다.

 

Parallel Import

 

이외의 유형은 해당 설정이 활성화되어 있어도 순차적으로 임포트 된다.

 

Desired Import Worker Count

병렬 임포트에서 사용할 작업 프로세스의 최적의 수

 

Standby Import Worker Count

쉬고 있는 상태에서도 유지시킬 최소의 작업 프로세스의 수

에디터에서 작업에 필요한 프로세스의 수가 최소보다 큰 경우 쉬고있는 프로세스를 중지시키고 시스템 리소스를 확보하도록 한다. 

 

Idle Import Worker Shutdown Delay

쉬는 상태의 작업 프로세스를 종료할 때 대기하는 시간

 

또한 Edit > Preferences > Asset Pipeline에서 새 프로젝트에서 필요한 작업 프로세스의 기본 값을 제어할 수 있다.

Preferences > Asset Pipeline

 

Import Worker Count % 의 값을 사용하여 Desired Import Worker Count 값을 할당할 수 있다.

이때 할당되는 값은 시스템에서 사용할 수 있는 논리 코어 수의 비율에 해당한다.

(16개의 논리 코어가 있다면 이중 25%를 할당하여  Desired Import Worker Count 값은 4가 할당된다.)

 

Cache Server (project specific)

Cache Server

Asset Pipeline 1 일 때 사용한 기능으로 버전 2에서는 기본으로 비활성화되어 있고 활성화할 수 없고 Unity Accelerator로 대체되었다.

 

Accelerator

팀 작업 속도를 높이기 위한 기능이다.

임포트 한 에셋의 사본을 유지하는 캐싱 프락시 에이전트이다. 팀이 동일한 네트워크에서 작업할 때 프로젝트 일부를 다시 임포트 할 필요가 없도록 하여 반복 시간을 줄일 수 있도록 돕는다.

 

Unity Accelerator

 

Prefab Mode

프리팹 관련 설정

Prefab Mode

 

Allow Auto Save

프리팹 설정 시 자동으로 저장되는 기능을 활성화할지 여부를 정할 수 있다.

활성화된 경우 프리팹 수정 씬에서 자동 저장 기능을 사용할 수 있는 상태가 된다.

 

Prefab Scene Auto Save - Enable

 

Prefab Scene Auto Save - Disable

 

Editing Environments

프리팹을 수정하는 환경을 편집하는 기능을 제공한다.

 

Regular Environment

일반 프리팹을 편집하는 환경에서 사용하고자 하는 신을 할당하면 배경으로 사용할 수 있다.

Regular Environment

 

UI Envrionment

UI 프리팹의 편집하는 환경에서 사용할 수 있다.

UI Environment

 

Graphics

Graphics

 

Show Lightmap Resolution Overlay

씬의 드로우 모드 중에서 Baked Lightmap 모드에 체커보드 오버레이를 그린다. 

여기서 타일 하나는 텍셀에 해당하며 라이트매핑 작업 시 씬의 텍셀 밀도를 확인할 수 있다.

Draw Mode - Baked Lightmap / left enable

 

Use legacy Light Probe sample counts

활성화 시 Progressive Lightmapper를 사용하여 베이크 할 때 고정된 라이트 프로브 샘플 수를 사용한다. 

Direct Sample 64, Indirect Sample 2048, Environment Sample 2048

Lighjtmapping - right enable

 

Enable baked cookies support

2020.1 이상의 프로젝트는 기본적으로 베이크 된 쿠키가 Progressive Lightmapper의 베이크된 광원과 혼합 광원에 대해 활성화된다. 이전의 경우 해당 부분이 비활성화되는데 이 옵션은 이전 버전과의 호환성을 위해서 제공되는 기능이다.

 

Cookie

특정 모양이나 색상의 그림자를 만들기 위해 광원에 배치하는 마스크로 광원의 모양과 강도를 변경한다.

쿠키를 통해 런타임 성능에 최소한 또는 전혀 영향을 미치지 않는 선에서 복잡한 조명 효과를 효율적으로 사용할 수 있다.

Light cookie

 

728x90
반응형

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

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

 

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

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

 

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

.prefab Text

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

길이는 100줄 정도 된다.

.prefab Text view

 

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

 

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

 

.prefab Binary

 

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

 

.prefab Binary view

 

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

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

Binary

 

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

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

ASCII

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

 

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

 

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

.prefab size

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

 

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

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

 

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

 

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

 

+1 cube biary

 

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

 

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

 

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

큐브 개수 / 파일 사이즈(kb)  Binary Text
1 9 3
2 9 6
3 10 9
4 11 12
20 23 56
100 82 276

 

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

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

 

비교

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

 

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

 

Github unity Asset Serialization

 

Github - Git and Unity

 

Git and Unity

Git and Unity. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 

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

 

 

 

728x90
반응형

에디터 버전 : 2021.3.28f1 (LTS)

 

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

Unity Remote [Depricated]

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

 

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

 

Device Simulator Package

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

Device Simulator

 

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

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

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

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

Advanced Project Settings

 

Enable Pre-release Package

 

Asset Serialization

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

Asset Serialization

 

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

 

Mixed

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

 

Force Binary

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

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

Unity .prefab binary view

 

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

VS Manage Extensions-HexVisualizer

 

Force Text

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

Unity .prefab Text

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

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

 

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

 

Left Text, Right Binary

 

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

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

 

Default Behaviour Mode

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

Unity Default Behaviour Mode

 

유니티에서는 프로젝트가 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 작업을 한다고 해서 치명적인 문제가 발생하지는 않는다.

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

 

728x90
반응형

에디터 버전 : 2021.3.28f1 (LTS)

 

Audio

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

 

Unity Project Settings - Audio

 

Global Volume

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

Audio - Global Volume

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

 

Volume Rolloff Scale

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

Audio Volume Rolloff Scale

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

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

( 기본으로 Logarithmic Rolloff 설정 )

 

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

 

Doppler Factor

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

Audio Doppler Factor

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

 

Doppler Effect

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

 

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

 

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

 

Default Speaker Mode

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

Audio - Default Speaker Mode

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

Default Speaker Mode - Option

 

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 버퍼 크기

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

Audio - DSP Buffer Size

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

 

DSP Buffer Size

Default

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

 

Best latency

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

 

Good latency

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

 

Best performance

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

 

Max Virtual Voices

Audio - Max Virtual Voices

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

 

Max Real Voices

Audio - Max Real Voices

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

 

Spatializer Plugin

Audio - Spactializer Plugin

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

 

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

 

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

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

 

Ambisonic Decoder Plugin

Audio - Ambisonic Decoder Plugin

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

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

 

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

Import Ambisonic Audio Clip

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

 

Ambisonic

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

Binaural

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

 

Disable Unity Audio

Disable Unity Audio

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

 

Enable Output Suspension (editor only)

Enable Output Suspension

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

 

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

 

Visualize Effects

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

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

728x90
반응형

에디터 버전 : 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) 

 

 

728x90
반응형

+ Recent posts