라이트매핑

라이트매핑은 씬의 표면 밝기를 미리 계산하고 계산 결과를 나중에 사용하기 위해 라이트맵이라고 불리는 텍스처에 저장하는 프로세스입니다.

왼쪽: 라이트맵이 적용된 간단한 씬. 오른쪽: Unity가 생성한 라이트맵 텍스처. 그림자 및 광원 정보가 모두 캡처됩니다.

라이트맵에는 직접광과 간접광이 모두 포함될 수 있습니다. 이 조명 텍스처는 오브젝트의 머티리얼과 연결된 셰이더에서 컬러(알베도) 및 릴리프(노멀) 같은 표면 정보와 함께 사용될 수 있습니다.

라이트맵에 베이크된 데이터는 런타임 시 변경할 수 없습니다. 실시간 광원은 라이트맵이 적용된 씬 위에 오버레이시켜 추가적으로 사용할 수 있지만, 라이트맵 자체를 대화식으로 변경할 수 없습니다.

이 방식을 사용할 경우 게임플레이 시에 광원을 실시간으로 움직일 수 있는 유용성을 잠재적인 성능 향상과 맞바꾸는 것이므로, 모바일 플랫폼처럼 성능이 낮은 하드웨어에 적합합니다.

Unity는 라이트맵 생성을 위해 다음의 라이트매퍼를 제공합니다.

• 프로그레시브 라이트매퍼
• 인라이튼 베이크된 전역 조명

인라이튼 베이크된 전역 조명을 사용한 라이트매핑

인라이튼 베이크된 전역 조명은 사전 계산된 실시간 전역 조명 데이터에 기반하여 간접 조명을 생성합니다. 이렇게 하면 씬의 조명을 변경한 후 새로운 라이트맵을 매우 빠르게 생성하는 장점이 있습니다. 그러나 인라이튼 베이크된 전역 조명은 프로그레시브 라이트매퍼보다 UV 레이아웃 제한이 더 많습니다.

인라이튼 베이크된 전역 조명은 지원 중단 예정입니다.(인라이튼 실시간 전역 조명은 계속 지원합니다.)

렌더 파이프라인 지원

렌더 파이프라인의 인라이튼 베이크된 전역 조명 지원에 대한 자세한 내용은 렌더 파이프라인 기능 비교를 참조하십시오.

인라이튼 라이트매퍼 사용

인라이튼 베이크된 전역 조명을 사용하려면 Window > Rendering > Lighting에서 Lightmapping Settings로 이동한 후 Lightmapper를 Enlighten으로 설정합니다.

LightingSettings API를 사용하여 스크립트를 통해 이 창에서 사용할 수 있는 많은 기능을 수행할 수 있습니다.

다음 프로퍼티는 인라이튼에만 해당됩니다. 이것을 노출시키려면 Lightmapper control에서 Enlighten을 선택합니다.

프로퍼티:기능:

기본 환경 기여 비활성화

Unity는 자동으로 앰비언트 프로브와 기본 반사 프로브를 생성하여 환경 조명이 기본적으로 씬과 씬의 게임 오브젝트에 영향을 주도록 합니다.

라이트맵과 라이트 프로브를 수동으로 생성하지 않은 게임 오브젝트 또는 씬의 조명 결과에서 환경 기여를 비활성화하려면 기본 반사 프로브와 앰비언트 프로브를 비활성화합니다. 자세한 내용은 [SkyManager 비활성화]를 참조하십시오.

라이트매핑: 시작하기

씬 준비 및 라이트맵 베이킹

Unity 에디터 메뉴에서 Window > Rendering > Lighting 을 선택하여 Lighting 창을 엽니다. 라이트맵을 적용할 메시를 검토하여 라이트맵에 적합한 UV가 있는지 확인합니다. 메시 임포트 설정을 열고 Generate Lightmap UVs 설정을 활성화하면 가장 쉽게 확인할 수 있습니다.

다음, 라이트맵 해상도를 설정하기 위해 라이트맵 설정(Lightmapping Settings) 섹션으로 이동하여 라이트맵 해상도(Lightmap Resolution) 값을 조정합니다.

라이트맵에 포함되려면 렌더러가 다음 조건을 충족해야 합니다.

• Mesh Renderer 또는 Terrain 컴포넌트가 있습니다.
• Contribute GI로 표시되어 있습니다.
• 빌트인 Unity 머티리얼, 스탠다드 셰이더 또는 메타 패스가 포함된 셰이더를 사용합니다.

광원 탐색기에서 광원에 대한 설정을 조정할 수 있습니다. 광원 탐색기를 열려면 Window > Rendering > Light Explorer로 이동합니다.

씬의 라이트맵을 생성하는 방법:

1. Lighting 창(메뉴: Window > Rendering > Lighting)을 엽니다.
2. Lighting 창의 Scene 탭 하단에서 Generate Lighting 을 선택합니다(또는 Auto Generate 가 활성화되어 있는지 확인합니다).
3. Unity 에디터 상태 표시줄의 오른쪽 하단에 진행 표시줄이 나타납니다.

라이트매핑이 완료되면 Unity의 씬 뷰와 게임 뷰가 자동으로 업데이트되며 Lighting 창의 Baked Lightmaps 탭으로 이동하여 결과가 적용된 라이트맵을 볼 수 있습니다.

조명을 수동으로 생성하면 조명 데이터 에셋, 베이크된 라이트맵, 반사 프로브가 Assets 폴더에 추가됩니다.

라이트맵 파라미터 에셋

라이트맵 파라미터 에셋에는 Unity의 조명 기능을 제어하는 파라미터 값 세트가 들어 있습니다. 이러한 에셋을 사용하면 다양한 조명 값 세트를 정의하고 저장하여 다양한 상황에서 사용할 수 있습니다.

라이트맵 파라미터 에셋을 사용하면 다양한 게임 오브젝트 타입이나 여러 플랫폼과 여러 씬 타입(예: 실내 또는 야외 씬)에 최적화된 프리셋을 빨리 만들 수 있습니다.

라이트맵 파라미터 에셋 생성

새 라이트맵 파라미터 에셋을 생성하려면 프로젝트 창에서 마우스 오른쪽 버튼을 클릭하고 생성(Create) > 새 파라미터 에셋(New Parameters Asset) 으로 이동합니다. Unity는 프로젝트 폴더에 생성된 에셋을 저장합니다.

프로퍼티

프로젝트 창에서 라이트맵 파라미터 에셋을 클릭하면 해당 에셋에 정의된 값이 인스펙터 창에 표시됩니다. 아래 표에는 각 파라미터와 해당 설명이 나열되어 있습니다.

실시간 GI

이 파라미터는 인라이튼 실시간 전역 조명을 설정합니다.

렌더 파이프라인의 인라이튼 실시간 전역 조명 지원에 대한 자세한 내용은 렌더 파이프라인 기능 비교를 참조하십시오.

프로퍼티기능

베이크된 GI

이 파라미터는 라이트매핑을 설정합니다.

렌더 파이프라인의 라이트매핑 지원에 대한 자세한 내용은 렌더 파이프라인 기능 비교를 참조하십시오.

프로퍼티기능

베이크된 태그: 세부 정보

위 두 이미지에는 동일한 씬에 대한 두 가지 뷰가 나와 있습니다.

1. 위: 모든 게임 오브젝트의 Baked Tag 가 같으므로 모두 하나의 아틀라스에 있습니다.
2. 아래: 한 게임 오브젝트에 다른 Baked Tag 가 할당되어 있어 두 번째 라이트맵으로 들어갑니다.

베이크된 AO

이 파라미터는 베이크된 앰비언트 오클루전을 설정합니다.

프로퍼티기능

일반 GI

프로퍼티기능

라이트맵 파라미터 에셋 할당(Assigning Lightmap Parameters Assets)

씬(Scenes)

전체 씬에 라이트맵 파라미터 에셋을 할당하려면 다음 단계를 따르십시오.

1. 조명 창(Window > Rendering > Lighting)을 엽니다.
2. Scene 탭을 클릭합니다.
3. Lightingmapping Settings 로 이동합니다.
4. Lightmap Parameters 드롭다운을 사용하여 디폴트 라이트맵 파라미터 에셋을 할당합니다. 드롭다운 리스트에는 사용 가능한 라이트맵 파라미터 에셋이 모두 나열됩니다.

게임 오브젝트(GameObject)

라이트맵 파라미터 에셋을 단일 게임 오브젝트에 할당하려면 게임 오브젝트에 Mesh Renderer 또는 Terrain 컴포넌트가 연결되어 있어야 합니다.

라이트맵 파라미터 에셋을 Mesh Renderer 컴포넌트에 할당하려면 다음 단계를 따르십시오.

1. 인스펙터에서 Mesh Renderer > Lighting으로 이동합니다.
2. Contribute Global Illumination 을 활성화합니다.
3. Mesh Renderer 컴포넌트에서 Lightmapping > Lightmap Parameters로 이동합니다.
4. 메뉴에서 옵션을 선택합니다. Scene Default Parameter 를 선택하여 전체 씬에 할당된 동일한 라이트맵 파라미터 에셋을 사용합니다.

라이트맵 파라미터 에셋을 Terrain 컴포넌트에 할당하려면 다음 단계를 따르십시오.

1. 인스펙터에서 Terrain > Terrain Settings > Lighting으로 이동합니다.
2. Contribute Global Illumination 을 활성화합니다.
3. Terrain Settings에서 Lightmapping > Lightmap Parameters로 이동합니다.
4. 메뉴에서 옵션을 선택합니다. Scene Default Parameter 를 선택하여 전체 씬에 할당된 동일한 라이트맵 파라미터 에셋을 사용합니다.

라이트맵 UV

일반적으로 UV라고 불리는 텍스처 좌표는 지오메트리 주위에 텍스처를 “래핑”하는 방법을 말합니다. 라이트맵은 텍스처이므로 Unity에서 씬을 올바르게 사용하려면 UV가 필요합니다.

이 섹션에서는 다음의 정보를 제공합니다.

페이지설명

https://docs.unity3d.com/kr/2021.3/Manual/LightingOverview.html

Unity의 내비게이션 시스템

내비게이션 시스템을 통해 게임 월드에서 이동할 수 있는 캐릭터를 생성할 수 있습니다. 2층으로 가기 위해 계단을 오르거나 배수로를 넘기 위해 점프해야 하는지를 이해할 수 있는 능력을 캐릭터에 부여합니다. Unity 내비메시 시스템은 다음으로 구성되어 있습니다.

• 내비메시(NavMesh)는 내비게이션 메시의 줄임말로, 게임 월드에서 걸을 수 있는 표면을 뜻하며, 내비메시를 사용하여 게임 월드 안에 있는 움직일 수 있는 한 위치에서 다른 위치로 이동할 수 있는 경로를 찾을 수 있습니다. 데이터 구조는 레벨 지오메트리에서 자동으로 빌드 또는 베이크됩니다.
• 내비메시 에이전트(NavMesh Agent) 컴포넌트를 사용하여 각자의 목적지로 이동하는 동안 서로를 피할 수 있는 캐릭터를 생성할 수 있습니다. 에이전트는 내비메시를 사용하여 게임 월드를 추론하며, 움직이는 장애물뿐만 아니라 서로를 피하는 방법을 알게 됩니다.
• 오프 메시 링크(Off-Mesh Link) 컴포넌트를 사용하여 걸을 수 있는 표면만으로는 정의할 수 없는 내비게이션 단축키를 통합할 수 있습니다. 예를 들어 배수로나 울타리를 뛰어넘거나 문을 지나가기 전에 여는 행동 등은 모두 오프 메시 링크로 정의할 수 있습니다.
• 내비메시 장애물(NavMesh Obstacle) 컴포넌트를 사용하여 에이전트가 월드를 탐색하는 동안 회피해야 하는 움직이는 장애물을 정의할 수 있습니다. 이에 대한 예로는 물리 시스템이 제어하는 통이나 상자를 들 수 있습니다. 움직이는 장애물이라면 에이전트가 이를 피하도록 하고, 장애물이 정지한 경우 내비메시에 구멍을 카빙하여 에이전트가 장애물을 돌아가도록 경로를 변경하거나, 정지한 장애물이 경로를 완전히 차단할 경우 에이전트가 다른 경로를 찾게 할 수 있습니다.

내비게이션 시스템의 내부 작업

게임에서 캐릭터(AI 써클에서는 에이전트라 함)를 지능적으로 움직이려면 목적지를 찾기 위해 필요한 레벨 추론과 목적지까지 이동하는 방법이라는 두 가지 문제를 해결해야 합니다. 이 두 문제는 밀접하게 연관되어 있지만 실제로는 아주 다릅니다. 레벨을 추론하는 문제는 씬 전체를 고려해야 한다는 점에서 훨씬 전역적이고 정적입니다. 목적지까지의 이동은 지역적이고 동적이며, 이동하는 방향과 이동 중인 다른 에이전트와의 충돌을 방지하는 방법에 대해서만 고려하면 됩니다.

걸을 수 있는 영역

게임 씬에서의 걸을 수 있는 영역을 나타내기 위해 내비게이션 시스템은 자체적인 데이터가 필요합니다. 걸을 수 있는 영역은 씬에서 에이전트가 서거나 움직일 수 있는 장소를 정의합니다. Unity에서 에이전트는 실린더로 정의됩니다. 걸을 수 있는 영역은 씬의 지오메트리에서 에이전트가 설 수 있는 위치를 테스트하여 자동으로 빌드됩니다. 그런 다음, 이러한 위치가 씬 지오메트리의 맨 위에 위치한 표면에 연결됩니다. 이 표면을 내비게이션 메시(줄여서 내비메시라고 함)라고 합니다.

내비메시는 이 표면을 Convex 폴리곤으로 저장합니다. Convex 폴리곤은 폴리곤 안의 두 지점 사이에 아무런 장애물이 없기 때문에 이런한 목적으로 유용하게 사용됩니다. 폴리곤의 경계를 비롯하여 서로 이웃한 폴리곤에 대한 정보도 저장합니다. 이렇게 하면 걸을 수 있는 모든 영역을 추론할 수 있습니다.

경로 찾기

씬에서 두 위치 사이의 경로를 찾기 위해서는 먼저 시작 위치와 목적지 위치를 가장 가까운 폴리곤에 매핑해야 합니다. 그런 다음, 시작 위치에서 탐색을 시작하여 모든 이웃 폴리곤을 거쳐 목적지 폴리곤에 도달합니다. 이동 중에 방문한 모든 폴리곤의 경로를 추적하여 시작에서 목적지까지 연결해주는 폴리곤의 시퀀스를 찾을 수 있습니다. 이렇게 경로를 찾는 일반적인 알고리즘을 A*(“에이스타”라고 발음)라고 하며, Unity도 바로 이 방법을 사용합니다.

경로 따라가기

시작 폴리곤에서 목적지 폴리곤까지의 경로를 정의하는 폴리곤의 시퀀스를 통로라고 합니다. 에이전트는 통로를 따라 보이는 가장 가까운 코너를 향해 움직이는 방법으로 목적지에 도달합니다. 씬에서 에이전트가 하나만 움직이는 간단한 게임이라면 한 번에 통로 선상의 모든 코너를 찾은 뒤 코너를 연결하는 라인 세그먼트를 따라 캐릭터가 움직이도록 애니메이션화할 수 있습니다.

여러 에이전트가 동시에 움직인다면 에이전트끼리의 충돌을 피하기 위해 원래 경로에서 벗어나야 할 필요가 있습니다. 라인 세그먼트로 이루어진 경로를 사용하여 이러한 경로 이탈을 수정하는 것은 매우 어렵고 오류가 쉽게 발생합니다.

각 프레임에서 에이전트의 움직임이 매우 적기 때문에 우회할 필요가 있을 경우 폴리곤의 연결을 사용하여 통로를 수정할 수 있습니다. 이후 에이전트가 향할 가장 가까운 보이는 코너를 검색하면 됩니다.

장애물 회피

스티어링 로직은 통로 선상에 있는 다음 코너의 포지션을 파악하고, 이에 기반하여 목적지에 도달하기 위한 원하는 방향과 속도를 계산합니다. 원하는 속도를 사용하여 에이전트를 움직일 때 다른 에이전트와의 충돌이 발생할 수 있습니다.

장애물 회피는 원하는 방향으로 나아가되 다른 에이전트 및 내비게이션 메시의 가장자리와 충돌하지 않게 적절한 균형점을 찾아 새로운 속도를 선택합니다. Unity는 상호간 속도 장애물(RVO)을 사용하여 충돌을 예견하고 방지합니다.

에이전트 이동

스티어링과 장애물 회피가 적용된 이후에 최종 속도가 계산됩니다. Unity에서 에이전트는 간단한 동적 모델을 사용하여 시뮬레이션되며, 자연적이고 부드러운 움직임을 위해 가속도까지 고려됩니다.

이 단계에서 시뮬레이션된 에이전트의 속도를 애니메이션 시스템에 제공하여 루트 모션을 사용해 캐릭터를 이동하거나 내비게이션 시스템이 이동을 처리하도록 할 수 있습니다.

두 메서드 중 하나를 사용하여 에이전트가 이동되면 시뮬레이션된 에이전트 위치가 이동되며 내비메시에 적용됩니다. 이 간단한 마지막 단계는 확실한 내비게이션 과정에서 중요한 역할을 합니다.

글로벌 및 로컬

내비게이션과 관련하여 이해해두어야 할 가장 중요한 사항 중의 하나는 글로벌 내비게이션과 로컬 내비게이션의 차이입니다.

글로벌 내비게이션은 월드에서 통로를 찾는 데 사용됩니다. 월드에서 경로를 탐색하려면 상당한 프로세싱 능력과 메모리가 필요합니다.

경로를 정의하는 폴리곤의 리니어 리스트는 스티어링을 위한 유연한 데이터 구조이며, 에이전트의 포지션이 움직임에 따라 로컬하게 조정될 수 있습니다. 로컬 내비게이션은 다른 에이전트나 움직이는 오브젝트와 충돌 없이 어떻게 효율적으로 다음 코너를 향해 나아갈 수 있는지를 결정합니다.

장애물의 두 가지 사례

내비게이션에는 다른 에이전트보다 다른 타입의 장애물이 많이 응용됩니다. 슈팅 게임에서 일반적으로 볼 수 있는 상자나 통을 예로 들 수 있고, 차량도 이에 해당합니다. 이러한 장애물은 로컬 장애물 회피 또는 글로벌 경로 탐색을 통해 처리할 수 있습니다.

움직이는 장애물이라면 로컬 장애물 회피를 사용하는 것이 좋습니다. 이 경우 에이전트가 장애물을 예측하여 회피합니다. 정지해 있을 수 있고 모든 에이전트의 경로를 차단하는 장애물이라면 글로벌 내비게이션인 내비게이션 메시에 영향을 주어야 합니다.

내비메시를 변경하는 것을 카빙이라고 합니다. 이 프로세스는 장애물의 어떤 부분이 내비메시에 닿는지를 감지한 다음, 내비메시에서 해당 부분을 깎아내어 구멍을 만듭니다. 이를 계산할 때 매우 많은 비용이 소모되기 때문에 움직이는 장애물은 충돌 회피를 통해 처리하는 이유이기도 합니다.

로컬 충돌 회피는 종종 흩어진 장애물을 피하는 데 사용되기도 합니다. 알고리즘이 로컬이므로 바로 직면한 충돌만 회피할 수 있으며, 함정을 피하거나 장애물이 경로를 차단하는 경우를 처리할 수 없습니다. 이러한 경우는 카빙을 통해 해결할 수 있습니다.

오프 메시 링크 정의

내비메시 폴리곤 사이의 연결은 경로 탐색 시스템 내부의 링크를 통해 정의됩니다. 가끔은 에이전트가 걸어 다닐 수 없는 장소(예: 펜스를 뛰어 넘거나 닫힌 문을 지나가는 경우)를 지날 수 있어야 합니다. 이러한 경우에는 액션이 일어나는 위치를 알아야 합니다.

오프 메시 링크 설정을 추가하여 이러한 액션을 정의하면, 특정한 링크를 통해 연결되는 경로가 있다는 것을 경로 탐색자가 알 수 있습니다. 해당 경로를 따라갈 때 이 링크가 사용되며, 링크 지점에서 특정한 액션이 이루어집니다.

내비메시 빌드

레벨 지오메트리에서 내비메시(NavMesh) 생성 과정을 내비메시 베이킹이라 부릅니다. 이 프로세스는 내비게이션 정적으로 마크된 메시 렌더와 모든 게임 오브젝트의 터레인을 수집한 후 처리하여 내비메시를 생성합니다. 메시는 레벨의 걸을 수 있는 표면과 비슷합니다.

Unity에서 내비메시 생성은 Navigation 창(메뉴: Window > AI > Navigation)에서 이루어집니다.

씬에서는 네 가지 단순한 단계를 거쳐 내비메시를 빌드합니다.

1. 내비게이션에 영향을 주는 씬 지오메트리를 Select합니다. - 걸을 수 있는 표면과 장애물입니다.
2. 내비게이션 스태틱을 Check하여 내비메시 베이킹 프로세스 안에 선택한 오브젝트를 포함시킵니다.
3. 베이크 설정을 Adjust하여 에이전트의 크기에 맞춥니다.

• 에이전트 반경 은 벽이나 낭떠러지 같은 지형에 에이전트 센터가 얼마나 가깝게 다가갈 수 있는지를 정의합니다.
• 에이전트 높이 는 에이전트가 다가갈 수 있는 공간의 높이를 정의합니다.
• 최대 슬로프 는 에이전트가 걸어 올라갈 수 있는 경사의 기울기가 어느 정도 되는지 정의합니다.
• 스텝 높이 는 에이전트를 멈춰 세우는 장애물의 높이가 어느 정도 되는지 정의합니다.

1. 베이크를 Click해서 내비메시를 빌드합니다.

빌드된 내비메시 결과는 내비게이션 창이 열리고 사용자의 눈에 씬이 들어올 때마다 기본 지오메트리 레벨 위에 파란 오버레이로 나타납니다.

위 그림에서 볼 수 있듯이, 생성된 내비메시에서 걸을 수 있는 영역이 더 작아 보입니다. 내비메시는 에이전트의 센터가 움직일 수 있는 영역을 나타냅니다. 개념적으로는 에이전트를 작아진 내비메시의 포인트로 여기든 풀 사이즈 내비메시의 원으로 여기든 둘은 같은 요소이므로 상관이 없습니다. 하지만 포인트로 해석하면 런타임 효율을 개선할 수 있고, 에이전트가 반지름에 상관없이 틈 사이로 지나갈 수 있는지 여부를 설계자가 즉시 확인할 수도 있습니다.

또 한 가지 유의해야 할 점은 내비메시는 걸을 수 있는 표면에 대한 근사치라는 점입니다. 예를 들어 계단의 경우 평면으로 표현되지만 소스 표면은 계단으로 되어 있을 수 있습니다. 이것은 내비메시 데이터 크기를 작게 유지하기 위해서입니다. 근사치의 부작용은 가끔씩 레벨 지오메트리에 추가 영역을 가져야 에이전트가 좁은 지점을 통과할 수 있습니다.

베이킹이 끝나면 내비메시 에셋 파일이 씬 이름과 같은 이름을 가지고 폴더 안에 생성됩니다. 예를 들어 씬을 Assets 폴더 안에

 첫 번째 레벨 로 만들었다면 내비메시는 Assets > First Level > NavMesh.asset 에 위치하게 됩니다.

베이킹을 위한 오브젝트 마킹 추가 워크플로

내비게이션 창에서 오브젝트를 내비게이션 스태틱 으로 마킹하기 외에도 위에서 설명한 대로 인스펙터 맨 위의 정적 메뉴를 이용할 수 있습니다. 내비게이션 창을 열어 두지 않았다면 편리한 기능입니다.

NavMesh 빌딩 컴포넌트

NavMesh 빌딩 컴포넌트는 런타임 시 Unity 에디터에서 NavMesh를 생성하고 사용하는 데 필요한 추가 컨트롤을 제공합니다.

NavMesh 빌딩 컴포넌트는 패키지 관리자로는 볼 수 없는 실험 패키지를 통해 사용할 수 있습니다. 이 실험 NavMesh 패키지를 설치하려면 이름별 레지스트리 패키지 추가의 지침을 따르고 com.unity.ai.navigation 패키지를 추가하십시오.

NavMesh 빌딩 컴포넌트에 관한 자세한 내용은 실험 패키지 문서를 참조하십시오.

고급 내비메시 베이크 설정

최소 영역(Min Region Area)

Min Region Area 고급 빌드 설정을 사용하여 연결되지 않은 작은 내비메시 영역을 제거할 수 있습니다. 표면 영역이 특정 값보다 작은 내비메시 영역은 제거됩니다.

일부 영역은 Min Region Area 설정에도 불구하고 제거되지 않을 수 있습니다. 내비메시는 타일 격자로 병렬로 구축됩니다. 영역이 타일 경계를 넘으면 그 영역은 제거되지 않습니다. 그 이유는 주변의 타일에 접근할 수 없는 빌드 프로세스의 단계에서 영역이 제거되기 때문입니다.

복셀 크기(Voxel Size)

수동 복셀 크기를 사용하면 베이크 프로세스가 작동하는 정확도를 변경할 수 있습니다.

내비메시 베이크 프로세스는 복셀화를 사용하여 임의의 레벨 지오메트리에서 내비메시를 작성합니다. 알고리즘의 첫 번째 단계에서 씬을 복셀에 래스터화한 다음 걷기 쉬운 표면을 추출하고 마지막으로 걷기 쉬운 표면을 탐색 메시로 바꿉니다. 복셀 크기는 결과 내비메시가 씬 지오메트리를 얼마나 정확하게 표현하는지를 나타냅니다.

디폴트 정확도는 에이전트 반지름당 3복셀, 즉 에이전트 전체 너비가 6복셀이 되도록 설정되어 있습니다. 정확도와 베이크 속도 사이에는 상쇄 효과가 존재합니다. 복셀 크기를 반으로 줄이면 메모리 사용이 4배 증가하고 씬을 빌드하는 데 4배 더 오래 걸립니다.

일반적으로 복셀 크기를 조정할 필요는 없습니다.

 더 작은 에이전트 반지름을 생성 하거나 보다 정확한 내비메시 를 만드는 두 가지 시나리오가 필요합니다.

더 작은 에이전트 반지름

인위적으로 더 작은 에이전트 반지름으로 베이크하면 내비메시 베이크 시스템은 복셀 크기를 같이 줄입니다. 다른 에이전트 크기가 동일하다면 내비메시 빌드 해상도를 높이지 않아도 됩니다.

가장 손쉬운 방법은 다음과 같습니다.

1. 에이전트 반지름 을 실제 에이전트 반지름에 설정합니다.
2. Manual Voxel Size 를 체크하면 현재 복셀 크기가 적용되고 “고정”됩니다.
3. 에이전트 반지름 을 인위적으로 작게 설정합니다. Manual Voxel Size 를 체크했기 때문에 복셀 크기가 변하지 않습니다.

보다 정확한 내비메시

레벨에 많은 단점이 있는 경우 복셀을 작게 만들어 정확도를 높이는 것이 좋습니다. 복셀 크기 아래의 레이블에는 복셀 크기와 에이전트 반지름 간의 관계가 표시됩니다. 28 사이가 적절하며, 일반적으로 빌드 시간이 길어지는 것보다 더 나아갑니다.

게임에서 의도적으로 타이트한 통로를 빌드할 때는 에이전트 반지름에 더해 최소한 4 * voxelSize 간격을 남겨둬야 합니다. 특히 통로가 각을 이루고 있다면 더욱 그렇습니다.

내비메시 베이킹이 지원할 수 있는 것보다 작은 복도가 필요한 경우 오프 메시 링크를 사용합니다. 이 링크는 사용 시 감지할 수 있고, 특정 애니메이션을 재생할 수 있는 등의 장점이 있습니다.

내비메시 에이전트 생성

게임 레벨의 내비메시를 베이크한 경우 씬 안에서 이동할 캐릭터를 생성합니다. 실린더로 프로토타입 에이전트를 빌드한 뒤 움직여 보겠습니다. 이 작업은 NavMesh Agent 컴포넌트와 간단한 스크립트를 통해 이루어집니다.

먼저 캐릭터를 생성합니다.

1. 원기둥을 생성합니다. 게임 오브젝트(GameObject) > 3D 오브젝트(3D Object) > 원기둥(Cylinder).
2. 디폴트 원기둥 크기(높이 2와 반경 0.5)는 휴머노이드 형태의 에이전트에 적합하므로 원기둥 형태로 둡니다.
3. 내비메시 에이전트 컴포넌트를 추가합니다. 컴포넌트(Component) > 내비게이션(Navigation) > 내비메시 에이전트(NavMesh Agent).

이제 간단한 내비메시 에이전트를 생성했으며 커맨드를 내릴 수 있습니다.

내비메시 에이전트로 실험을 시작하려면 캐릭터 크기와 속도에 맞춰 크기를 조정해야 합니다.

내비메시 에이전트 컴포넌트가 경로 탐색과 캐릭터의 움직임 조절까지 다룹니다. 스크립트에서 내비게이션으로 원하는 목표 포인트를 설정하면 내비메시 에이전트가 나머지 항목을 자동으로 처리합니다.

    // MoveTo.cs
        using UnityEngine;
        using UnityEngine.AI;
    
        public class MoveTo : MonoBehaviour {
       
           public Transform goal;
       
           void Start () {
              NavMeshAgent agent = GetComponent<NavMeshAgent>();
              agent.destination = goal.position; 
           }
        }

다음으로 간단한 스크립트를 빌드하여 또 다른 게임 오브젝트로 지정된 목표와 목표로 설정된 구체에 캐릭터를 보낼 수 있습니다.

1. 새 C# 스크립트(MoveTo.cs)를 생성하고 위의 스크립트로 콘텐츠를 작성합니다.
2. 생성한 캐릭터에 MoveTo 스크립트를 할당합니다.
3. sphere를 생성하여 에이전트가 도달할 목표로 만듭니다.
4. 캐릭터에서 구체를 NavMesh Surface에 가까운 위치로 옮깁니다.
5. 캐릭터를 선택하고 MoveTo 스크립트를 지정한 뒤 구체를 Goal 프로퍼티에 할당합니다.
6. Play 버튼을 누릅니다. 에이전트가 구체의 위치로 이동하는 것을 볼 수 있습니다.

즉, 스크립트에서 NavMesh Agent 컴포넌트의 레퍼런스를 가지고 에이전트를 움직이도록 설정하려면 에이전트의 destination 프로퍼티로 포지션을 할당합니다. 내비게이션 방법에서 내비메시 에이전트로 일반적인 게임플레이 시나리오 해결법에 대한 다양한 예제를 볼 수 있습니다

\

내비메시 장애물 생성

내비메시 장애물(NavMesh Obstacle) 컴포넌트는 에이전트가 이동하는 동안 피해야 하는 장애물을 정의하는 데 사용합니다. 예를 들어, 에이전트가 이동하는 동안 피해야 하는 상자나 통을 지정할 수 있습니다.

상자를 하나 추가하여 최상단의 경로를 차단해보겠습니다.

1. 우선 게임 오브젝트(Game Object) > 3D 오브젝트(3D Object) > 큐브(Cube) 에서 큐브를 만들어 상자를 생성합니다.
2. 큐브를 상단의 플랫폼으로 이동합니다. 큐브의 디폴트 크기가 상자의 크기로 적당하므로 그대로 둡니다.
3. 큐브에 내비메시 장애물 컴포넌트를 추가합니다. 인스펙터에서 컴포넌트 추가(Add Component)를 선택한 다음 내비게이션(Navigation) > 내비메시 장애물(NavMesh Obstacle)을 선택합니다.
4. 장애물의 모양을 박스(box)로 설정합니다. 모양이 변경되면서 큐브 중심과 크기가 렌더 메시에 자동으로 맞춰집니다.
5. 장애물에 리지드바디를 추가합니다. 인스펙터에서 컴포넌트 추가(Add Component)를 선택한 다음 물리(Physics) > 리지드바디(Rigid Body)를 선택합니다.
6. 마지막으로 에이전트가 장애물을 피하여 경로를 찾을 수 있도록 내비메시 장애물(NavMesh Obstacle) 인스펙터에서 Carve 설정을 활성화합니다.

이제 물리적으로 제어되는 상자가 활성화되었으며, AI는 이 상자를 피해 경로를 찾습니다.

오프 메시 링크 생성

오프 메시 링크(Off-Mesh Link)는 걸을 수 있는 내비게이션 메시 표면 외 지나갈 수 있는 경로를 만드는 데 사용됩니다. 예를 들어, 배수로나 펜스 뛰어넘기 또는 지나가기 전에 문 열기 등이 오프 메시 링크로 묘사될 수 있습니다.

오프 메시 링크 컴포넌트를 추가해 위 플랫폼에서 지상으로 점프하는 움직임을 구현해 보겠습니다.

1. 먼저 원기둥 2개를 생성합니다. 게임 오브젝트(Game Object) > 3D 오브젝트(3D Object) > 원기둥(Cylinder).
2. 원기둥의 크기를 (0.1, 0.5, 0.1) 로 조정해서 더 쉽게 작업할 수 있습니다.
3. 첫 번째 원기둥을 위 플랫폼의 모서리인 내비메시 표면 가까이로 옮깁니다.
4. 두 번째 원기둥을 내비메시 주변, 링크가 착지할 지점의 지상에 배치합니다.
5. 왼쪽의 원기둥을 선택하고 오프 메시 링크 컴포넌트를 추가합니다. 인스펙터에서 컴포넌트 추가(Add Component)를 선택하고 내비게이션(Navigation) > 오프 메시 링크(Off-Mesh Link)를 선택합니다.
6. 왼쪽의 원기둥을 시작(Start) 필드에 할당하고 오른쪽의 원기둥을 끝(End) 필드에 할당합니다.

오프 메시 링크 설정을 마쳤습니다. 만약 오프 메시 링크를 통한 경로가 내비메시를 통한 경로보다 짧을 경우 오프 메시 링크가 사용됩니다.

오프 메시 링크 컴포넌트를 지속시키기 위해 씬에서 모든 게임 오브젝트를 이용할 수 있습니다. 예를 들어 펜스 프리팹에 오프 메시 링크 컴포넌트를 포함시킬 수 있습니다. 또한 변환이 포함된 모든 게임 오브젝트를 시작과 끝 마커로 사용할 수 있습니다.

내비메시 베이크 프로세스는 공통의 건너뛰기 및 떨어지기 링크를 자동으로 탐지하고 생성할 수 있습니다. 자세한 내용은 오프 메시 링크 자동으로 빌드하기를 참조하십시오.

자동으로 오프 메시 링크 빌드

오프 메시 링크의 일부는 자동으로 감지되어 생성됩니다. 가장 일반적인 경우는 떨어지기(Drop-Down) 와 건너뛰기(Jump-Across) 입니다.

• 떨어지기 링크는 플랫폼에서 떨어질 때 만들어집니다.
• 건너뛰기 링크는 틈을 건너뛸 때 만들어집니다.

점프 위치를 자동으로 찾기 위해 빌드 프로세스는 내비메시의 가장자리를 따라 걸어가고 내비메시 위에 착지 위치를 확인합니다. 점프 궤도에 별다른 장애물이 없을 경우 오프 메시 링크가 생성됩니다.

이제 오프 메시 링크가 자동으로 생성되도록 설정해 보겠습니다. 내비메시 베이킹에 익숙하지 않다면 내비메시 빌드를 참조하십시오.

먼저 씬에서 점프가 시작될 수 있는 오브젝트를 표시해야 합니다. 오브젝트 탭 아래의 _ 내비게이션 창_에 있는 Generate Off-Mesh Links 옵션을 체크하면 됩니다.

그런 다음, 떨어지기 및 건너뛰기 궤도를 다음과 같이 설정합니다.

• 떨어지기 링크의 생성은 Drop Height 파라미터에 의해 제어됩니다. 이 파라미터는 연결이 유지되는 가장 높은 낙하 거리를 제어하며, 이 값을 0으로 설정하면 링크가 생성되지 않습니다.
• 떨어지기 링크의 궤도가 정의되면 수평 경로 (A)는 2\agentRadius + 4\voxelSize 가 됩니다. 이는 떨어질 경우 플랫폼 가장자리 바로 뒤에 착지한다는 것을 뜻합니다. 또한 단순히 걸어서 내려가지 않게 하려면 수직 경로 (B)는 베이크 설정의 Step Height 보다는 높아야 합니다. 그리고 복셀 크기를 통해 조정이 이루어지더라도 복셀화 과정 동안 발생하는 반올림 오류로 인해 링크가 생성되지 않는 일이 없도록 하려면 수직 경로가 Drop Height 보다는 작아야 합니다. Drop Height 의 값은 현재 레벨에서 측정한 값보다 약간 더 높게 설정해야 링크가 올바르게 연결됩니다.
• 건너뛰기 링크 생성은 Jump Distance 파라미터에 의해 제어됩니다. 이 파라미터는 연결이 유지되는 최장 거리를 제어합니다. 이 값을 0으로 설정하면 링크가 생성되지 않습니다.
• 건너뛰기 링크의 궤도가 정의되면 수평 경로 (C)는 2\*agentRadius 보다는 크지만 Jump Distance 파라미터의 값보다는 작습니다. 또한 착지 지점 (D)는 시작 지점의 레벨에 있는 복셀의 크기보다 높아서는 안 됩니다.

이제 오브젝트가 표시되었고 설정이 조정되었으므로 Bake 를 누르면 자동으로 오프 메시 링크가 생성됩니다. 씬을 변경하고 다시 베이크하는 경우 이전 링크는 제거되고 새로운 링크가 새로운 씬에 기반하여 생성됩니다.

문제 해결

오프 메시 링크가 의도하지 않은 위치에 생성되는 경우 다음 사항에 유의해야 합니다.

• Drop Height 값은 현재 레벨에서 측정한 실제 거리보다 약간 더 커야 합니다. 이렇게 해야 내비메시 베이킹 프로세스 동안 약간의 오차가 발생하더라도 링크가 연결됩니다.
• Jump Distance 값은 현재 레벨에서 측정한 실제 거리보다 약간 더 커야 합니다. Jump Distance는 내비메시의 한 지점에서 다른 지점까지의 거리로 측정되므로 2\*agentRadius 보다 더 큰 값으로 설정해야 틈을 건너뛸 수 있습니다.

정확한 캐릭터 배치를 위한 하이트 메시 빌드

하이트 메시(Height Mesh)를 이용하여 걸을 수 있는 표면에 캐릭터를 더 정확하게 배치할 수 있습니다.

길을 찾는 동안 내비메시 에이전트는 내비메시 표면에 있어야 합니다. 내비메시는 걸을 수 있는 공간을 대략적으로 추정한 것이므로, 내비메시가 빌드되는 동안 일부 기능이 안정화됩니다. 예를 들어 계단은 내비메시에서는 경사로 표현될 수도 있습니다. 게임에서 에이전트의 위치를 정확하게 지정해야 하는 경우에는 내비메시를 베이크할 때 하이트 메시 빌딩을 활성화해야 합니다. 이 설정은 내비게이션 창의 고급 옵션에 있습니다. 이 기능을 활성화하면 런타임 도중 메모리와 처리 시간을 추가적으로 요구하게 되며, 내비메시를 베이크할 때 더 오랜 시간이 필요하게 된다는 점을 기억해야 합니다.

내비게이션 영역 및 비용

Navigation Areas 는 특정 영역을 걸어서 지나가는 데 드는 비용(어려움)을 뜻하며, 경로를 탐색할 때에는 낮은 비용 영역순으로 선택됩니다. 또한 각각의 내비메시 에이전트에는 Area Mask 가 있어 에이전트가 이동할 수 있는 영역을 지정할 수 있습니다.

위의 예제에서, 영역 타입은 아래 두 개의 사용 사례에 사용됩니다.

• Water 영역에는 높은 비용을 할당되어 있어 걸어가는 데 더 많은 비용이 소요됩니다. 이를 통해 물이 얕은 곳을 느리게 걸어가는 시나리오를 처리할 수 있습니다.
• Door 영역에는 특정 캐릭터만 접근할 수 있습니다. 이를 통해 사람은 통과할 수 있지만 좀비는 통과할 수 없는 시나리오를 처리할 수 있습니다.

영역 타입은 내비메시 베이킹에 포함된 모든 오브젝트에 할당할 수 있으며, 각각의 오프 메시 링크에는 영역 타입을 지정하는 프로퍼티가 있습니다.

경로 탐색 비용

비용을 조절하여 경로 탐색자가 경로를 탐색할 때 선호하는 영역을 제어할 수 있습니다. 예를 들어 한 영역의 비용을 3.0으로 설정하면, 해당 영역을 지나가기 위해서는 다른 경로로 지나갈 때보다 세 배의 시간이 걸립니다.

비용의 작동 방식을 완전히 파악하기 위해 경로 탐색자의 작동 방식을 살펴보겠습니다.

경로 탐색 도중 거쳐가는 노드와 링크

Unity는 A*를 사용하여 내비메시에서 최단 경로를 계산합니다. A*는 연결된 노드 그래프에서 작동합니다. 이 알고리즘은 경로 시작점에서 가장 가까운 노드에서부터 시작하여 여러 연결 노드를 거쳐 목적지에 도달합니다.

Unity 내비게이션은 폴리곤 메시로 나타나기 때문에 경로 탐색자는 우선 각 폴리곤에 노드의 위치가 되는 포인트를 배치해야 합니다. 최단 경로는 이 노드들 사이에서 계산됩니다.

위 그림의 노란 점과 선은 A*를 따라 가로지르는 순서에 따라 노드와 링크가 내비메시에 배치되는 방식을 보여줍니다.

두 노드 사이를 이동하는 비용은 이동하는 거리와 링크 아래의 폴리곤 영역 타입에 설정된 비용에 따라 달라지며, 이를 거리 * 비용 이라고 합니다. 실제로 영역의 비용이 2.0인 경우 해당 폴리곤을 지나가는 거리는 두 배로 표시됩니다. A* 알고리즘에서는 모든 비용이 1.0 이상이어야 합니다.

최종 경로에서의 비용의 영향은 조절하기 어려우며, 특히 경로가 길수록 더 어렵습니다. 비용을 다루는 가장 좋은 방법은 비용을 힌트로 취급하면 됩니다. 예를 들어, 에이전트가 오프 메시 링크를 너무 자주 사용하지 않게 하려면 이 비용을 늘리면 됩니다. 하지만 에이전트가 보도 위를 걷는 것을 선호하는 동작을 조절하기는 어려울 수 있습니다.

어떤 레벨에서 경로 탐색자는 항상 최단 경로를 선택하지 않는다는 점도 알아두어야 합니다. 이는 노드 배치 때문입니다. 작은 장애물 옆에 큰 열린 영역이 있을 때, 즉 내비게이션 메시에 아주 큰 폴리곤과 아주 작은 폴리곤이 포함될 때 이런 현상을 쉽게 볼 수 있습니다. 큰 폴리곤의 노드는 해당 폴리곤의 아무 곳에나 배치될 수 있는데, 경로 탐색자의 관점에서 볼 때 이것이 우회 경로로 보일 수 있습니다.

영역 타입 의 비용 은 Areas 탭에서 전역으로 설정하거나 스크립트를 사용하여 에이전트별로 오버라이드할 수 있습니다.

영역 타입

영역 타입은 내비게이션 창 의 영역 탭에 있습니다. 29 개의 커스텀 타입과 Walkable, Not Walkable, Jump 등 3개의 빌트인 타입이 있습니다.

• Walkable은 걸을 수 있는 영역을 의미하는 일반적인 영역 타입입니다.
• Not Walkable은 내비게이션을 방지하는 일반적인 영역 타입입니다. 내비메시가 해당 영역을 지나가지 못하게 하면서 특정 오브젝트를 장애물로 표시할 때 사용할 수 있습니다.
• Jump는 자동으로 생성된 모든 오프 메시 링크에 할당되는 영역 타입입니다.

다른 영역 타입의 오브젝트가 여러 개 중첩되는 경우 일반적으로 최종 생성된 내비메시 영역 타입이 우선적으로 적용됩니다. 하지만 Not Walkable 은 예외적으로 항상 최우선적으로 적용됩니다. 이를 통해 특정 영역을 차단해야 하는 경우 확실하게 차단할 수 있습니다.

영역 마스크

각 에이전트에는 내비게이션에 사용할 영역을 정의할 수 있는 Area Mask 가 있습니다. 영역 마스크는 에이전트 프로퍼티에서 설정할 수 있으며, 런타임 중에는 스크립트를 사용하여 비트마스크를 조작할 수 있습니다.

영역 마스크는 특정 타입의 캐릭터만 해당 영역을 지나갈 수 있게 할 때 유용합니다. 예를 들어 좀비에게서 도망치기 게임에서 각각의 문 아래 영역을 Door 영역 타입으로 표시하고, 좀비 캐릭터의 영역 마스크에서 Door 영역을 선택 해제하면 좀비가 해당 영역을 통과하지 못합니다.

추가 로딩을 사용하여 여러 내비메시 로드

다른 씬의 내비메시는 기본적으로 연결되지 않습니다. Application.LoadLevelAdditive() 를 사용하여 다른 레벨을 로드하는 경우 오프 메시 링크를 사용하여 여러 씬의 내비메시를 연결해야 합니다.

위의 예제에 Scene 1 과 Scene 2 가 있습니다. Scene 1 에는 걷기 쉬운 영역에서 시작하여 Scene 2 의 걷기 쉬운 영역에 착륙하는 오프 메시 링크가 있습니다. 필요에 따라 씬을 연결하는 만큼 많은 오프 메시 링크가 있을 수 있습니다.

작성 시 오프 메시 링크를 연결하는 씬의 다른 끝 지점은 연결되지 않습니다. 새로운 씬이 로드된 후 오프 메시 링크가 다시 연결됩니다.

여러 씬의 내비메시가 동일한 영역에서 겹쳐져 있는 경우 위치 선택은 해당 위치에서 임의의 내비메시일 수 있습니다. 이는 내비메시 API를 사용하는 에이전트, 오프 메시 링크 및 포지션 선택에 적용됩니다. 오프 메시 링크가 하나의 내비메시에서만 시작되고 끝날 수 있게 씬을 만들어야 합니다. 겹치는 내비메시 영역은 자동으로 연결되지 않습니다.

내비메시 에이전트를 다른 컴포넌트와 함께 사용

내비메시 에이전트(NavMesh Agent), 내비메시 장애물(NavMesh Obstacle), 오프 메시 링크(Off Mesh Link) 컴포넌트는 다른 Unity 컴포넌트와 함께 사용할 수 있습니다. 다른 컴포넌트를 함께 사용할 때에는 다음과 같은 규칙을 따라야 합니다.

내비메시 에이전트 및 물리

• 서로 충돌하지 않도록 내비메시 에이전트에 물리 콜라이더를 추가하지 않아도 됩니다.
  내비게이션 시스템이 에이전트뿐만 아니라 장애물과 정적 월드에 대한 에이전트의 반응까지 시뮬레이션하기 때문입니다. 여기서 정적 월드는 베이크된 내비메시입니다.
• 내비메시 에이전트가 물리 오브젝트를 푸시하거나 물리 트리거를 사용하도록 하려면 다음과 같이 수행해야 합니다. 
  콜라이더 컴포넌트를 추가합니다(없을 경우).
  리지드바디 컴포넌트를 추가합니다.
  키네마틱(물리 법칙에 영향을 받지 않음)을 활성화합니다. 이 작업은 매우 중요합니다!
  키네마틱이란 리지드바디가 물리 시뮬레이션 이외의 다른 요소에 의해 제어된다는 뜻입니다.
• 내비메시 에이전트와 리지드바디(키네마틱이 아님)를 동시에 활성화하면 경합 조건이 발생합니다.
  두 컴포넌트가 동시에 에이전트를 움직이려고 하여 정의되지 않은 동작이 발생할 수 있습니다.
• 내비메시 에이전트를 사용하여 물리 없이 플레이어 캐릭터 등을 움직일 수 있습니다.
  플레이어 에이전트의 회피 우선 순위를 작은 숫자(우선 순위가 높음)로 설정하여 플레이어가 군중 사이를 헤치고 지나갈 수 있게 합니다.
  다른 에이전트가 플레이어의 움직임을 예측하여 회피할 수 있도록 NavMeshAgent.velocity를 통해 플레이어 에이전트를 움직입니다.

내비메시 에이전트 및 애니메이터

• 내비메시 에이전트와 루트 모션이 있는 애니메이터는 경합 조건을 유발할 수 있습니다.
  두 컴포넌트가 각 프레임에서 트랜스폼을 이동시키려고 합니다.
  두 가지 해결 방법 -
• 정보는 항상 한 방향으로 흘러야 합니다.
  에이전트가 캐릭터를 움직이고 애니메이션이 이를 따르거나,
  시뮬레이션 결과에 기반하여 애니메이션이 캐릭터를 움직여야 합니다.
  그렇지 않으면 피드백 루프를 디버그하기가 어려워집니다.
• 애니메이션이 에이전트를 따르는 경우 NavMeshAgent.velocity를 애니메이터의 입력값으로 사용하면 에이전트의 이동과 애니메이션이 대략적으로 일치합니다.
  확실하고 손쉬운 방법이지만, 애니메이션이 속도를 따라가지 못하면 발이 미끄러지는 결과가 나타날 수 있습니다.
• 에이전트가 애니메이션을 따르는 경우
  NavMeshAgent.updatePosition 및 NavMeshAgent.updateRotation을 비활성화하여 게임 오브젝트의 위치에서 시뮬레이션을 분리합니다.
  시뮬레이션된 에이전트의 포지션(NavMeshAgent.nextPosition)과 애니메이션 루트(Animator.rootPosition)의 차이를 사용하여 애니메이션 제어를 계산할 수 있습니다.

내비메시 에이전트 및 내비메시 장애물

• 혼합해서는 안 됩니다!
  둘 다 활성화하면 에이전트가 스스로 회피하게 됩니다.
  추가적으로 카빙이 활성화된 경우 에이전트는 카빙된 구멍의 가장자리로 지속적으로 다시 매핑하려고 하여 더 잘못된 동작이 발생합니다.
• 언제든지 둘 중 하나만 활성화되도록 합니다.
  멈춘 상태라면 에이전트를 끄고 장애물을 활성화하여 다른 에이전트가 이를 피하도록 합니다.
  또는 우선 순위를 설정하여 특정 에이전트를 더 회피하도록 할 수도 있습니다.

내비메시 장애물 및 물리

• 물리 제어되는 오브젝트가 내비메시 에이전트의 동작에 영향을 주도록 하려면 다음과 같이 수행해야 합니다.
  에이전트가 인지해야 하는 오브젝트에 내비메시 장애물 컴포넌트를 추가합니다. 이렇게 하면 회피 시스템이 장애물을 추론할 수 있습니다.
• 게임 오브젝트에 리지드바디와 내비메시 장애물이 추가된 경우 장애물의 속도는 자동으로 리지드바디에서 구해집니다.
  이렇게 하면 내비메시 에이전트가 움직이는 장애물을 예측하고 회피할 수 있습니다.

내비메시 에이전트

NavMeshAgent 컴포넌트는 목표를 향해 움직일 때 서로를 피해가는 캐릭터 생성에 유용합니다. 에이전트는 내비메시를 이용하여 게임 월드에 대해 추론하고 서로 또는 기타 움직이는 장애물을 피할 방법을 이해하고 있습니다. 내비메시 에이전트의 스크립팅 API를 이용하여 경로를 찾거나 공간을 추론할 수 있습니다.

프로퍼티

프로퍼티기능

세부 정보

에이전트는 수직으로 서 있는 실린더에 의해 정의되며 실린더의 크기는 Radius 과 Height 프로퍼티에 의해 특정됩니다. 실린더는 오브젝트와 함께 움직이지만 오브젝트가 회전한다 해도 계속 수직으로 서 있습니다. 실린더의 모양은 다른 에이전트와 장애물간의 충돌 감지와 대응에 사용됩니다. 게임 오브젝트의 앵커 포인트가 실린더의 베이스에 없을 때 높이의 차이를 메우기 위해 베이스 오프셋 프로퍼티를 사용할 수 있습니다.

실린더의 높이와 반경은 실제로 두 개 의 다른 장소에 특정됩니다. 내비메시 베이크 설정과 각 에이전트의 프로퍼티 입니다.

-내비메시 베이크 설정 은 내비메시 에이전트가 어떻게 정적인 월드 지오메트리와 충돌하고 또는 어떻게 회피하는지를 설명합니다. 메모리 여유량을 유지하고 CPU 로드를 지속적으로 체크하기 위해 오직 하나의 크기만이 베이크 설정에서 특정될 수 있습니다. -내비메시 에이전트 프로퍼티 값은 에이전트가 움직이는 장애물 및 다른 에이전트와 어떻게 충돌하는지를 설명합니다.

대부분의 경우 두 장소 모두에 에이전트 크기를 똑같이 설정합니다. 하지만 예를 들어 크기가 큰 에이전트의 반경이 더 넓다면 다른 에이전트는 그 에이전트 주변에 공간을 더 많이 남겨둡니다. 하지만 그렇지 않다면 크기가 큰 에이전트도 마찬가지로 환경을 무시합니다.

내비메시 장애물

Nav Mesh Obstacle 컴포넌트로 내비메시 에이전트가 월드를 탐색하는 동안 피해야 하는 움직이는 장애물(예: 물리 시스템에 의해 제어되는 배럴 또는 크레이트)을 설명할 수 있습니다. 장애물이 움직일 때 내비메시 에이전트는 장애물을 피하기 위해 최선을 다합니다. 장애물이 정지 상태일 때는 내비메시에 구멍을 팝니다. 그러면 내비메시 에이전트가 경로를 바꿔 장애물을 돌아가거나, 장애물로 인해 경로가 완전히 차단될 경우 다른 길을 찾습니다.

프로퍼티기능

세부 정보

내비메시 장애물은 게임 중에 다음 두 가지 방법으로 내비메시 에이전트의 내비게이션에 영향을 미칠 수 있습니다.

방해

Carve 가 활성화되지 않은 경우 내비메시 장애물의 디폴트 동작은 콜라이더와 비슷합니다. 내비메시 에이전트는 내비메시 장애물과 충돌을 피하려고 하고, 내비메시 장애물과 가까우면 충돌합니다. 장애물 회피 동작은 매우 기본적이며 짧은 반경을 가집니다. 따라서 내비메시 에이전트는 내비메시 장애물이 많은 환경에서 장애물을 피해갈 길을 찾지 못할 수 있습니다. 이 모드는 장애물이 계속 움직이는 경우(예: 차량이나 플레이어 캐릭터)에 사용하면 가장 적합합니다.

카빙

Carve 가 활성화된 경우, 장애물은 정지 중일 때 내비메시에 구멍을 팝니다. 장애물은 이동할 때 방해물이 됩니다. 내비메시에 구멍을 파면 패스파인더는 내비메시 에이전트가 장애물이 많은 장소를 피해 돌아가도록 하거나, 현재 경로가 장애물에 막힐 경우 다른 길을 찾을 수 있습니다. 일반적으로 내비게이션을 막지만 플레이어나 기타 폭발 같은 게임 이벤트에 의해 이동될 수 있는 내비메시 장애물(예: 크레이트 또는 배럴)에 대해서는 카빙을 켜는 것이 좋습니다.

내비메시 장애물 이동 논리

Unity는 내비메시 장애물이 Carve > Move Threshold 에서 설정한 거리보다 많이 이동할 경우 이동 중인 것으로 간주합니다. 내비메시 장애물이 이동하면 파인 구멍도 이동합니다. 하지만 CPU 오버헤드를 줄이기 위해 필요한 경우에만 구멍을 다시 산출합니다. 이 산출의 결과는 다음 프레임 업데이트에 사용 가능합니다. 재산출 논리에는 다음 두 가지 옵션이 있습니다.

• 내비메시 장애물이 정지 상태일 때만 카빙
• 내비메시 장애물이 이동된 경우에 카빙

내비메시 장애물이 정지 상태일 때만 카빙

디폴트 동작입니다. 이 옵션을 활성화하려면 Nav Mesh Obstacle 컴포넌트의 Carve Only Stationary 체크박스를 선택해야 합니다. 이 모드에서 내비메시 장애물이 움직이면 파인 구멍이 제거됩니다. 내비메시 장애물의 이동이 멈추고 Carving Time To Stationary 에서 설정한 시간보다 오랫동안 정지해 있으면 정지 상태로 간주되고 파인 구멍이 다시 업데이트됩니다. 내비메시 장애물이 이동 중인 동안에는 내비메시 에이전트가 충돌 방지를 사용하여 장애물을 피하지만 장애물을 돌아갈 경로를 계획하지는 않습니다.

Carve Only Stationary 는 일반적으로 성능의 관점에서 최선의 선택이고 내비메시 장애물과 연관된 게임 오브젝트가 물리를 통해 제어되는 경우에 적합합니다.

내비메시 장애물이 이동된 경우에 카빙

이 모드를 활성화하려면 Nav Mesh Obstacle 컴포넌트의 Carve Only Stationary 체크박스를 선택 해제해야 합니다. 선택 해제하면 장애물이 Carving Move Threshold 에서 설정된 거리보다 많이 이동한 경우 파인 구멍이 업데이트됩니다. 이 모드는 예를 들어 보병대가 피하려고 하는 탱크처럼 크고 천천히 이동하는 장애물에 유용합니다.

참고: 내비메시 쿼리 메서드를 사용하는 경우 내비메시 장애물을 변경한 후 이 변경 사항이 내비메시에 영향을 미칠 때까지 1프레임이 지연됨을 감안해야 합니다.

오프 메시 링크

OffMeshLink 컴포넌트는 걸을 수 있는 표면만으로는 표현할 수 없는 네비게이션 단축키를 구체화할 수 있도록 해 줍니다. 예를 들어, 도랑이나 울타리를 뛰어넘는 경우나 문을 열어야 걸어 지나갈 수 있을 경우, 이런 동작을 오프 메시 링크로 묘사할 수 있습니다.

프로퍼티

프로퍼티기능

세부 정보

에이전트가 오프 메시 링크를 따라 이동하지 않는다면 양 끝 지점이 제대로 연결되어 있는지 확인해야 합니다. 올바르게 연결된 끝 지점은 액세스 포인트 주위에 원형으로 표시가 나타납니다.

또 다른 원인으로 내비메시 에이전트의 에어리어 마스크 가 오프 메시 링크 영역을 포함하지 않았을 수도 있습니다.

NavMeshAgent에 목표로 이동 지시

NavMeshAgent.destination 프로퍼티를 설정하는 것으로 에이전트에 이동시키고자 하는 포인트까지의 경로를 산출시킬 수 있습니다. 산출이 완료되는 즉시 에이전트는 자동으로 경로를 따라 이동하여 목표에 도달합니다. 다음의 코드는 게임 오브젝트를 이용하여 목표 포인트를 설정하는 간단한 클래스를 사용하며 Start 함수의 destination 프로퍼티에 할당됩니다. 스크립트는 이미 NavMeshAgent 컴포넌트를 에디터로부터 추가하고 설정했다고 간주한다는 점에 유의해야 합니다.

    // MoveDestination.cs
        using UnityEngine;
    
        public class MoveDestination : MonoBehaviour {
       
           public Transform goal;
       
           void Start () {
              NavMeshAgent agent = GetComponent<NavMeshAgent>();
              agent.destination = goal.position; 
           }
        }

    // MoveDestination.js
        var goal: Transform;

        function Start() {
          var agent: NavMeshAgent = GetComponent.<NavMeshAgent>();
          agent.destination = goal.position; 
        }

마우스로 클릭한 포지션으로 에이전트 이동

이 스크립트에서는 오브젝트의 표면을 마우스로 클릭하여 내비메시의 목표 포인트로 선택합니다. 클릭 포지션은 레이저 빔을 오브젝트에 쏴서 어디에 광선이 닿는지 확인하는 것처럼 레이캐스트 로 결정됩니다. 이 기법에 대한 자세한 설명은 카메라에서 나오는 레이 페이지를 참조하십시오. GetComponent 함수는 실행 속도가 매우 느리므로 스크립트는 결과를 업데이트 시에 반복적으로 호출하지 많고 Start 함수 실행 중에 결과를 변수 안에 저장합니다.

    // MoveToClickPoint.cs
        using UnityEngine;
        using UnityEngine.AI;
    
        public class MoveToClickPoint : MonoBehaviour {
            NavMeshAgent agent;
        
            void Start() {
                agent = GetComponent<NavMeshAgent>();
            }
        
            void Update() {
                if (Input.GetMouseButtonDown(0)) {
                    RaycastHit hit;
                
                    if (Physics.Raycast(Camera.main.ScreenPointToRay(Input.mousePosition), out hit, 100)) {
                        agent.destination = hit.point;
                    }
                }
            }
        }

    //MoveToClickPoint.js
        var agent: NavMeshAgent;
    
        function Start() {
            agent = GetComponent.<NavMeshAgent>();
        }

        function Update() {
            if (Input.GetMouseButtonDown(0)) {
                var hit: RaycastHit;
        
                if (Physics.Raycast(Camera.main.ScreenPointToRay(Input.mousePosition), hit, 100)) {
                    agent.destination = hit.point;
                }
            }
        }

포인트 세트 사이에 에이전트 패트롤 생성

많은 게임이 자동으로 영역을 패트롤하는 NPC를 활용하고 있습니다. 이 동작을 실행하는 데 내비게이션 시스템을 사용할 수 있지만 일반적인 경로 탐색보다 더 많은 부분에서 관여해야 합니다. 일반적인 경로 탐색은 두 점 사이에 단순히 가장 가까운 경로를 지정하는 것으로 제한되고 예상되는 패트롤 루트를 만들어 냅니다. NPC가 경로를 따라 움직이고 방문하는 시퀀스를 특정할 때 “유용한” 키 포인트 세트를 지정하여 더 그럴싸한 패트롤 패턴을 만들어 낼 수 있습니다. 예를 들면 미로에서 갈림길과 코너에 키 패트롤 포인트를 지정하고 에이전트가 모든 복도를 체크하도록 할 수 있습니다. 사무실 건물에서는 키 포인트가 개별 사무실이나 다른 방이 될 수 있습니다.

키 패트롤 포인트가 마크된 미로

이상적인 패트롤 포인트의 시퀀스는 NPC가 어떻게 행동하길 원하는지에 따라 다릅니다. 예를 들어 로봇이 체계적인 순서로 포인트를 방문하지만 인간 경비는 더 랜덤한 패턴으로 플레이어를 잡으려 들지 모릅니다. 로봇의 단순한 동작은 아래의 코드로 구현될 수 있습니다.

패트롤 포인트는 변환의 공용 배열을 사용해서 스크립트에 제공됩니다. 이 배열은 인스펙터에서 게임 오브젝트를 사용하여 포인트의 포지션을 마크하기 위해 할당될 수 있습니다. GotoNextPoint 함수는 에이전트를 위한 목적지 포인트를 지정하며(에이전트를 움직이게 만듦) 다음 호출에 사용할 새로운 목적지를 선택합니다. 이에 따라 코드가 배열에서 발생하는 순서대로 포인트를 돌아다니게 됩니다. 이는 쉽게 수정할 수 있는데, 예를 들어 Random.Range를 사용하여 랜덤하게 배열 인덱스를 고를 수 있습니다.

Update 함수에서 remainingDistance 프로퍼티를 사용하여 에이전트가 얼마나 목적지에서 떨어져 있는지를 스크립트가 체크합니다. 거리가 짧으면 GotoNextPoint 를 호출하여 다음 패트롤을 시작하게 합니다.

    // Patrol.cs
        using UnityEngine;
        using UnityEngine.AI;
        using System.Collections;


        public class Patrol : MonoBehaviour {

            public Transform[] points;
            private int destPoint = 0;
            private NavMeshAgent agent;


            void Start () {
                agent = GetComponent<NavMeshAgent>();

                // Disabling auto-braking allows for continuous movement
                // between points (ie, the agent doesn't slow down as it
                // approaches a destination point).
                agent.autoBraking = false;

                GotoNextPoint();
            }


            void GotoNextPoint() {
                // Returns if no points have been set up
                if (points.Length == 0)
                    return;

                // Set the agent to go to the currently selected destination.
                agent.destination = points[destPoint].position;

                // Choose the next point in the array as the destination,
                // cycling to the start if necessary.
                destPoint = (destPoint + 1) % points.Length;
            }


            void Update () {
                // Choose the next destination point when the agent gets
                // close to the current one.
                if (!agent.pathPending && agent.remainingDistance < 0.5f)
                    GotoNextPoint();
            }
        }

    // Patrol.js
        var points: Transform[];
        var destPoint: int = 0;
        var agent: NavMeshAgent;


        function Start() {
            agent = GetComponent.<NavMeshAgent>();

            // Disabling auto-braking allows for continuous movement
            // between points (ie, the agent doesn't slow down as it
            // approaches a destination point).
            agent.autoBraking = false;

            GotoNextPoint();
        }


        function GotoNextPoint() {
            // Returns if no points have been set up
            if (points.Length == 0)
                return;
            
            // Set the agent to go to the currently selected destination.
            agent.destination = points[destPoint].position;

            // Choose the next point in the array as the destination,
            // cycling to the start if necessary.
            destPoint = (destPoint + 1) % points.Length;
        }


        function Update() {
            // Choose the next destination point when the agent gets
            // close to the current one.
            if (!agent.pathPending && agent.remainingDistance < 0.5f)
                GotoNextPoint();
        }

애니메이션과 내비게이션 연결

이 문서는 내비게이션 시스템을 사용하여 내비게이팅 휴머노이드 캐릭터가 움직이도록 설정하는 방법을 설명하기 위해 작성되었습니다.

여기서는 Unity 빌트인 애니메이션 시스템, 내비게이션 시스템, 커스텀 스크립팅을 활용해서 휴머노이드 캐릭터를 움직이게 할 것입니다.

Unity 기본 사용법과 메카님 애니메이션 시스템을 완전히 이해하고 있다는 전제 하에 시작됩니다.

예제 프로젝트를 이용할 수 있으므로 처음부터 스크립트를 추가하거나 애니메이션 및 애니메이션 컨트롤러를 설정할 필요는 없습니다.

• NavigationAnimation_53.zip Unity 5.3 이상에서 작동합니다.

애니메이션 컨트롤러 생성

광범위한 움직임을 커버할 수 있는, 즉각적인 대응이 가능하고 다양한 용도로 활용할 수 있는 애니메이션 컨트롤러를 갖추기 위해서는 다양한 방향으로 움직이는 애니메이션 세트가 필요합니다. 세트는 스트레이프 세트(strafe-set)라고도 불립니다.

움직이는 애니메이션 외에도 서 있는 캐릭터를 위한 애니메이션이 필요합니다.

2D 블렌드 트리에 스트레이프 세트를 정렬하는 것으로 블렌드 타입을 선택합니다. 2D Simple Directional을 이용하며 Compute Positions > Velocity XZ를 통해 애니메이션을 적용합니다.

블렌딩 조절을 위해 velx와 vely 두 개의 플로트 파라미터를 추가하고 블렌드 트리에 할당합니다.

여기서 7개의 달리기 애니메이션을 배치합니다. 각 애니메이션은 다른 속도로 달리고 있습니다. 앞(+ 좌/우)과 뒤(+ 좌/우)에 더해서 제자리에서 달리는 애니메이션 클립을 사용합니다. 후자는 아래의 2D 블렌드 맵의 중앙에 하이라이트되어 있습니다. 제자리 달리기 애니메이션이 필요한 이유는 두 가지가 있습니다. 첫 번째 이유는 다른 애니메이션과 혼합되는 경우에도 달리는 스타일을 유지할 수 있기 때문이며, 두 번째 이유는 혼합되는 동안 발이 미끄러지는 현상을 방지하기 때문입니다.

애니메이션 노드에 대기 애니메이션 클립을 추가합니다(Idle). 이제 두 개의 트랜지션에 각각 해당하는 두 개의 분리된 애니메이션 상태가 준비되었습니다.

움직임과 대기 상태의 전환을 조절하려면 부울(boolean) 제어 파라미터 move를 추가합니다. 그리고 트랜지션에서 종료 시간 있음(Has Exit Time) 프로퍼티를 비활성화합니다. 이를 통해 애니메이션 중 어느 때라도 트랜지션이 트리거될 수 있습니다. 즉각적으로 대응하는 트랜지션을 위해 트랜지션 시간은 대략 0.10초로 설정합니다.

새롭게 생성한 애니메이션 컨트롤러를 움직일 캐릭터에 위치시킵니다.

계층 구조 창에서 플레이 버튼을 누르고 캐릭터를 선택합니다. 이제 수동으로 애니메이터 창의 애니메이션 값을 조절해서 움직임 상태와 속도를 변경할 수 있습니다.

다음으로 애니메이션 파라미터를 조절할 수 있는 다른 방법을 생성합니다.

내비게이션 컨트롤

NavMeshAgent 컴포넌트를 캐릭터에 적용하고 반지름, 높이를 캐릭터와 일치하도록 조정합니다. 추가적으로 속도 프로퍼티를 애니메이션 블렌드 트리의 최대 속도와 일치하도록 변경합니다.

캐릭터를 배치한 씬의 내비메시를 생성합니다.

다음으로 캐릭터에게 어디로 이동할지 지정합니다. 지정하는 방법은 애플리케이션에 따라 크게 다릅니다. 이번에는 사용자가 화면에서 클릭하는 포인트로 캐릭터가 움직이게 해서 동작을 지정합니다.

// ClickToMove.cs
using UnityEngine;
using UnityEngine.AI;

[RequireComponent (typeof (NavMeshAgent))]
public class ClickToMove : MonoBehaviour {
    RaycastHit hitInfo = new RaycastHit();
    NavMeshAgent agent;

    void Start () {
        agent = GetComponent<NavMeshAgent> ();
    }
    void Update () {
        if(Input.GetMouseButtonDown(0)) {
            Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition);
            if (Physics.Raycast(ray.origin, ray.direction, out hitInfo))
                agent.destination = hitInfo.point;
        }
    }
}

플레이 버튼을 누르고 나서 씬 안을 클릭하면 캐릭터가 움직입니다. 그러나 애니메이션이 움직임과 일치하지 않습니다. 에이전트의 상태와 속도를 애니메이션 컨트롤러와 연동시켜야 합니다.

에이전트의 속도와 상태 정보를 애니메이션 컨트롤러로 전달하기 위해 추가 스크립트를 더합니다.

// LocomotionSimpleAgent.cs
using UnityEngine;
using UnityEngine.AI;

[RequireComponent (typeof (NavMeshAgent))]
[RequireComponent (typeof (Animator))]
public class LocomotionSimpleAgent : MonoBehaviour {
    Animator anim;
    NavMeshAgent agent;
    Vector2 smoothDeltaPosition = Vector2.zero;
    Vector2 velocity = Vector2.zero;

    void Start ()
    {
        anim = GetComponent<Animator> ();
        agent = GetComponent<NavMeshAgent> ();
        // Don’t update position automatically
        agent.updatePosition = false;
    }
    
    void Update ()
    {
        Vector3 worldDeltaPosition = agent.nextPosition - transform.position;

        // Map 'worldDeltaPosition' to local space
        float dx = Vector3.Dot (transform.right, worldDeltaPosition);
        float dy = Vector3.Dot (transform.forward, worldDeltaPosition);
        Vector2 deltaPosition = new Vector2 (dx, dy);

        // Low-pass filter the deltaMove
        float smooth = Mathf.Min(1.0f, Time.deltaTime/0.15f);
        smoothDeltaPosition = Vector2.Lerp (smoothDeltaPosition, deltaPosition, smooth);

        // Update velocity if time advances
        if (Time.deltaTime > 1e-5f)
            velocity = smoothDeltaPosition / Time.deltaTime;

        bool shouldMove = velocity.magnitude > 0.5f && agent.remainingDistance > agent.radius;

        // Update animation parameters
        anim.SetBool("move", shouldMove);
        anim.SetFloat ("velx", velocity.x);
        anim.SetFloat ("vely", velocity.y);

        GetComponent<LookAt>().lookAtTargetPosition = agent.steeringTarget + transform.forward;
    }

    void OnAnimatorMove ()
    {
        // Update position to agent position
        transform.position = agent.nextPosition;
    }
}

스크립트에는 설명이 필요합니다. Animator와 NavMeshAgent 컴포넌트가 추가된 캐릭터에 적용되며 위에서 설명한 클릭한 포인트로 움직이는 스크립트가 적용되어 있습니다.

먼저 스크립트가 에이전트에게 자동으로 캐릭터 포지션을 업데이트하지 말라고 전달합니다. 포지션 업데이트는 스크립트의 마지막에서 다룹니다. 오리엔테이션은 에이전트에 의해 업데이트 됩니다.

애니메이션 블렌드는 에이전트 속도를 읽는 것으로 조절됩니다. 상대적인 속도로 변환되고(캐릭터 오리엔테이션에 기초) 부드럽게 조정됩니다. 변환된 수평 속도 컴포넌트는 Animator로 이어지며 이에 더해서 대기 상태와 이동 사이의 전환은 속도에 의해 조절됩니다(예를 들어, 속도 규모).

OnAnimatorMove() 콜백에서 캐릭터의 포지션을 NavMeshAgent와 일치하도록 업데이트합니다.

씬을 다시 플레이하면 애니메이션이 최대한 움직임과 일치하는 것이 확인됩니다.

내비게이팅 캐릭터의 품질 개선

애니메이션 및 내비게이션 캐릭터의 품질을 개선하기 위해 여러 옵션을 살펴보겠습니다.

바라보기

관심있는 영역으로 캐릭터를 돌려서 바라볼 수 있게 하면 관심과 기대를 전달하는 데 유용합니다. 이제 애니메이션 시스템 바라보기 API를 사용하겠습니다. 이것은 또 다른 스크립트를 호출합니다.

// LookAt.cs
using UnityEngine;
using System.Collections;

[RequireComponent (typeof (Animator))]
public class LookAt : MonoBehaviour {
    public Transform head = null;
    public Vector3 lookAtTargetPosition;
    public float lookAtCoolTime = 0.2f;
    public float lookAtHeatTime = 0.2f;
    public bool looking = true;

    private Vector3 lookAtPosition;
    private Animator animator;
    private float lookAtWeight = 0.0f;

    void Start ()
    {
        if (!head)
        {
            Debug.LogError("No head transform - LookAt disabled");
            enabled = false;
            return;
        }
        animator = GetComponent<Animator> ();
        lookAtTargetPosition = head.position + transform.forward;
        lookAtPosition = lookAtTargetPosition;
    }

    void OnAnimatorIK ()
    {
        lookAtTargetPosition.y = head.position.y;
        float lookAtTargetWeight = looking ? 1.0f : 0.0f;

        Vector3 curDir = lookAtPosition - head.position;
        Vector3 futDir = lookAtTargetPosition - head.position;

        curDir = Vector3.RotateTowards(curDir, futDir, 6.28f*Time.deltaTime, float.PositiveInfinity);
        lookAtPosition = head.position + curDir;

        float blendTime = lookAtTargetWeight > lookAtWeight ? lookAtHeatTime : lookAtCoolTime;
        lookAtWeight = Mathf.MoveTowards (lookAtWeight, lookAtTargetWeight, Time.deltaTime/blendTime);
        animator.SetLookAtWeight (lookAtWeight, 0.2f, 0.5f, 0.7f, 0.5f);
        animator.SetLookAtPosition (lookAtPosition);
    }
}

캐릭터에 스크립트를 추가하고 헤드 프로퍼티를 캐릭터의 트랜스폼 계층 구조에 할당합니다. LookAt 스크립트는 내비게이션 조절과 관련 없습니다. 그러므로 어디를 보는지 조절하려면 LocomotionSimpleAgent.cs 스크립트로 돌아가서 두 행을 추가하는 것으로 바라보기를 조절합니다. Update()의 끝을 추가하려면 다음을 더합니다.

        LookAt lookAt = GetComponent<LookAt> ();
                if (lookAt)
                    lookAt.lookAtTargetPosition = agent.steeringTarget + transform.forward;

위의 행은 LookAt 스크립트가 경로 상에 모서리가 있는 경우에는 다음 모서리에, 없는 경우에는 경로 끝에 관심 지점을 설정하도록 합니다.**

시도해야 합니다.

내비게이션을 사용해 애니메이션으로 구동되는 캐릭터

이제까지 캐릭터는 에이전트가 명시한 포지션에 따라 완전히 제어되었습니다. 이렇게 하면 다른 캐릭터나 장애물이 제어하는 캐릭터의 포지션에 겹치지 않게 되지만, 애니메이션이 원하는 속도를 지원하지 못하는 경우에는 발이 미끄러지는 현상이 발생할 수 있습니다. 여기서는 캐릭터의 제한을 조금 완화하여, 회피 품질을 희생하여 애니메이션 품질을 개선해볼 것입니다.

LocomotionSimpleAgent.cs 스크립트에서 OnAnimatorMove() 콜백을 다음 행으로 교체합니다.

    void OnAnimatorMove ()
        {
            // Update position based on animation movement using navigation surface height
            Vector3 position = anim.rootPosition;
            position.y = agent.nextPosition.y;
            transform.position = position;
        }

교체를 시도할 때 캐릭터가 에이전트 포지션에서 멀어지는 것을 볼 수 있습니다(녹색 와이어프레임 실린더). 캐릭터가 멀어지는 것을 제한해야 합니다. 이렇게 하려면 에이전트를 캐릭터를 향해 당기거나, 캐릭터를 에이전트의 위치를 향해 당기면 됩니다. LocomotionSimpleAgent.cs 스크립트의 Update() 메서드 마지막에 다음을 추가합니다.

        // Pull character towards agent
                if (worldDeltaPosition.magnitude > agent.radius)
                    transform.position = agent.nextPosition - 0.9f*worldDeltaPosition;

아니면 에이전트가 캐릭터를 따라가도록 할 수 있습니다.

        // Pull agent towards character
                if (worldDeltaPosition.magnitude > agent.radius)
                    agent.nextPosition = transform.position + 0.9f*worldDeltaPosition;

각각의 경우에 따라 가장 적합한 방법은 다를 수 있습니다.

결론

지금까지 내비게이션 시스템을 사용하여 움직이고 그에 맞춘 애니메이션을 가지는 캐릭터를 설정해보았습니다. 블렌드 시간이나 바라보기 가중치를 조절해 보십시오. 캐릭터의 품질이 개선될 뿐만 아니라, 설정을 익히는 데에도 도움이 될 것입니다.

https://docs.unity3d.com/kr/2021.3/Manual/nav-CouplingAnimationAndNavigation.html

카메라 원리

Perspective와 Orthographic의 차이

 Camera 오브젝트의 Inspector 창에서 Projection의 두 가지 옵션이 있습니다. Percpective와 Orthographic이 있는데 Percpective는 사물에 대해 원근감과 공간감을 잘 표현하여서 보여주고, Orthographic은 사물에 대해서 원근감과 공간감 없이 표현을 해줍니다. 보통 2D나 2.5D를 제작할 시에는 Orthographic을 사용하여 제작합니다.

뷰 절두체 이해

절두체 는 피라미드 같은 모양의 윗부분을 밑면에 병렬로 잘라낸 입체 형상을 가리킵니다. 이는 원근(Perspective) 카메라에 의해 보여지고 렌더링되는 영역의 형상입니다.

원거리 절단면과 근거리 절단면은 모두 카메라의 XY 평면에 평행하게 위치하고 있으며, 만일 어떤 것이 근거리 절단면보다 카메라에 근접하거나 원거리 절단면보다 카메라에 멀리 떨어져있는 경우에는 렌더링되지 않습니다.

카메라에서 일정 거리 떨어진 절두체의 크기

카메라에서 일정 거리 떨어진 뷰 절두체의 교차 영역은 가시 영역을 구성하는 월드 공간에서 사각형으로 정의됩니다. 떨어진 거리를 알고 있으면 사각형의 크기를 계산할 수 있고, 사각형의 크기를 알고 있으면 떨어진 거리를 계산할 수 있기 때문에, 이를 유용하게 활용할 수 있습니다. 예를 들어, 움직이는 카메라가 항상 플레이어와 같은 특정 오브젝트를 샷 안에 계속 온전하게 담아내야 할 때, 오브젝트가 잘리지 않도록 카메라의 적정 거리를 유지할 수 있습니다.

일정 거리만큼 떨어진 절두체의 높이(두 값 모두 월드 단위)는 다음 공식을 통해 구할 수 있습니다.

 var frustumHeight = 2.0f * distance * Mathf.Tan(camera.fieldOfView * 0.5f * Mathf.Deg2Rad);

또한 이 과정을 반대로 하면 특정 절두체 높이일 때의 거리를 계산할 수 있습니다.

 var distance = frustumHeight * 0.5f / Mathf.Tan(camera.fieldOfView * 0.5f * Mathf.Deg2Rad);

거리와 높이를 모두 알고 있을 때에는 FOV 각도를 계산할 수도 있습니다.

 var camera.fieldOfView = 2.0f * Mathf.Atan(frustumHeight * 0.5f / distance) * Mathf.Rad2Deg;

각 계산식의 결과를 얻으려면 절두체의 높이를 알아야 하며, 절두체의 높이는 절두체의 너비를 이용하여 쉽게 구할 수 있습니다(절두체의 높이를 이용하여 너비를 계산할 수도 있음).

var frustumWidth = frustumHeight * camera.aspect;
var frustumHeight = frustumWidth / camera.aspect;

카메라에서 나오는 레이

 Ray ray = new Ray(transform.position, transform.forward);

카메라의 뷰에서 모든 점은 월드 공간의 하나의 선에 대응됩니다. 때로는 그 선의 수학적인 표현을 사용하는 것이 편리한 경우가 있으며 Unity는 이것을 레이(Ray) 오브젝트로 제공할 수 있습니다. 레이는 항상 뷰 내의 한 점에 부합하므로 Camera 클래스는 ScreenPointToRay 및 ViewportPointToRay 함수를 제공합니다. 이 둘의 차이는 ScreenPointToRay가 점을 픽셀 좌표를 필요로 하는 반면 ViewportPointToRay는 0..1(뷰에서 0이 왼쪽 또는 아래쪽 1이 오른쪽 또는 위쪽) 범위의 정규화된 좌표를 요구한다는 점입니다. 이 각각의 함수는 원점과 원점으로부터 나가는 선의 방향을 나타내는 벡터로 구성된 레이의 값을 반환합니다. 레이는 카메라의 transform.position 포인트 대​​신 근접 클리핑 평면을 기점으로 하고 있습니다.

레이캐스팅(Raycasting)

카메라를 통한 레이의 가장 일반적인 사용 방법은 씬에 Raycast를 실행하는 것입니다. 레이캐스트는 가상의 “레이저 빔”을 원점에서부터 레이에 따라 씬 안의 콜라이더에 충돌할 때까지 보냅니다. 그 다음 오브젝트와 RaycastHit 오브젝트의 충돌된 점에 대한 정보를 반환합니다. 이것은 스크린상 나타난 이미지를 기반하여 오브젝트가 어디에 위치하는지 찾는 유용한 방법입니다. 예를 들어, 마우스 포지션에 있는 오브젝트는 다음 코드로 확인할 수 있습니다.

using UnityEngine;
using System.Collections;

public class ExampleScript : MonoBehaviour {
    public Camera camera;

    void Start(){
        RaycastHit hit;  //충돌정보를 받아오는 변수
        Ray ray = camera.ScreenPointToRay(Input.mousePosition);  //레어저벡터
        
        if (Physics.Raycast(ray, out hit)) { //레이저를 쏨
            Transform objectHit = hit.transform;
            
            // Do something with the object that was hit by the raycast.
        }
    }
}

레이를 따라 카메라 이동

때로는 화면의 한 포지션에 반응하는 레이를 설정하고 카메라를 레이에 따라 이동시키는 것이 유용할 때가 있습니다. 예를 들어, 사용자가 오브젝트를 마우스로 선택하여 동일한 화면 위치를 “고정”하면서 줌인할 경우가 있습니다(이것은 카메라가 전술 지도를 볼 때 유용할 수 있습니다). 이 작업을 위한 코드는 매우 간단합니다.

using UnityEngine;
using System.Collections;

public class ExampleScript : MonoBehaviour {
    public bool zooming;
    public float zoomSpeed;
    public Camera camera;

    void Update() {
        if (zooming) {
            Ray ray = camera.ScreenPointToRay(Input.mousePosition);
            float zoomDistance = zoomSpeed * Input.GetAxis("Vertical") * Time.deltaTime;
            camera.transform.Translate(ray.direction * zoomDistance, Space.World);
        }
    }
}

마우스를 움직여서 2D 오브젝트를 움직여 보겠다 실험을 위해 2D 프로젝트를 만든뒤 2D Sprite Circle을 하나 만들고 포지션을 리셋한다. 나중에 아시겠지만 마우스는 게임오브젝트가 투영되는 스크린의  해상도와 카메라의 Z좌표를 갖는다.

그런데 게임오브젝트는 각자의 좌표가 있고 씬뷰에 보이는 범위는 카메라에 의존한다. 따라서 마우스의 좌표를 게임오브젝트에 적용하기 위해서는 2좌표간의 차이를 알고 변환해 줘야한다.

그다음 ScreenToWorld라는 스크립트를 다음과 같이 붙여준다. 무척 직관적이다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ScreenToWorld : MonoBehaviour
{
    public Vector2 mousePosition;

    // Update is called once per frame
    void Update()
    {
        mousePosition = Input.mousePosition;
        transform.position = mousePosition;
    }
}

실행히보면 원이 없어진다. 원인을 찾아보자.  

유니티 2D 기본스크린 화면이다. 객체포지션은 리셋하면  (0,0,0)인데 스크린 범위를 보기위해 (5,4,-10)으로 카메라 Z위치와 맞추었다.

하이라키뷰의 Circle을 클릭하고 Inspector를 보면 포지션이  각자 다르겠지만 마우스좌표는 스크린 좌표라 x:0~1980 y:0~1080,인데 이게 월드봐표 x:±8.8ㄹ y:±5f를 넘어서면 안보이게 된다. 

스크립트에 mousPosition을 Public으로 했기 때문에 마우스를 움직이면 좌표값을 확인할 수 있다.

마우스를 왼쪽아래로 잘 몰아보면 0에 가까워지면서 Circle이 보이게 된다.

문제는 Input.mousePosition과 transform.position과의 차이 때문이다. 왼쪽이 마우스좌표 오른쪽이 transform.position이다

두 시스템의 숫자차이도 문제지만 스크린은 (0,0)점이 좌하이고 월드좌표는 가운데다 따라서 offset(1920/2,1080/2)를 생각해야한다. 월드좌표는 현재 아래와 같고 만일 카메라의 위치 회전에 따라 변화할수 있다.

문제를 알았으니 다음 스크립트를 넣고 다시한번 해보자.

유니티는 모니트의 화면사이즈를 Screen.width, Screen.height로 얻을 수 있고 camera world의 높이를 Camera.main.orthographiSize로 얻을수 있어 이걸 화면비를 곱하면 폭도 얻을 수 있다.

실험을 위해 public변수를 많이 만들었다. 마우스를 움직이면서 봐주길 바란다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ScreenToWorld : MonoBehaviour
{
    public Vector2 mPos;  //마우스 좌표
    public float mWidth;  //마우스 스크린 폭
    public float mHeight;  //마우스 스크록 높이
    public float wWidth;  
    public float wHeight;
    public float xscale,yscale;

    // Update is called once per frame
    private void Start() {
        mWidth = Screen.width;  //좌측에서 우측까지의 사이즈
        mHeight= Screen.height;  //아래서 위까지의 사이즈
        
        wWidth = Camera.main.orthographicSize * mWidth / mHeight;  //중앙에서 오른쪽까지 화면의 반
        wHeight = Camera.main.orthographicSize;  //중앙에서 위까지의 화면의 반
        yscale = wHeight *2 / Screen.height;
        xscale = wWidth *2 / Screen.width;
    }
    void Update()
    {
        mPos = Input.mousePosition;
        transform.position = MouseToWorld(mPos);
    }
    Vector2 MouseToWorld(Vector2 mPos) {
        return new Vector2((mPos.x - Screen.width/2) * xscale, (mPos.y- Screen.height / 2) * yscale);
    }
}

위 방법은 카메라가 월드좌표의 (0,0,0)을 바라 보고 있을 경우만 잘동작하고 그렇지 않은 경우 잘 안될것이다. 좀더 섬세한 계산이 필요할 것다. 

그런데 유니티가 이럴줄 알고  스크린좌표를 월드좌표를 마련해주었다. 잘보면 Vector2를 사용한다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ScreenToWorld : MonoBehaviour
{
    Vector2 worldPosition;
    Vector2 mousePosition;

    // Update is called once per frame
    void Update()
    {
        Screen2World();
        transform.position = worldPosition;
    }
    void Screen2World() {
        mousePosition = Input.mousePosition;
        worldPosition = Camera.main.ScreenToWorldPoint(mousePosition);
    }
}

Vector3를 사용하면 Input.mousePosition의 리턴값의 Z좌표가 카메라의 Z좌표 -10되면서 카메라가 자기와 같은 평면의 Circle을 못보게 된다. 자기눈과 같은 평면에 걸 볼수가 없다. Vector2에서는 Z정보를 전달안하기 때문에 이런 문제가 안 일어 났던거다. 따라서 변환된 world좌표에 게임객체의z좌표를 카피해 주면 간단히 끝난다. 이외에도 방법은 여러가지 생각해보시길

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ScreenToWorld : MonoBehaviour
{
    Vector3 worldPosition;
    Vector3 mousePosition;

    // Update is called once per frame
    void Update()
    {
        Screen2World();
        transform.position = worldPosition;
    }
    void Screen2World() {
        mousePosition = Input.mousePosition;
        worldPosition = Camera.main.ScreenToWorldPoint(mousePosition);
        worldPosition.z = transform.position.z; 
        Debug.Log(mousePosition+ " " + worldPosition);
    }
}

Unity에서는 오일러 각과 쿼터니언을 모두 사용하여 회전과 방향을 나타낼 수 있습니다. 표현은 둘 다 동일하지만 용도와 제한 사항은 서로 다릅니다.

보통 씬에서는 방향을 오일러 각으로 표시하는 트랜스폼 컴포넌트를 사용하여 오브젝트를 회전합니다. 그러나 Unity는 회전과 방향을 내부적으로 쿼터니언으로 저장하므로 짐벌 락으로 이어질 수도 있는 더 복잡한 모션에 유용할 수 있습니다.

오일러 각

트랜스폼 좌표에서 Unity는 벡터 프로퍼티 Transform.eulerAngles X, Y, Z를 사용하여 회전을 표시합니다. 노멀 벡터와는 달리 이 값은 X, Y, Z 축에 대한 실제 회전 각도(단위: 도)를 나타냅니다.

오일러 각 회전은 3개의 축을 중심으로 3개의 개별 회전을 수행합니다. Unity는 Z축, X축, Y축을 중심으로 오일러 회전을 순차적으로 수행합니다. 이 회전 방법은 외부 회전입니다. 회전하는 동안 원래 좌표계가 변경되지 않습니다.

게임 오브젝트를 회전하려면 각 축이 트랜스폼 컴포넌트로 회전할 각의 크기를 입력할 수 있습니다. 스크립트로 게임 오브젝트를 회전하려면 Transform.eulerAngles를 사용합니다. 오일러 각으로 변환하여 계산하고 회전하려면 짐벌 락 문제가 발생할 위험이 있습니다.

짐벌 락

3D 공간에 있는 오브젝트가 자유도를 잃고 2차원 내에서만 회전할 수 있는 경우를 짐벌 락이라고 합니다. 두 축이 평행하면 오일러 각으로 짐벌 락이 발생할 수 있습니다. 스크립트에서 회전 값을 오일러 각으로 변환하지 않으면 쿼터니언을 사용하여 짐벌 락을 방지해야 합니다.

짐벌 락 문제가 있는 경우 Transform.RotateAround를 사용하면 오일러 각을 피할 수 있습니다. 각 축에 Quaternion.AngleAxis를 사용하여 함께 곱할 수도 있습니다(쿼터니언 곱셈은 각 회전에 차례로 적용됩니다).

쿼터니언

쿼터니언은 3D 공간에서 공간 방향과 회전의 고유한 표현을 위한 수학적 표기법을 제공합니다. 쿼터니언은 4개의 숫자를 사용하여 3D에서 단위 축을 중심으로 회전 방향과 각도를 인코딩합니다. 이 4개의 값은 각이나 각의 크기가 아닌 복소수입니다. 자세한 내용은 쿼터니언의 수학을 참조하십시오.

쿼터니언 회전은 계산에 있어 효율적이고 안정적이기 때문에 Unity는 회전 값을 쿼터니언으로 변환하여 저장합니다. 단일 쿼터니언은 축에 대해 360도보다 큰 회전을 나타낼 수 없기 때문에 에디터에서는 회전을 쿼터니언으로 표시하지 않습니다.

Quaternion 클래스를 사용하면 쿼터니언을 직접 사용할 수 있습니다. 회전에 스크립트를 사용하는 경우 Quaternion 클래스와 함수를 사용하여 회전 값을 만들고 변경할 수 있습니다. 회전에 오일러 각으로 값을 적용할 수 있지만 문제를 방지하기 위해 쿼터니언으로 저장해야 합니다.

오일러 각과 쿼터니언 간의 전환

다음 스크립트를 사용하여 쿼터니언과 오일러 각 간을 변환하고 원하는 방식으로 회전을 보고 편집할 수 있습니다.

• Quaternion.Euler 함수를 사용하여 오일러 각도에서 쿼터니언으로 변환할 수 있습니다.
• Quaternion.eulerAngles 함수를 사용하여 쿼터니언을 오일러 각으로 변환할 수 있습니다.

중요 클래스 - Quaternion

Unity는 Quaternion 클래스를 사용하여 게임 오브젝트의 3차원 방향을 저장하고, 이를 통해 한 방향에서 다른 방향으로의 상대 회전을 설명합니다.

이 페이지는 Quaternion 클래스의 개요, 그리고 이 클래스를 사용하는 스크립팅의 일반적인 용도에 대해 설명합니다. Quaternion 클래스의 모든 멤버에 대한 전체 레퍼런스는 Quaternion 스크립트 레퍼런스를 참조하십시오.

오일러 각(게임 오브젝트의 회전을 위해 인스펙터에 표시되는 X, Y, Z 값)과 Unity가 게임 오브젝트의 실제 회전을 저장하는 데 사용하는 기본 쿼터니언 값 간의 차이를 이해하고 있어야 합니다. 이 항목에 대한 기본 정보는 Unity의 회전 및 방향을 참조하십시오.

스크립트에서 회전 처리를 다루는 경우 Quaternion 클래스와 이 클래스의 함수를 사용하여 회전 값을 만들고 수정해야 합니다. 오일러 각을 사용할 수 있는 상황도 있지만, 다음 사항을 염두에 둬야 합니다. - 오일러 각을 처리하는 Quaternion 클래스 함수를 사용해야 합니다. - 회전의 오일러 값을 검색 및 수정하고 다시 적용하면 의도하지 않은 부작용이 발생할 수 있습니다(아래 참조).

쿼터니언 직접 생성 및 조정

Unity Quaternion 클래스의 여러 함수를 통해 오일러 각을 전혀 사용하지 않고도 회전을 만들고 조정할 수 있으며, 대부분의 일반적인 경우 이러한 함수들을 사용해야 합니다. 각각의 함수는 코드 샘플이 있는 스크립트 레퍼런스에 연결됩니다.

회전 생성:

• Quaternion.LookRotation
• Quaternion.Angle
• Quaternion.AngleAxis
• Quaternion.FromToRotation

회전 조작:

• Quaternion.Slerp
• Quaternion.Inverse
• Quaternion.RotateTowards

Transform 클래스도 쿼터니언 회전에 사용할 수 있는 다음의 메서드를 제공합니다.

• Transform.Rotate 및 Transform.RotateAround

오일러 각 사용

일부의 경우 스크립트에서 오일러 각을 사용하는 것이 더 좋습니다. 이 경우 각을 변수로 유지하고 회전에 오일러 각으로 적용하는 데만 사용해야 하고, 궁극적으로 쿼터니언으로 저장되어야 합니다. 오일러 각을 쿼터니언에서 검색해서 가져올 수 있지만, 검색해서 가져온 후 수정하고 다시 적용하면 문제가 발생할 수 있습니다.

이러한 문제가 정확히 어떻게 발생하는지에 대한 자세한 내용은 eulerAngles 스크립트 레퍼런스 페이지를 참조하십시오.

아래에는 흔히 발생하는 잘못된 방법에 대한 몇 개의 예제가 있습니다. 설명을 위해 X축을 중심으로 게임 오브젝트를 초당 10도씩 회전시키려는 가상의 예제를 사용합니다. 다음 2코드는 잘못된 방법입니다.

// rotation scripting mistake #1
// the mistake here is that we are modifying the x value of a quaternion
// this value does not represent an angle, and does not produce desired results
    
void Update () 
{
    var rot = transform.rotation;
    rot.x += Time.deltaTime * 10;
    transform.rotation = rot;
}

// rotation scripting mistake #2
// Read, modify, then write the Euler values from a Quaternion.
// Because these values are calculated from a Quaternion,
// each new rotation might return very different Euler angles, which might suffer from gimbal lock.
        
void Update () 
{
    var angles = transform.rotation.eulerAngles;
    angles.x += Time.deltaTime * 10;
    transform.rotation = Quaternion.Euler(angles);
}

그리고 다음은 스크립트에서 오일러 각을 올바르게 사용하는 예입니다.

// Rotation scripting with Euler angles correctly.
// Store the Euler angle in a class variable, and only use it to
// apply it as an Euler angle, but never rely on reading the Euler back.
        
float x;
void Update () 
{
    x += Time.deltaTime * 10;
    transform.rotation = Quaternion.Euler(x,0,0);
}

오일러각과 쿼터니언각의 차이

새로운 씬을 하나 만들고 Models>Player폴더의 Player를 끌어다 놓습니다. (Prefab은 이미 다른 스크립트가 들어 있어 안됩니다.) 이 강좌가 처음이 신분들은 아무 게임오브젝트를 만들어 놓습니다.

아래 스크립트를 끌어다 적용합니다.

using UnityEngine;
public class ExampleScript : MonoBehaviour {
    float rotationSpeed = 45;
    Vector3 currentEulerAngles;
    Quaternion currentRotation;
    float x;
    float y;
    float z;

    void Update() {
        if (Input.GetKeyDown(KeyCode.Alpha1)) x = 1 - x;
        if (Input.GetKeyDown(KeyCode.Alpha2)) y = 1 - y;
        if (Input.GetKeyDown(KeyCode.Alpha3)) z = 1 - z;
        if(Input.GetKeyDown(KeyCode.Alpha0)) {
            x = 0; y = 0; z = 0;
            currentEulerAngles = Vector3.zero;
        }

        //modifying the Vector3, based on input multiplied by speed and time
        currentEulerAngles += new Vector3(x, y, z) * Time.deltaTime * rotationSpeed;

        //moving the value of the Vector3 into Quanternion.eulerAngle format
        currentRotation.eulerAngles = currentEulerAngles;

        //apply the Quaternion.eulerAngles change to the gameObject
        transform.rotation = currentRotation;
    }

    void OnGUI() {
        GUIStyle style = new GUIStyle();
        style.fontSize = 24;
        // Use eulerAngles to show the euler angles of the quaternion stored in Transform.Rotation
        GUI.Label(new Rect(10, 0, 0, 0), "Rotating on X:" + x + " Y:" + y + " Z:" + z, style);

        //outputs the Quanternion.eulerAngles value
        GUI.Label(new Rect(10, 25, 0, 0), "CurrentEulerAngles: " + currentEulerAngles, style);

        //outputs the transform.eulerAngles of the GameObject
        GUI.Label(new Rect(10, 50, 0, 0), "GameObject World Euler Angles: " + transform.eulerAngles, style);
    }
}

1,2,3을 누르면 해당되는 x,y,z축으로 무한히 회전합니다.

0을 누르면 초기화 됩니다.

Play시켜보면 오일러나 GameObject World Euler Angle 둘 다 (0,0,0)입니다.

처음 1만 눌러 90도 전에 다시 1을 눌러 세워 보겠습니다. 아직 2개의 값은 비슷합니다.

다시1을 눌러 90도가 넘은면 1을 눌러 세워 봅니다. World Euler Angles.x가 줄어들고 y,z가 180됩니다.

일단 1,2,3을 토글하면서 오일러값과 쿼터니언의 값 변화를 보세요 쿼터니언값의 변화는 상식적이지 않습니다. 연속적인 회전이 안됩니다. 

0을 눌러 초기화 합니다

우선 1만 눌러 적당히 90을 만들어 아래로 눕게 합니다. 그다음 2,나 3을 눌러보면 둘다 Y축으로 돌아가는데 하나는 반대로 돌아갑니다. 

이게 짐벌록입니다.  x축을 90돌면서 차일드인 Z축이 같이 돌아 Y축과 겹쳐졌기 때문입니다.  

다른 축으로도 실험해보왔지만 일어나지 않습니다. 이건 유니티의 x,y,z계산 우선순위때문인듯 합니다. 

재미있는건 1을 눌러 90도쯤 변화시켜 눕힌후 2를 눌러 y축을 회전시킨후 3을 누르면 각도는 열심히 변하는데 실제 게임오브젝트는 멈춰있습니다 y축과 z축의 방향이 서로 반대라 합쳐서 0이 되기 때문입니다. 꼭해보시기 바랍니다. 희안합니다.

사진으로 간단하게 설명하겠다.

우선 다음 사진과 같이 x, y ,z 축을 가진 오브젝트가 있다고 해보자.

저 화살표가 가리키는 방향을 계속 유의하자. 이 오브젝트의 x(빨간축) 축을 90도 회전시켜보겠다.

x축(빨간축)으로 90도 회전시킨 모습이다.  화살표를 보면 오른쪽 방향을 가리키고 있다. 

여기까지는 문제가 없다. 

자, 그다음 Y축(초록색)으로 90도 회전시켜보겠다.

Y축으로 90도 회전시키니 다음과 같은 모습이 된다.

Z 축과 X 축이 한축으로 합쳐지면서 한축에 대한 계산이 불가능해집니다.

이러한 현상을 바로 '짐벌락(Gimbal-lock)' 이라고 한다. 

이러한 짐벌락 현상이 생기는 이유는 오일러 앵글이 자체적으로 설정되어있는 순서로 해당 축들을 개별적으로 계산하기 때문이다.

Unity에서는 오일러 앵글이 X, Y, Z 순서로 계산된다.

세 개의 축을 동시에 계산하지 않고 각 축을 독립적으로 판단하기에 다음과 같이 어쩌다가 겹쳐버리는 현상이 발생하는 것이다.  이렇게 축이 겹쳐버리면 한 축에 대해서는 계산이 불가능하기에, 정확한 각도 계산이 불가능하다.

Unity로 2D 게임을 제작할 때는 오일러 각으로도 각도 구현에 문제가 없지만, 모든 각도를 통제해줘야 하는 3D 게임 같은 경우에는 오일러 앵글만으로는 구현에 한계가 있다. 

오일러 각의 이러한 문제를 해결하기 위해 나온 것이 바로 쿼터니언(Quaternion)이다. 

쿼터니언(Quaternion)

쿼터니언은 각 축을 한꺼번에 계산하기 때문에 짐벌락 문제가 발생하지 않는다.

Euler angle 과는 다르게 쿼터니언은 4개의 성분(x, y, z, w)으로 이루어져 있다. 

해당 성분은 벡터(x, y, z)와 스칼라(w)를 의미한다.

쿼터니언은 내부가 수학적으로 복잡하게 구현되어있어 이를 제대로 이해하지 못한다면 자유자재로 다루기는 상당히 까다롭다.

쿼터니언은 방향(orientation)과 회전(rotation) 둘을 다 표현할 수 있다.

하지만 쿼터니언의 회전은 한 orientation 에서 다른 orientation 으로 측정하기에 180 보다 큰 값을 표현할 수 없다는 단점이 있다. 

이 점이 쿼터니언을 직관적으로 이해할 수 없는 큰 이유 중 하나이다.

다행히 유니티에는 이러한 쿼터니언을 간단하게 사용 가능하도록 만들어진 함수들이 다양하게 존재한다.

유니티 공식 문서에도 쿼터니언은 쓰기 어려우니 자기들이 만든 함수를 사용하도록 권장한다.

쿼터니언을 다루기 위해 사용되는 대표적인 함수들의 사용법을 정리해봤다. 

Quaternion.Euler

public static Quaternion Euler(float x, float y, float z);

유니티에서는 Quaternion.Euler 함수를 통해서 오일러각을 쿼터니언으로 변경시켜 사용한다.

해당 함수 인자에 오일러각을 넣으면 쿼터니언으로 변환된 값을 반환시켜준다. 

Euler 함수 사용법

transform.roation = Quaternion.Euler(new Vector3(120,60,100)); 

float x; 
void Update () 
{ 
	x += Time.deltaTime * 10; 
	transform.rotation = Quaternion.Euler(x,0,0); 
}

Quaternion.LookRotation

public static Quaternion LookRotation(Vector3 forward, Vector3 upwards = Vector3.up);

두 번째 인자인 upwards upwards는 Vector3.up 으로 디폴트 인자가 세팅되어 있다.

첫 번째 인자에  방향벡터를 입력하면 해당 자기 위치기준에서의 해당 방향벡터를 바라보게 된다.

어떠한 타겟을 향해 회전시키고 싶다면 다음과 같이 사용하면 된다.

Vector3 direction = (traget.position - this.transform.position).normalized;
Quaternion lookRotation = Quaternion.LookRotation(direction);
this.transform.rotation = lookRotation;

Quaternion.Slerp

public static Quaternion Slerp(Quaternion a, Quaternion b, float t);

/from/과 /to/사이를 /t/로 구형보간 합니다.

Quaternion.Slerp 함수는 두 쿼터니언의 중간값을 리턴 시켜준다.

Slerp 함수를 사용할 때 종종 세 번째 인자인 t 값에 대하여 헷갈리는데,

Slerp 함수는 lerp 함수에서 쓰이는 선형보간법이 아닌 구면선형보간법 기반으로 되있다는 점을 명심해야한다.

Lerp 함수와 Slerp 함수는 세 번째 인자에 따른 반환값이 다르다.

Slerp를사용하고 싶다면 선형보간법과 구면선형보간법의 차이를 숙지해야 원하는 각도 변환을 연출할 수 있을 것이다.

Lerp, Slerp 차이.

Lerp와 Slerp의 차이를 간단하게 그림으로 나타내면 다음과 같다. 

초록점에서 빨간 점으로 이동할 때 Lerp는 직선으로 Slerp는 곡선으로 보간 된다.

transform.rotation = Quaternion.Slerp(A.transform.rotation, B.transform.rotation, Time.deltaTime);

Quaternion.FromToRotation

public static Quaternion FromToRotation(Vector3 fromDirection, Vector3 toDirection);

/fromDirection/에서 /toDirection/으로 회전한 rotation을 생성합니다.

FromToRotaion 함수는 fromDirection 의 방향벡터를 toDirection 으로 회전한 쿼터니언을 반환한다.

rotation(0,0,0)

rotation 값이 (0,0,0)인인 큐브이다.

transform.rotation = Quaternion.FromToRotation(Vector3.up, Vector3.right);

다음 함수를 적용 시키면

큐브의 up vector(초록색 화살표)가 옆으로 꺽여있다.

카메라 위치 때문에 반대로 보이지만 큐브가 오른쪽으로 90도 회전한 모습이다.

FromToRotation 함수는 중심축을 첫 번째 인자로 넣고 회전하고 싶은 방향벡터를 두 번째 인자로 넣어서 사용하면 될듯싶다.

참조 : 유니티매뉴얼 ,  https://hub1234.tistory.com/21

public struct Vector3 :IEquatable<Vector3>, IFormattable{
    public float x;
    public float y;
    public float z;
    public static Vector3 right {get;}
    public static Vector3 left {get;}
    public static Vector3 up {get;}
    public static Vector3 down {get;}
    public static Vector3 foward {get;}
    public static Vector3 back {get;}
}

정적 변수

변수

생성자

Public 함수

Static 함수

옆

프로젝트창에서 우클릭하고 Create>Script를 하면 스크립트가 하나만들어지고 이름을 Empty라고 바꿔보자.

바꾼 이름인 Empty  class가 자동으로 만들어진다. 유니티는 스크립트 언어로 c#을 사용한다.

나중에 이 스크립트를 카피할때 조심해야 한다 복사한 파일의 이름을 변경해도 내부의 클래스 이름은 안 바뀌기 때문이다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Empty : MonoBehaviour
{
    // Start is called before the first frame update
    void Start()
    {
        
    }

    // Update is called once per frame
    void Update()
    {
        
    }
}

Empty class는 Start()와 Update() 2개의 함수를 갖고 있다. 

사실 class Empty는 MonoBehaviour class에서 상속되어졌기에 아래와 같이 다양한 콜백함수들이 라이프싸이클을 갖고 실행된다. Empty라는 클래스가 생성되면서 파괴될때까지의 과정이라고 보면 된다. 프로그래밍을 위해서는 라이프싸이클을 이해할 필요가 있다.

1. 모노 (Mono)

.Net은 마이크로 소프트(MicroSoft)에서 C언어에 자바의 장점을 수용하여 개발한 MS Windows 프로그램 개발 및 실행 환경이자 언어이다.

네트워크와 UI 등의 많은 작업을 캡슐화 하여 코딩의 효율성을 극대화 한 .Net 의 강력한 기능을 사용하기 위해서는 .Net 프레임워크가 설치 된 윈도우 환경이 있어야 했다.

이에 윈도우가 아닌 다른 플랫폼에서 .Net 프레임워크를 사용하기 위해 개발된 것이 얼마 전 MS에서 인수한 자마린(Xamarin) 사의 Mono 이다.

Mono 는 .Net 프레임워크(framework) 의 오픈소스 개발 플랫폼으로서 크로스플랫폼(Cross-platform) 어플리케이션의 개발을 지원하며 C#과 CLI (Common Language Infrastructure) 에 기반을 두고 있다.

Mono 를 활용한 대표적인 크로스플랫폼 개발 도구가 유니티와 자마린 이다.

현재 유니티에서 사용하는 Mono 의 .Net 컴파일러에서 지원하는 .Net 버전은 4.x 로 C# 7까지 사용할 수 있다고 한다.

2. 스크립트 언어 (Script Langauge)

하나 이상의 어플리케이션 에서 스크립트(script)를 지원하는 프로그래밍의 부분 집합(subset)이다.

스크립트는 흔히 어플리케이션의 코어 코드와는 별개의 언어로서 최종 사용자에 의해 작성되거나 최소한으로 수정되는 프로그램이다.  스크립트는 대개 소스코드나 바이트코드로 부터 해석되며 이는 어플리케이션이 기계어나 중간언어로 컴파일되는 것과 차별화 된다.  그런면에서 스크립트 언어인지 아닌지를 결정하는 것은 언어 그 자체가 아니라 그 언어가 사용되는 환경이다.

3. Unity 의 Behaviour Script

유니티에서 하나의 스크립트는 그 자체로 하나의 클래스(Class)를 뜻한다.

클래스란 속성(Properties), 메서드(Method) 들을 하나의 객체로 묶은 데이터 타입이다.

유니티에서 하나의 스크립트는 각각 속성(Properties), 변수(Variables), 명령(Instructions) 또는 기능(Functions)을 가지며 사용자는 원하는 순간에 해당 스크립트를 호출 할 수 있다.

모든 스크립트는 또한 Behaviour Component 이다.

Behaviour 는 활성화(Enable), 비활성화(Disable) 할 수 있는 Component 이다.

즉, Behaviour는 껐다켰다 할 수 있는 동작(behaviour) 이며, 이는 캐릭터의 동작이 될 수도 있고, 환경이 될 수도 있고, 게임 내 흐름을 제어하는 프로그램 자체가 될 수도 있다.

* Component 란? GameObject 에 부착되는(Attached) 모든 것들이 상속받는 기반 클래스.

4. MonoBehaviour

MonoBehaviour 는 Unity 의 모든 스크립트가 상속받는 클래스이다.

사용자가 Unity 엔진의 작동 방식을 이해하지 못하더라도 코드를 작성할 수 있도록 미리 만들어 둔(built-in) Behaviour 클래스 이자 스크립트 명령(scripting instruction) 들의 집합이다.

덕분에 모든 스크립트는 유니티 엔진에 의해 호출(invoke) 되는 콜백(callback) 함수들을 이용할 수 있게 된다.

이 콜백 함수들은 Reset, Awake, Start, Update, OnGUI, OnDestroy 등 유니티를 사용하면서 수없이 사용하게 된다.

5. MonoBehaviour 의 생명주기(Lifecycle)

유니티의 공식 매뉴얼을 보면 위와 같이 MonoBehaviour 의 수많은 콜백함수 종류와 각각이 호출 되는 시점을 알 수 있다.

이 중 개발 과정에서 실제 자주 이용하게 되는 콜백들의 라이프사이클을 살펴보자.

Reset : 유니티 에디터에서 오브젝트 생성 후 인스펙터 뷰에서 리셋을 눌러줄 때 실행된다.

          객체의 속성을 초기 값으로 설정해 줄 때 사용한다.

Awake : 프리팹이 인스턴스화 한 직후, 스크립트가 호출되자마자 오브젝트 활성화 여부와 상관없이 실행 된다.

           모든 오브젝트가 초기화 된 후 호출되기 때문에 GameObject.Find 같은 명령문을 안전하게 사용할 수 있다.                 Awake 함수는 언제나 Start 함수 전에 호출되는 점에 주의. (StartCoroutine 을 사용할 수 없다.)

OnEnable : 다른 초기화 함수와 달리 하나의 라이프 사이클 내에서 여러번 호출 될 수 있다.

                인스펙터뷰에서 체크 및 스크립트 내에서 SetActive 함수로 게임 오브젝트를 활성화 할 때마다 호출 된다.

Start : Update 함수가 호출되기 전에 한번만 호출된다.

         다른 스크립트의 모든 Awake가 모두 실행된 이후에 실행되며 Awake와 달리 오브젝트가 활성화 되어 있어야 호출 된다.

         Awake 이후 호출되므로 예를들어 A 객체의 Awake 함수에서 동적 생성한 멤버를 B객체의 Awake 함수에서 접근할 경우 오브젝트 들의 Awake 함수 호출 순서는 임의로 정할 수 없으므로 B객체의 Awake 가 먼저 호출 되어 NullReferenceExecption 을 발생 시킬 수 있다.

         이럴 경우 동적 생성은 Awake 에서 하고 동적 생성되는 멤버에 접근하는 초기화 코드는 항상 Awake 이후로 보장되는 Start 에 넣는 것이 좋다. 

FixedUpdate : 프레임과 상관없이 무조건 시간 기준(default 0.02초. 변경 가능)으로 호출 되는 Update 콜백이기 때문에 주로 물리 엔진을 사용하는 경우 일정 시간 간격으로 힘을 가하거나 체크할 때 사용한다.

                   프레임 속도가 기준 시간 속도보다 오래 걸릴 정도로 느려질 경우 한 프레임에서 여러번 호출 될 수 있다.

Update : 매 프레임마다 호출되는 가장 일반적인 Update 함수.

             오브젝트가 활성화 되어 있어야 호출 되며 프레임 단위이기에 호출 시간 간격은 프레임에 따라 변한다.

LateUpdate : 모든 Update 계열 콜백들이 실행되고 나서 호출된다.

                  Update 함수에서 캐릭터를 이동 시킨 후 LastUpdate에서 캐릭터의 좌표를 추적해 카메라의 좌표를 이동시키는 등의 경우에 사용한다.

OnDisable : 게임 오브젝트 또는 스크립트가 비 활성화 되었을 때 호출된다. (StartCoroutine 사용 불가)

OnDestroy : 해당 오브젝트가 파괴 되기 전 프레임의 Update 함수 실행 후 호출 된다.

                 일반적으로 라이프 사이클 내에서 사용한 자원들을 돌려 놓는 작업을 이곳에서 하게 된다.

OnApplicationQuit :  앱이 종료 되기 직전에 모든 오브젝트에서 호출된다.

                             에디터에서는 플레이 모드 중지할 때 호출 된다.

6. MonoBehaviour 의 특징

MonoBehaviour 를 상속받은 스크립트 파일은 그 자체로 사용할 수 없다.

GameObject 에 Component 형태로 등록되어 있어야 한다.

즉, 게임 내에서 사용할 GameManager.cs 라는 스크립트 파일을 만들었다면 해당 클래스를 적용할 빈 GameObject를

Unity의 Hierarchy 에서 추가한 후 Inspector 창에 이 스크립트 파일을 등록한다.

그리고 코드에서 해당 GameManager 클래스를 가져오려면 위에서 추가한 GameObject 객체에 GetComponent<GameManager>(); 형태로 가져와야 한다는 뜻이다.

또한 가장 중요한 특징 중 하나는 MonoBehaviour 를 상속받은 클래스는 new 로 동적 할당할 수 없다.

이 경우,

1. GamObject.Instantiate 함수를 통해 해당 스크립트가 Component 로 추가된 오브젝트의 인스턴스를 생성

2. 기존 생성된 GameObject 객체에 AddComponent<GameManager>();

하여 사용할 수 있다.

MonoBehaviour 의 다양한 콜백 함수는 필요할 경우 오버라이딩 해서 사용하면 된다.

하지만 오버라이딩 해놓고 해당 함수 안에서 아무것도 하지 않고 비워두면 어떻게 될까?

컴파일 과정에서 이런 경우 함수 호출을 제거해 주면 좋으련만 아쉽게도 내용이 있던 없던 무조건 호출을 진행 한다.

Awake 나 Start 같은 한번만 호출 되는 경우는 상대적으로 영향이 적겠지만 FixedUpdate 같은 경우 0.02초 마다 오브젝트 별로 각각 호출을 하게 되므로 퍼포먼스에 상당한 영향을 끼칠수 있다.

쓰지 않는 MonoBehaviour 함수는 꼭 삭제해 주자.

https://skuld2000.tistory.com/25

행동부품으로서의 스크립 번역해보면 어색하지만, 모든 스크립트는  Behaviour Component 이다.

Behaviour 는 활성화(Enable), 비활성화(Disable) 할 수 있는 Component 이다.

즉, Behaviour는 껐다켰다 할 수 있는 동작(behaviour) 이며, 이는 캐릭터의 동작이 될 수도 있고, 환경이 될 수도 있고, 게임 내 흐름을 제어하는 프로그램 자체가 될 수도 있다.

* Component 란? GameObject 에 부착되는(Attached) 모든 것들이 상속받는 기반 클래스.

아시다시피 유니티는 게임오브젝트에 다양한 부품을 추가할 수 있다. 

유니티는 Create Empty라는 게임오브젝트를 만들면 축만보이는 투명한 오브젝트가 만들어지고 오른쪽 Inspector창을 보면  Transform이외에 아무런 기능이 추가되여 있지 않다.

transform이라는 이동 회전 스케일을 처리하는 컴포넌트만 보인다. 이 transform이라는 컴포넌트는 제가불가능하다. 오른쪽 삼점을 눌러봐도 Delete 메뉴가 안보인다.

유니티는 게임오브젝트의 특성(생명)을 부여하기 위해 다양한 컴포넌트를 추가할 수 있는데 스크립트가 여러가지 부품중 하나로 취급된다는 거다. 부품이란 필요할때 추가되기도 하고 제거할 수도 있다.

결론은 스크립트 == 컴포넌트 라는 이야기