지혜공방(Wisdom Atelier)

요약: 이 페이지는 Feel에 포함된 다양한 데모를 다룹니다.

소개

Feel에는 피드백 및 기타 시스템을 사용하여 게임의 느낌을 향상시키고, 게임 전반에 걸쳐 더 나은 신호와 피드백을 구현하는 다양한 방법을 보여주는 여러 데모가 포함되어 있습니다. 대부분의 데모는 에셋의 루트에 있는 FeelDemos 폴더에서 찾을 수 있으며, MMFeedbacks 데모는 MMFeedbacks 폴더에, NiceVibrations 데모는 동일한 이름의 폴더에 있습니다. MMFeedbacks 데모의 경우, 씬에 피드백이 있는 루트 오브젝트와 없는 루트 오브젝트가 자주 있습니다. 이를 통해 동일한 상호작용을 플레이하고 Feel이 어떻게 향상시키는지 확인할 수 있습니다.

대부분의 MMTools는 데모가 없지만(아직은), 더 많은 데모가 곧 추가될 예정입니다. 현재 MMTools 데모 목록은 아래에서 확인할 수 있습니다. 특정 MMTools 기능에 대한 데모를 요청하려면 언제든지 연락 양식을 사용하세요!

특정 데모를 찾고 있다면, 프로젝트 패널 검색 창에 이름을 입력하여 항상 찾을 수 있다는 점을 참고하세요.

MMFeedbacks

MMF_PlayerDemo

이 데모는 가능한 한 많은 피드백을 보여줍니다. 왼쪽 목록에서 150개 이상의 피드백을 거의 모두 재생할 수 있습니다. "이 피드백은 어떻게 작동하나요?"라는 궁금증이 생길 때 좋은 참고 자료가 됩니다. 에디터에서 UI > Canvas > FeedbackScrollRect > ScrollRectContent 노드를 펼치면 긴 버튼 목록에 접근할 수 있습니다. 버튼을 펼치면 버튼을 눌렀을 때 재생되는 특정 MMF_Player가 포함된 MMF_Player 노드를 찾을 수 있습니다. 참고 자료로서 이러한 내용을 주저하지 말고 확인해보세요!

Feel

Snake

Snake의 완벽한 게임은 다양한 레벨에 피드백을 추가하는 방법을 참고할 수 있도록 제공됩니다. "실제" 클래스의 예시와 함께 제공됩니다. 이 매우 미니멀한 버전의 Snake에서는 한 방향으로만 회전할 수 있고, 패배할 수 없으며, 자신을 먹으면 몸의 일부를 잃습니다. Scripts 폴더에서 음식 생성과 뱀의 움직임을 처리하는 모든 스크립트와 가능한 모든 레벨에서 사용되는 피드백을 찾을 수 있습니다.

Barbarians

이 작은 씬은 전투 피드백과 데미지 텍스트에 중점을 둡니다. 단 2개의 스크립트로 구동됩니다:

• Barbarian: 이 스크립트는 플레이어의 행동을 처리합니다. 입력을 감지하고, 입력이 감지되면 타겟을 스캔하여 캐릭터를 각 타겟으로 이동시킵니다. 공격 시퀀스가 시작될 때 글로벌 MMF_Player를 트리거하고, 각 "히트"마다 개별 피드백을 제공합니다.
• BarbarianEnemy: 적을 처리하는 간단한 스크립트로, 데미지를 받고 데미지 MMF_Player를 트리거합니다.

Blob

 

이 데모는 "올인원" 피드백의 예를 보여줍니다. 시스템이 원래 설계된 목적은 아니지만, 여러 개의 원자 피드백으로 나누는 것이 유지 관리가 더 쉽습니다. FeelBlob/Feedbacks/MoveFeedback 아래에서 블롭이 "움직일 때" 모든 효과를 구동하는 피드백을 찾을 수 있습니다.

 

Bounce 

 

이 간단한 씬에서는 스페이스바를 눌러 캐릭터를 점프시킬 수 있습니다. 데모 씬에는 피드백이 있는 버전과 없는 버전 두 가지가 포함되어 있습니다. 계층 패널에서 SceneWithFeedbacks 및 SceneWithoutFeedbacks 노드를 활성화/비활성화하여 피드백을 추가하는 것이 얼마나 큰 차이를 만드는지 확인할 수 있습니다. 피드백이 있는 버전에서는 점프가 여러 피드백으로 나뉘어 있습니다: 충전, 점프, 착지. 이는 피드백을 구현할 때 권장되는 접근 방식이며, 가장 많은 제어를 제공합니다. 논리와의 의존성을 줄여주며, 게임의 중력을 변경하거나 점프를 아날로그 방식으로 만들기로 결정하더라도, 피드백의 타이밍을 조정할 필요가 없습니다.

 

Brass

 

이 데모는 Feel과 그 시스템, 특히 MMAudioAnalyzer를 사용하여 소리와 동기화하는 다양한 방법에 중점을 둡니다. 이 데모에서는 배경 음악이 재생되며, 음악의 리듬에 따라 땅이 움직이고, 큐브가 실시간으로 스펙트럼 비주얼라이저를 형성하며, 오디오 스펙트럼의 특정 부분이 미리 설정된 임계값을 초과할 때 이벤트와 피드백이 발생합니다. 전체 씬은 음악의 비트에 맞춰 동적으로 변경되며, 실시간으로 오디오를 변경하거나 배경 트랙을 원하는 트랙으로 교체할 수 있어 무한한 가능성을 제공합니다. MMAudioAnalyzer에 대한 자세한 내용은 문서의 전용 섹션에서 확인할 수 있습니다.

 

Cards UI

 

이 사용자 인터페이스 중심의 데모는 카드 스택을 사용하여 카드를 배포하고, 하나씩 공개하고, 다시 뒤집고, 다시 스택할 수 있습니다. 이 모든 것은 단 두 개의 MMF_Players를 사용하여 수행됩니다. 하나는 카드를 배포/스택하는 용도로, 다른 하나는 각 카드를 공개/숨기는 용도로 사용됩니다. 두 MMF_Players는 앞으로 재생되고 다시 뒤로 재생되도록 설정되어 있으며, 일부 피드백은 전체 시퀀스가 앞으로 재생되거나 뒤로 재생될 때만 실행되도록 조건이 설정되어 있습니다. 이러한 설정은 주로 기능을 시연하기 위한 것으로, 배포/스택을 두 개의 전용 MMF_Players로 분리하는 것이 더 쉽고 현명했을 것입니다. 하지만 이 설정이 여러분에게 아이디어를 제공하기를 바랍니다.

 

Duck

 

이번에는 2D로 된 또 다른 "점프" 데모입니다. FeelDuckJumpStartFeedback과 FeelDuckLandingFeedback의 두 가지 주요 피드백을 중심으로 구성됩니다. Duck 클래스에서 피드백을 자신의 캐릭터 컨트롤러 클래스에 통합하는 방법의 예를 확인할 수 있습니다.

 

GettingStartedTutorial

 

이 데모는 시작 튜토리얼의 예상 결과물입니다. 기본 피드백 설정과 게임의 느낌을 향상시키는 데 사용할 수 있는 몇 가지 도구를 다룹니다.

 

Letters

 

이 데모는 처음에는 의도하지 않았던 시스템과 상호 작용하기 위해 피드백을 사용하는 방법을 보여줍니다. 이 경우, 피드백은 Unity의 2D 뼈대 시스템과 상호 작용하는 데 사용됩니다(이 데모가 작동하려면 2D 뼈대 패키지를 설치해야 합니다). 애니메이션이 없고, 피드백은 단순히 뼈대의 회전과 크기에 영향을 주어 FEEL 글자에 생명을 불어넣습니다.

 

MMProgressBar

 

이 데모는 MMProgressBar 클래스를 중심으로 구성되며, 이를 사용하여 모든 종류의 진행 바를 만들고 이를 멋지게 만드는 방법을 보여줍니다.

 

MMSequencer

 

이 데모는 MMSequencer 시스템과 MMF_Player의 조합을 보여줍니다. 기본적으로 시퀀서는 타임라인에서 항목을 순서대로 배치하고 비트에 맞춰 재생하는 방법입니다. 이를 사용하여 소리를 재생할 수 있을 뿐만 아니라 원하는 이벤트도 재생할 수 있습니다. MMFeedbacksSequencer(MMSequencer의 특정 하위 유형)는 각 시퀀스 트랙에 피드백을 직접 바인딩할 수 있게 해줍니다. 이 씬을 즐기려면 Sequencers 노드를 펼치고 MMFeedbacksSequencer 오브젝트를 선택한 다음 재생 버튼을 누르고, 인스펙터에서 "StartPlaying" 버튼을 누르세요(이것은 해당 씬에서 자동으로 시작되도록 스페이스를 누르는 것과 같습니다). 그런 다음 트랙 슬롯을 클릭하여 패턴을 변경할 수 있습니다. 색이 있는 슬롯은 해당 트랙의 피드백이 비트에 도달할 때 재생된다는 것을 의미합니다.

 

MMSquashAndStretch

 

이 데모는 MMSquashAndStretch 컴포넌트의 다양한 사용 예를 보여줍니다. 이를 통해 객체에 주스있고 탄력 있는 동작을 추가하고, 이동할 때 질량감을 유지하면서 크기를 조절할 수 있습니다.

 

ParallaxUI

 

이 데모는 MMParallaxUI 컴포넌트를 사용하여 마우스, 자이로스코프 또는 스크립트로 제어되는 다양한 레이어의 패럴랙스가 있는 패럴랙스 UI 뷰를 빠르게 설정하는 방법을 보여줍니다.

 

Tactical

 

떠다니는 데미지 텍스트의 빠른 발사를 예로 들 수 있습니다. 데미지 텍스트 피드백에는 MMFloatingTextSpawner가 필요하며, 이 씬에서는 Managers 노드 아래에 각각 하나씩 있는 세 가지 다른 스포너를 찾을 수 있습니다. 각 Tactical 슈터는 ShootFeedbacks와 연결되어 있으며, 각각(다른 것들 중에서) 떠다니는 텍스트 피드백을 트리거합니다. 이들 각각은 특정 채널을 대상으로 하며, 일치하는 채널을 가진 세 가지 MMFloatingTextSpawners 중 하나에 의해 수신됩니다.

1. 첫 번째 스포너는 매우 기본적인 떠다니는 텍스트를 생성합니다.
2. 두 번째 스포너는 피드백을 통해 전원이 공급되는 텍스트를 생성하며, 생성된 후 MMF_Player를 재생하여 텍스트의 회전, 위치, 색상 및 간격을 애니메이션화합니다.
3. 세 번째 스포너는 TextMeshPro 떠다니는 텍스트를 생성합니다.

 

Templates

 

Feel/FeelDemos 폴더에서 FeelTemplatesDemo.unitypackage를 찾을 수 있습니다. 이를 추출하고 가져오면 두 개의 새로운 데모에 접근할 수 있습니다: FeelTemplatesDamage와 FeelTemplatesGuns. 이들은 MMF_Player 프리셋의 템플릿으로 프리팹을 사용하는 방법을 보여줍니다. 일부 종속성이 설치되지 않은 경우 Unity가 오류 메시지를 표시하므로, .unitypackage로 제공됩니다.

 

Toaster

 

Toaster 데모 씬은 화면 흔들림을 트리거하는 다양한 방법을 보여주는 데 중점을 둡니다. 메뉴에서 20개 이상의 다른 피드백을 재생할 수 있으며, 각각 다양한 방식으로 화면을 흔들고, 다른 요소들(임펄스, 카메라 위치, 회전, 줌, 포스트 프로세싱, 렌더 텍스처 등)에 작용합니다. 화면 흔들림에만 집중하고 싶다면 토스터 자체를 비활성화할 수도 있습니다.

 

Wheel

 

피드백은 일반적으로 "한 번" 이벤트(소리가 재생되거나, 햅틱 피드백, 무언가를 활성화하는 등)를 위해 설계되고 사용됩니다. 이 데모는 피드백을 사용하여 액션이 시작될 때 특정 상태로 전환하고, 해당 상태에서 벗어날 때 다시 되돌리는 방법을 보여줍니다. 이는 보다 "지속적/중단할 때까지" 효과를 제공합니다. TurnFeedbacks와 TurnStopFeedbacks를 살펴보면 그 작동 방식을 확인할 수 있습니다.

 

MMSoundManager Track Control

이 데모는 MMSoundManager를 통해 사용할 수 있는 일부 오디오 트랙 제어 기능을 보여줍니다. 개별 트랙에서 사운드를 재생하고, 볼륨을 제어하며, 트랙을 음소거/음소거 해제하고, 페이드 인 또는 페이드 아웃할 수 있습니다.

 

MMSoundManager Playlist Manager

이 데모는 다양한 노래 플레이리스트를 순서대로 또는 다양한 랜덤 모드로 재생하고, 이를 완전히 제어할 수 있는 고급 플레이리스트 시스템의 일부 기능을 보여줍니다.

Feel HDRP

Falcon

대부분의 피드백은 모든 렌더 파이프라인에서 동일하게 작동하지만, HDRP는 고유한 볼륨 시스템을 사용합니다. 이 데모는 피드백을 사용하여 HDRP의 볼륨 오버라이드를 타겟팅하고 제어하는 방법을 보여줍니다. 또한 스페이스바를 누르면 사막을 드라이브할 수 있습니다.

Feel URP

Strike

버전 2.3에 도입된 이 데모는 미니 볼링 게임을 특징으로 합니다(스페이스바를 눌러 공을 던질 수 있습니다). 점수와 모든 것이 완비되어 있으며, 원하는 경우 App Store에서 무료로 다운로드할 수 있습니다. 또한 URP 볼륨 오버라이드를 조종하는 다양한 피드백을 시연하는 컨트롤도 제공합니다.

Nice Vibrations

Nice Vibrations Demos

이 데모는 세로 모드에서 가장 잘 보이며, 다양한 방법으로 햅틱(“더 나은” 진동)을 재생할 수 있습니다. 에디터에서 실험해 볼 수 있으며, 게임패드에서 럼블 진동을 얻거나 iOS 또는 Android에서 빌드하여 테스트할 수 있습니다. 또는 App Store나 Google Play에서 사용할 수 있는 버전을 다운로드할 수도 있습니다. Nice Vibrations의 기능에 대해 더 알고 싶다면 전용 웹사이트와 문서를 참고하여 작동 방식과 사용 방법을 확인하세요.

MMTools

MMSceneLoadingDemoScene

 이 데모는 두 개의 씬(MMSceneLoadingDemoSceneA와 MMSceneLoadingDemoSceneB)으로 구성됩니다. 이를 작동시키려면 빌드 설정에 씬을 추가해야 합니다(파일 > 빌드 설정 > 두 씬을 "Scenes in Build" 섹션으로 드래그 앤 드롭). 이는 다른 로딩 모드를 사용하여 한 씬에서 다른 씬으로 이동하는 LoadScene 피드백을 사용하는 방법을 보여줍니다.

MMBezierLineRenderer

이 데모는 일반 LineRenderer에 추가된 MMBezierLineRenderer를 사용하여 이를 베지어 곡선으로 변환하는 방법을 보여줍니다. 그런 다음 핸들을 이동하여 곡선을 수정할 수 있습니다. 이 데모에서는 MMWiggle 컴포넌트가 핸들에 사용되어 자동으로 이동하지만, 이는 어떤 스크립트에 의해서도 구동될 수 있습니다. 또한 wiggle이 없는 라인 렌더러 버전도 찾을 수 있으며, 실행 중에 해당 버전의 핸들을 수동으로 이동할 수 있습니다.

MMControlsDemo

이 씬은 여러 모바일 컨트롤 헬퍼와 이를 설정하는 방법을 보여줍니다.

MMDebugMenu

이 씬에서는 콘솔 메뉴를 설정하는 방법과 게임 데이터의 실시간 수정에 사용하는 방법을 보여줍니다.

MMGhostCameraDemo

이 씬은 MMGhostCamera 컴포넌트를 시연합니다(해당 씬의 메인 카메라에 있음). 런타임에 화살표 키나 게임패드의 스틱으로 카메라를 제어하고, 키를 눌러 켜거나 끄며, 타임스케일을 수정할 수 있습니다. 모든 설정에 대해 민감도와 기타 설정을 완전히 제어할 수 있으며, 구 입력 시스템과 신 입력 시스템을 모두 지원합니다.

MMFollowTargetDemo

이 데모는 MMFollowTarget과 MMSpring이라는 두 가지 움직임 관련 헬퍼를 일반적인 보간과 비교하여 시연합니다. MMFollowTarget은 매우 부드러운 추적 동작을 제공하며, MMSpring은 간단한 추적 요소에 많은 생동감을 더할 수 있습니다.

MMGizmoDemo

이 데모는 MMGizmo 컴포넌트를 사용하여 객체에 쉽게 기즈모를 표시하는 다양한 방법을 보여줍니다. 이 컴포넌트는 객체의 위치나 콜라이더를 표시하는 기즈모와 선택적인 텍스트를 표시할 수 있습니다. 또한, 관련된 속성 값을 표시하는 데 사용할 수 있어 매우 유용한 디버그 도구가 됩니다. 이 기즈모들은 씬 뷰와 게임 뷰에서 모두 표시할 수 있습니다. 어떤 것을 선택하든 기즈모가 활성화되어 있는지 확인하세요!

MMObservableDemo

이 씬은 MMTools에서 관찰 가능한 패턴 구현을 시연합니다. MMObservable 설정을 테스트하려면 씬을 재생하고 씬 뷰에서 Subject 객체를 선택한 다음 X 축을 따라 이동하세요. 두 개의 구체는 관찰자 컴포넌트를 가지고 있으며, 큐브의 X 위치가 변경될 때 통지받습니다. 변경이 발생하면 구체는 자신의 Y 위치를 비례적으로 수정합니다. 이는 Update 루프 없이 이루어지며, 큐브의 X 위치가 변경되지 않으면 비용이 들지 않습니다.

MMRadioDemo

MMRadio 시스템의 데모입니다. 자세한 내용을 알고 싶다면 문서의 전용 섹션을 읽는 것이 좋지만, 간단히 말해 하나의 객체가 값을 여러 수신기에 브로드캐스트하고, 수신기들은 그 값을 기반으로 동작할 수 있게 하는 시스템입니다. 이 데모에서는 TestBroadcaster 객체가 MMRadioSignalGenerator를 사용하여 신호를 생성하고, 모든 큐브는 그 신호를 받아 Y 위치를 업데이트합니다.

MMPrototypeTexturesDemo

MMTools에는 프로토타이핑 텍스처가 여러 개 포함되어 있어 씬을 빠르게 깔끔하게 보이도록 할 수 있습니다. 이 데모 씬에서는 그 텍스처들을 모두 보여줍니다.

MMTweenPlotter

MMTween 시스템은 다양한 트윈 곡선을 사용하여 시간을 두고 값을 애니메이트할 수 있게 해줍니다. 이 데모는 각 곡선이 어떻게 느껴지는지 보여줍니다. MMTween 시스템은 많은 MM 컴포넌트에서 사용되며(대부분의 피드백이 이를 사용함), 시각적 참고 자료로 유용합니다. 이 데모는 HTML 형식으로도 제공됩니다.

기타 MMTools

MMTools에는 다양한 용도의 스크립트가 많이 있습니다. 대부분은 주석이 잘 달려 있고 보통은 자체 설명적이지만, 더 많은 데모가 필요할 수 있습니다. 특정 도구에 대한 데모를 원한다면 연락 양식을 사용하여 언급하는 것을 주저하지 마세요. 더 많은 데모가 추가될 예정이며, 특정 주제에 대한 요청이 많을수록 더 빨리 릴리스에 포함될 것입니다!

요약: 이 페이지는 에셋의 내용물을 설명합니다.

에셋에 무엇이 들어 있나요?

에셋에는 6개의 주요 폴더가 포함되어 있습니다:

• FeelDemos는 각기 독립된 폴더와 하위 폴더에 포함된 여러 데모를 포함하는 폴더입니다. 이 데모들은 Feel의 다양한 기능을 보여줍니다. 자세한 내용은 문서의 데모 섹션에서 확인할 수 있습니다.
• FeelDemosHDRP는 고해상도 렌더 파이프라인(High Definition Render Pipeline)에 특화된 데모를 포함합니다. 이러한 데모를 실행하려면 HDRP 프로젝트에 Feel을 가져와야 합니다.
• FeelDemosURP는 범용 렌더 파이프라인(Universal Render Pipeline)에 특화된 데모를 포함합니다. 이러한 데모를 실행하려면 URP 프로젝트에 Feel을 가져와야 합니다.
• MMFeedbacks는 에셋의 주요 부분입니다. 피드백 시스템, 모든 피드백 및 데모 씬이 포함되어 있습니다. 피드백을 사용하려면 반드시 이 폴더를 유지해야 합니다. 내부의 데모 폴더는 안전하게 제거할 수 있습니다.
• MMTools: MMTools는 다양한 유용한 도구가 포함된 멋진 라이브러리로, 에셋에 포함시키면 좋을 것 같아서 추가했습니다. 주저하지 말고 살펴보세요. 놀라운 것들이 가득합니다!
• NiceVibrations: Feel에 포함된 선물로, Nice Vibrations는 iOS 또는 Android 게임에 햅틱 피드백을 추가하는 최고의 방법입니다. 전용 웹사이트에서 더 많은 정보를 확인할 수 있습니다.

물건을 제거하고 싶다면 어떻게 하나요?

빌드 로그에서 볼 수 있듯이(Feel 4.0.1의 PC 빌드, MMF Player가 포함된 빈 씬 기준), Feel은 이미 매우 낮은 영향을 미치며, 프로젝트에 추가해도 빌드 크기에 몇 KB의 스크립트만 추가됩니다. Unity는 기본적으로 빌드 크기 최적화에 매우 뛰어나며, 사용한 것만 빌드에 포함시킵니다. 따라서 Feel에서 항목을 제거해도 얻을 수 있는 이점은 많지 않습니다. 유일한 이점은 프로젝트의 크기를 줄이는 것이지만(빌드 크기가 아닌), 몇 MB의 데모로 저장소 용량이 최대치에 도달하지는 않을 것입니다. 또한 컴파일 시간이나 기타 다른 부분에도 큰 영향을 미치지 않습니다. Feel의 모든 항목은 어셈블리 정의에 깔끔하게 정리되어 있기 때문입니다. 그러나 원한다면 항목을 제거할 수도 있습니다. 삭제한 항목은 잃게 되겠지만, 이는 여러분의 프로젝트이며 여러분의 규칙입니다.

다시 말하지만, 권장하거나 필요한 것은 아니지만, 만약 그렇게 하기로 결정한다면:

데모:

• 전체 Feel/FeelDemos 폴더를 안전하게 제거할 수 있습니다 (데모에 대한 쉬운 접근을 잃게 됩니다).
• 전체 Feel/FeelDemosURP 폴더를 안전하게 제거할 수 있습니다 (URP 데모에 대한 쉬운 접근을 잃게 됩니다).
• 전체 Feel/FeelDemosHDRP 폴더를 안전하게 제거할 수 있습니다 (HDRP 데모에 대한 쉬운 접근을 잃게 됩니다).
• 전체 Feel/MMFeedbacks/Demos 폴더를 안전하게 제거할 수 있습니다 (MMFeedbacks 데모에 대한 접근을 잃게 됩니다).
• 전체 Feel/MMTools/Demos 폴더를 안전하게 제거할 수 있습니다 (MMTools 데모에 대한 접근을 잃게 됩니다).
• 중요: 대부분의 Feel 데모(URP/HDRP 데모 포함)는 FeelDemos/_Common/ 폴더에 의존하므로, 일부 데모를 삭제하되 예를 들어 URP 데모를 유지하려면 해당 폴더도 유지해야 합니다.
  
  

선택적 라이브러리:

• Feel/NiceVibrations 폴더를 제거할 수 있습니다. 이 경우 Project Settings > Player로 이동하여  MOREMOUNTAINS_NICEVIBRATIONS_INSTALLED 스크립팅 정의 심볼을 제거하고(변경 사항을 적용), Nice Vibrations 및 관련 피드백에 대한 접근을 잃게 됩니다.
• Feel/MMFeedbacks/MMFeedbacksForThirdParties 폴더(또는 그 일부)를 제거할 수 있습니다. 이 경우 해당 폴더에 포함된 피드백에 대한 접근을 잃게 됩니다.

MMTools:

MMTools 폴더 내에는 4개의 주요 폴더가 있습니다: Accessories, Core, Demos, Foundation.

• MMTools/Demos 폴더를 안전하게 제거할 수 있습니다. 이 경우 다양한 데모에 대한 접근을 잃게 되지만, 모두 선택 사항입니다.
• MMTools/Accessories 폴더를 안전하게 제거할 수 있습니다. 이 경우 많은 헬퍼 도구에 대한 접근을 잃게 되지만, 피드백에는 영향을 미치지 않습니다.
• MMTools/Foundation 폴더를 안전하게 제거할 수 있습니다. 이 경우 도구에 대한 접근을 잃게 되지만, 피드백에는 영향을 미치지 않습니다.
• 이론적으로 MMTools/Core 폴더를 제거할 수 있지만, 이는 오류를 발생시키지 않지만 피드백 시스템의 많은 핵심 기능을 잃게 됩니다.

요약: 이 페이지는 Feel에서 렌더 파이프라인이 어떻게 작동하는지 설명합니다.

소개

몇 년 전 Unity는 SRP(Scriptable Render Pipelines) 개념을 도입했습니다. 이를 좋아하는 사람도 있고 싫어하는 사람도 있지만, 이제는 SRP가 정착될 가능성이 큽니다. Feel은 모든 렌더 파이프라인에서 작동하며, URP나 HDRP 프로젝트에 Feel을 가져올 수 있습니다.

이 규칙의 두 가지 예외가 있습니다:

• 데모
• 포스트 프로세싱 피드백

데모와 렌더 파이프라인

Unity가 렌더 파이프라인을 분리하기로 결정하면서, 모든 렌더 파이프라인에서 작동하는 데모를 제공하는 것이 불가능해졌습니다. 기술적으로 모든 데모를 세 번씩 복제하는 것(하나는 Standard, 하나는 URP, 하나는 HDRP)은 가능하지만, 이는 자산의 크기를 세 배로 늘리고 유지보수를 매우 어렵게 만듭니다. 그래서 대부분의 데모는 Built-in RP를 사용합니다. Built-in RP는 여전히 가장 널리 사용되는 렌더 파이프라인이며, 2022년 기준으로 70% 이상의 프로젝트가 Built-in RP를 사용하여 제작되었습니다. URP/HDRP/CustomRP 프로젝트에서 대부분의 데모를 열면 많은 재질이 누락되거나 깨질 가능성이 큽니다. Unity가 표준 재질을 URP로 변환할 수 있지만, 이는 완벽하지 않아서 모든 재질이 제대로 작동하지는 않을 것입니다.

표준이 아닌 RP에서 Feel을 사용하려고 하지만 여전히 데모를 확인하고 싶다면, 가장 쉬운 해결책은 프로젝트에 Feel을 추가하고 데모를 확인하기 위해 표준 RP 프로젝트를 만드는 것입니다.

포스트 트로세싱

Feel의 대부분의 시스템은 사용 중인 렌더 파이프라인과 완전히 독립적이지만, 일부 피드백은 포스트 프로세싱을 타겟으로 하며, 이는 렌더 파이프라인마다 다릅니다. Unity에는 3가지 주요 포스트 프로세싱 시스템이 있습니다(깊은 한숨):

• 표준 RP용 포스트 프로세싱(패키지 매니저를 통해 설치해야 하는 별도 패키지)
• URP용 URP 볼륨
• HDRP용 HDRP 볼륨

버전 2.3부터는 HDRP와 URP 볼륨에 대한 특정 피드백을 보여주는 전용 HDRP 및 URP 데모가 제공됩니다(문서의 전용 섹션 참조). 물론 해당 데모는 각 렌더 파이프라인에 맞는 프로젝트에서 사용해야 합니다.

설치 지침

Optional Steps

참고로, 4, 5, 6, 7 단계는 선택 사항이지만, 포스트 프로세싱, TextMesh Pro 및 Cinemachine 피드백에 접근하려면 해당 패키지가 필요합니다. 또한 대부분의 Feel 데모는 가능한 많은 피드백을 사용하며, 이러한 종속성 대부분을 포함합니다. 해당 종속성을 설치하지 않으면 오류가 발생할 수 있습니다.

URP 및 HDRP

Feel은 모든 렌더 파이프라인에서 작동하며, URP 또는 HDRP 프로젝트에 Feel을 가져올 수 있습니다. 다만, 대부분의 데모는 표준 렌더 파이프라인(Standard RP)을 사용하여 제작되었으므로 다른 파이프라인을 사용하는 프로젝트에서 열 때 올바르게 렌더링되지 않을 수 있습니다. 그리고 URP나 HDRP에서는 포스트 프로세싱 패키지를 설치할 필요가 없습니다. 이들은 자체 포스트 프로세싱 볼륨 시스템을 함께 제공합니다.

버전 2.3부터는 전용 HDRP 및 URP 데모가 제공됩니다(문서의 전용 섹션 참조). 물론 해당 파이프라인과 일치하는 프로젝트에 설치해야 합니다.

일부 제 재질이 모두 분홍색으로 표시됩니다! 엔진의 데모에서 사용되는 대부분의 재질은 모든 렌더 파이프라인(RP)에서 잘 표시되지만, NewCorgi3D와 같은 몇몇 데모는 커스텀 셰이더를 사용하며, 이 셰이더들은 HDRP 또는 URP에서 깨질 수 있습니다. 다행히도, 이를 비교적 쉽게 변환할 수 있습니다. 다음과 같이 진행하세요:

1. BiRP 셰이더를 사용하는 모든 재질을 선택합니다(보통 Demos/Corgi3D/Materials 폴더 아래에 있는 재질들).
2. 선택된 재질의 인스펙터에서 상단에 있는 셰이더를 Standard로 설정합니다.
3. 그런 다음, Edit > Rendering > Materials > Convert Selected Built-In Materials to URP로 이동합니다. 이 과정이 끝나면 BiRP에서와 똑같이 보이지는 않겠지만, 데모를 무리 없이 즐길 수 있습니다.

Editor pre-releases

URP 15 이상 버전을 사용하는 경우, "Light2D" 타입이나 네임스페이스 이름을 찾을 수 없다는 오류가 발생할 가능성이 큽니다. 이는 Unity가 Light 2D 클래스가 속한 어셈블리를 변경하여 이전 버전의 URP와의 호환성을 깨뜨렸기 때문입니다. 이 문제가 해결되거나 이전 버전의 지원이 중단될 때까지, 다음과 같은 방법으로 이 문제를 해결할 수 있습니다:

문제를 일으키는 두 클래스를 제거합니다(MMF_Light2D_URP 및 MMLight2DShaker - 오류를 클릭하면 프로젝트 패널에서 이 클래스들이 강조 표시됩니다). 또는 2D 패키지를 설치할 수도 있습니다. 2D 라이팅을 사용할 계획이 없다면, 이 두 클래스를 삭제하는 것이 가장 쉬운 방법입니다. 네, 이 문제는 성가실 수 있습니다.

Feel을 이전 버전에서 새 버전으로 업데이트하는 가장 좋은 방법은 무엇인가요?

무엇을 하든 문제가 발생할 경우 롤백할 수 있도록 커밋/백업을 만들어 두세요. 그런 다음 이전 Feel 폴더를 제거하고 새 폴더를 가져오세요. 그렇지 않으면 Asset Store 가져오기 방식 때문에 일부 스크립트가 중복되거나 제거되지 않을 수 있습니다. 업데이트하는 버전과 대상 버전에 따라 약간의 리팩토링이 필요할 수 있습니다. 릴리스 노트를 확인하여 변경된 사항과 코드에 영향을 미칠 수 있는 사항을 확인하세요.

입력

데모는 Unity의 입력 API를 사용하여 상호작용을 트리거합니다. 이는 대다수의 사용자가 여전히 "새로운" 입력 시스템으로 이동하지 않았기 때문에 "구" 입력 API를 사용합니다. 새로운 입력 시스템을 사용하는 경우 하이브리드 모드로 전환할 수 있습니다 (Player Settings > Active Input Handling > Both). 또는 URP/HDRP를 실행하고 공통 분모 데모를 확인하고 싶을 때처럼, 데모를 확인하기 위해 사이드 프로젝트를 생성할 수 있습니다. 데모일 뿐이며, 나머지는 모든 곳에서 잘 실행될 것입니다. 네, 성가실 수 있지만, 이것이 현재 Unity의 상태입니다.

Feel이란 무엇인가요?

Feel은 최소한의 마찰이나 설정으로 필요에 따라 Unity 게임에 게임 느낌을 제공하는 즉시 사용 가능한 솔루션입니다. 모듈식, 사용자 친화적이며 확장하기 쉬운 시스템으로, 이를 기반으로 구축할 수 있습니다.

Feel이 왜 좋은가요?

게임의 느낌(또는 주스, 마이크로 인터랙션, 피드백)은 게임 디자인에서 가장 중요한 부분 중 하나라고 굳게 믿습니다.

플레이어가 자신의 행동의 결과를 이해하게 하는 것은 상호작용이 보람 있고 몰입되게 만드는 가장 좋은 방법입니다. 플레이어가 행동을 취했을 때 또는 게임에서 중요한 일이 일어났을 때 적절한 피드백을 제공하는 것은 필수적입니다. 화면 흔들림, 플래시, 객체의 크기 증가 또는 이 모든 것을 한 번에 제공하는 것은 경험을 더욱 만족스럽게 만듭니다.

피드백에 대해 더 알고 싶다면 Martin Jonasson과 Petri Purho의 "Juice it or lose it" 강연, Jan Willem Nijman의 "Art of screenshake" 강연, 또는 2018년 Unite Los Angeles에서의 저의 게임 느낌과 빠른 프로토타이핑에 대한 강연, 그리고 2019년 코펜하겐에서의 강연을 참고하세요.

이러한 종류의 피드백을 구현하는 것은 로켓 과학이 아닙니다. 카메라를 흔드는 것은 꽤 쉬운 작업입니다. 그러나 많은 게임과 프로토타입을 작업하면서 종종 동일한 게임 느낌 레시피로 돌아가게 되었고, 피드백에 대한 아이디어와 게임 내 구현 사이의 마찰을 최대한 줄이고 싶었습니다. 처음에는 TopDown Engine과 Corgi Engine에 내장된 Feel 시스템을 공개하기로 결정하여 사람들이 게임의 느낌을 개선하는 데 도움이 되기를 바랍니다.

Feel을 이전 버전에서 새 버전으로 업데이트하는 가장 좋은 방법은 무엇인가요?

무엇을 하든 문제가 발생할 경우 롤백할 수 있도록 커밋/백업을 만들어 두세요. 그런 다음 이전 Feel 폴더를 제거하고 새 폴더를 가져오세요. 그렇지 않으면 Asset Store 가져오기 방식 때문에 일부 스크립트가 중복되거나 제거되지 않을 수 있습니다. 업데이트하는 버전과 대상 버전에 따라 약간의 리팩토링이 필요할 수 있습니다. 릴리스 노트를 확인하여 변경된 사항과 코드에 영향을 미칠 수 있는 사항을 확인하세요.

모든 곳에서 작동하나요?

짧은 대답은 예입니다. Feel은 Unity가 지원하는 모든 플랫폼에서 작동합니다. Feel의 스크립트는 최적화가 잘 되어 있으며 가능한 한 낮은 비용으로 제공됩니다. 다만, Feel은 Unity의 기본 API 및 시스템을 대상으로 하며 그 비용을 변경하지 않습니다. 따라서 일반적으로 포스트 프로세싱 효과는 Feel을 사용하든 사용하지 않든 모바일에서 비용이 많이 들 것입니다. Feel은 수많은 파티클 시스템을 인스턴스화하는 피드백을 사용하는 것을 막지 않지만, 이는 Switch에서 잘 작동하지 않을 것입니다. 따라서 중요한 질문은 Feel을 무엇과 함께 사용할 계획인지입니다. 프레임 예산을 확인하고 Feel이 작동하는 요소들이 그 예산 내에 맞는지 확인하세요.  

다른 MoreMountains 자산에 Feel을 가져올 수 있나요?

Corgi Engine, Infinite Runner Engine, Nice Touch 또는 TopDown Engine을 사용 중이라면, 이들은 이미 MMFeedbacks와 MMTools(또는 그 일부)를 포함하고 있으므로 FEEL을 추가로 가져올 필요가 없습니다. 만약 그렇다면 일부 공통 라이브러리가 동기화되지 않을 수 있습니다. 항상 가장 오래된 것을 제거하고 새 것을 가져오며, 몇 가지 리팩토링을 준비하세요. 가져올 때 공통 라이브러리 폴더를 선택 해제할 수도 있습니다. 또는 다음 엔진 업데이트를 기다리세요.

Highroad Engine과 함께 사용할 계획이라면, 일부 리팩토링이 필요할 수 있으며, C#에 익숙하지 않은 경우 권장하지 않습니다. 이들은 몇 가지 공통 라이브러리를 가지고 있으며 현재 동기화되지 않습니다. 이는 곧 업데이트에서 수정될 예정입니다.

네비메시 기반 그래프를 위한 고급 AI.

Inspecter

Shape

Radius

float radius = 0.5f

에이전트의 반지름을 월드 유닛으로 나타냅니다.

이것은 씬 뷰에서 캐릭터 주변의 노란색 실린더로 시각화됩니다.
경로 찾기에는 아무런 영향을 미치지 않는다는 점에 유의하십시오. 에이전트가 이동할 수 있는 위치는 그래프에 의해 완전히 결정됩니다.

Height

에이전트의 높이를 월드 유닛으로 나타냅니다.

이것은 씬 뷰에서 캐릭터 주변의 노란색 실린더로 시각화됩니다.

이 값은 현재 RVOController가 동일한 GameObject에 첨부된 경우에만 사용되며, 그렇지 않으면 씬 뷰에서 멋진 기즈모를 그리는 데만 사용됩니다. 그러나 높이 값이 일부 용도로 사용되기 때문에 반지름 필드는 항상 일관성과 캐릭터의 더 쉬운 시각화를 위해 표시됩니다. 이는 향후 릴리스에서 사용될 수 있습니다.

Pathfinding

?

Movement

Can Move

이동을 완전히 활성화하거나 비활성화합니다.

에이전트가 정지 상태로 있지만 여전히 로컬 회피에 반응하고 중력을 사용하도록 하려면  isStopped를 사용하십시오.

이것은 이동 계산이 실행되는 시점을 완전히 제어하려는 경우에도 유용합니다. MovementUpdate를 참조하십시오.

Max Speed

초당 월드 유닛으로 최대 속도를 설정합니다.

Acceleration

에이전트의 최대 가속도입니다.

초당 월드 유닛으로 표시됩니다.

Enable Rotation

참이면 AI가 이동 방향을 향해 회전합니다.

Rotation Speed

에이전트의 최대 회전 속도입니다.

초당 도 단위로 표시됩니다.

Slow When Not Facing Target

대상 방향을 향하지 않을 때 속도를 줄입니다.

약간의 성능 오버헤드가 발생합니다.

이 설정은 enableRotation이 활성화된 경우에만 효과가 있습니다.

Prevent Moving Backwards

캐릭터의 전방 방향과 너무 멀리 떨어진 속도를 방지합니다.

캐릭터가 향하고 있는 방향과 반대 방향으로 이동하도록 명령받은 경우, 이를 활성화하면 제자리에서 회전하는 대신 작은 루프를 만듭니다.

이 설정은  slowWhenNotFacingTarget이 활성화된 경우에만 효과가 있습니다.

slowdownTime

경로 끝에 도달하기 전에 감속을 시작하는 시간입니다.

더 낮은 값은 에이전트가 더 갑작스럽게 멈추게 합니다.

0으로 설정하면 에이전트는 감속을 시도조차 하지 않습니다. 이는 대상 지점이 에이전트가 멈추기를 원하는 지점이 아니라 플레이어와 같은 대상일 경우 유용할 수 있으며, 이 경우 AI가 플레이어와 충돌하도록 할 수 있습니다.

Wall Force

벽을 피하기 위한 힘입니다.

에이전트는 벽에서 약간 떨어져 나가려고 시도할 것입니다.

wallDist

이 범위 내의 벽은 회피에 사용됩니다.

이를 0으로 설정하면 벽 회피가 비활성화되며 성능이 약간 향상될 수 있습니다.

Funnel Simplification

퍼널 단순화를 사용합니다.

타일된 네비메시 맵에서, 그리고 때로는 일반 맵에서도 퍼널을 단순화하여 경로를 더 직선으로 만드는 것이 좋습니다.

이 설정은 경로 계산이 완료된 프레임 동안 중간 정도의 성능 영향을 미칩니다.

RichAI 스크립트는 자체 내부 퍼널 알고리즘을 사용하므로 FunnelModifier 컴포넌트를 첨부할 필요가 없습니다.

End Reached Distance

경로의 끝에 도달했다고 간주할 종점까지의 거리입니다.

경로의 끝이 이 거리 내에 있으면  IAstarAI.reachedEndOfPath가 true를 반환합니다.  destination(목적지)가 이 거리 내에 있으면  IAstarAI.reachedDestination이 true를 반환합니다.

경로의 끝에 도달했다고 해서 반드시 destination(목적지)에 도달한 것은 아님을 유의하십시오. destination(목적지)에 도달할 수 없을 수도 있습니다.

When Close To Destination

목적지에서 endReachedDistance 단위 내에 있을 때 수행할 작업입니다.

캐릭터는 그 거리 내에 도달했을 때 즉시 멈출 수 있으며, 이는 목표물에 발사하려는 궁수나 다른 원거리 유닛에 유용합니다. 또는 캐릭터가 지정된 정확한 목적지 지점을 계속 시도하여 완전히 멈출 수도 있습니다. 이는 캐릭터가 지정한 정확한 지점에 도달하게 하고 싶을 때 유용합니다.

Stop when destination is crowded

?

gravity

사용할 중력입니다.

(NaN, NaN, NaN)으로 설정하면 Unity 프로젝트 설정에서 구성된 Physics.Gravity가 사용됩니다. (0, 0, 0)으로 설정하면 중력이 사용되지 않으며 지면 침투를 확인하기 위한 레이캐스트가 수행되지 않습니다.

Raycast Ground Mask

?

월드 지형을 기반으로 자동으로 네비메쉬 그래프를 생성합니다.

Recast 그래프는 Recast(http://code.google.com/p/recastnavigation/)를 기반으로 합니다. 이것을 Unity에서 네이티브로 실행할 수 있도록 상당 부분을 C#으로 번역했습니다.

Recast 그래프를 설정하는 방법에 대한 튜토리얼은 네비메쉬 자동 생성하기(  Automatically generating a navmesh)를 참조하세요.

Inspector

Shape

Dimensions

3D 모드 또는 2D 모드를 사용할지 여부.

Center

바운딩 박스의 중심.

스캔은 바운딩 박스 내부에서만 수행됩니다.

Size

바운딩 박스의 크기.

Rotation

그래프의 회전 각도(도 단위).

Snap bounds to scene ()

설정에 따라 스캔 프로세스에 포함될 수 있는 씬의 모든 객체를 정확하게 캡슐화하도록 그래프의 경계를 변경합니다.

어떤 객체가 사용되는지는 설정에 따라 다릅니다. 현재 설정에서 그래프의 경계 내에 있는 객체가 그래프에 영향을 미칠 경우, 해당 객체를 포함하도록 경계가 확장됩니다.

이 메서드는 인스펙터에서 '씬에 경계 맞추기' 버튼에 해당합니다.

Input Filtering

Filter Objects By

객체의 초기 필터링 방법을 결정합니다.

Layer Mask

이 레이어에 있는 모든 객체가 래스터화됩니다.

collectionMode가 Layers로 설정된 경우에만 사용됩니다.

Tag Mask

이 태그 중 하나로 태그된 객체가 래스터화됩니다.

collectionMode가 Tags로 설정된 경우에만 사용됩니다.

Rasterize Terrains

네비메쉬 계산에 지형을 사용합니다.

2D 모드에서는 이 설정이 적용되지 않습니다.

Rasterize Trees

지형 위의 나무 콜라이더를 래스터화합니다.

나무 프리팹에 콜라이더가 있으면 해당 콜라이더가 래스터화됩니다. 그렇지 않은 경우 간단한 박스 콜라이더가 사용되며, 스크립트는 나무의 크기에 맞추려고 시도합니다. 그러나 정확하지 않을 수 있으므로 콜라이더가 첨부된 것이 더 좋습니다.

2D 모드에서는 이 설정이 적용되지 않습니다.

Heightmap Downsampling

래스터화를 위해 사용되는 입력 메쉬를 생성하기 전에 지형의 높이맵을 얼마나 다운샘플링할지 제어합니다.

값이 높을수록 스캔 속도는 빠르지만 정확도는 떨어집니다.

Rasterize Meshes

씬 메쉬를 사용하여 네비메쉬를 계산합니다.

콜라이더보다 더 높은 정밀도를 얻을 수 있습니다. 콜라이더는 일반적으로 메쉬의 매우 단순화된 버전이기 때문입니다. 그러나 스캔 속도가 느려질 수 있으며, 그래프 업데이트가 특히 느릴 수 있습니다.

그래프 업데이트가 느린 이유는 주어진 타일과 교차하는 모든 메쉬를 효율적으로 찾는 방법이 없기 때문입니다. 따라서 업데이트하려는 타일에 관련된 메쉬를 찾기 위해 씬의 모든 메쉬를 반복해야 합니다. 반면에 콜라이더는 물리 시스템을 사용하여 효율적으로 쿼리할 수 있습니다.

이 설정을 비활성화하고 대신 RecastMeshObj 컴포넌트(dynamic=false)를 네비메쉬에 포함시키고자 하는 모든 메쉬에 첨부할 수 있습니다. 이렇게 하면 씬의 모든 메쉬를 반복하지 않고도 효율적으로 쿼리할 수 있습니다.

2D 모드에서는 이 설정이 적용되지 않습니다.

Rasterize Colliders

네비메쉬를 계산하기 위해 콜라이더를 사용합니다.

dimensionMode 에 따라 3D 또는 2D 콜라이더가 래스터화됩니다.

Sphere/Capsule/Circle 콜라이더는 다각형을 사용하여 근사화되며, 정확도는 RecastGraph.colliderRasterizeDetail에 지정됩니다.

Agent Characteristics

Character Radius

네비메쉬를 이동할 에이전트의 반경입니다.

네비메쉬는 이 반경으로 침식됩니다.

Character Height

캐릭터의 높이.

Max Step Height

캐릭터가 오를 수 있는 높이.

Max Slope

캐릭터가 이동할 수 있는 최대 경사(도 단위).

Per Layer Modifications

래스터화된 객체의 레이어를 기반으로 그래프를 수정하는 규칙 목록입니다.

기본적으로 모든 레이어는 이동 가능한 표면으로 처리됩니다. 그러나 이 목록에 규칙을 추가하면 특정 레이어를 가진 모든 표면에 특정 경로 탐색 태그를 부여할 수 있습니다.

각 레이어는 이 목록에서 최대 한 번만 수정되어야 합니다.

객체에  RecastMeshObj컴포넌트가 첨부된 경우, 해당 컴포넌트의 설정이 이 목록의 설정을 재정의합니다.

Rasterization

Voxel Size

복셀 샘플 크기 (x, z).

Recast 그래프를 생성할 때 월드가 복셀화됩니다. 이것은 많은 상자로 구성된 월드의 근사치를 만드는 것으로 생각할 수 있습니다. Minecraft를 플레이해본 적이 있다면 매우 비슷하게 보입니다 (하지만 상자가 더 작습니다).

셀 크기는 이러한 상자의 너비와 깊이를 나타냅니다. 상자의 높이는 일반적으로 더 작으며 자동으로 계산됩니다.

값이 낮을수록 더 높은 품질의 네비메쉬를 얻을 수 있지만, 그래프 스캔 속도는 느려집니다.

Use Tiles

true로 설정하면 그래프를 타일로 나누고, 그렇지 않으면 전체 그래프를 단일 타일로 다룹니다.

타일을 사용하는 것은 여러 가지 유용한 점이 있지만, 몇 가지 단점도 있습니다.

타일을 사용하면 그래프의 일부만 업데이트할 수 있습니다. Recast 그래프에서 그래프 업데이트를 수행할 때 항상 전체 타일을 다시 계산합니다 (또는 타일이 없으면 전체 그래프를 다시 계산합니다).  NavmeshCut컴포넌트도 타일 단위로 작동합니다.

타일을 사용하면  NavmeshPrefabs 를 사용할 수 있습니다.

타일을 사용하면 매우 큰 삼각형을 분할할 수 있어, 일부 경우 경로 품질을 개선하고 네비메쉬가 지형의 y좌표를 더 잘 따르도록 만들 수 있습니다.

타일을 사용하면 네비메쉬 생성 속도가 크게 빨라질 수 있습니다. 각 타일을 병렬로 계산할 수 있기 때문입니다. 그러나 타일을 너무 작게 만들면 많은 타일의 오버헤드가 적은 타일보다 느릴 수 있습니다.

작은 타일을 사용하면 경우에 따라 경로 품질이 나빠질 수 있지만,  FunnelModifiers의 품질 설정을 높게 설정하거나 RichAI.funnelSimplification을 사용하면 대부분 이를 완화할 수 있습니다.

Tile Size

단일 타일의 복셀 크기입니다.

이 값은 타일의 너비를 나타냅니다.

큰 타일 크기는 초기 스캔 속도가 빠를 수 있지만, 큰 세계에서 너무 큰 타일 크기를 시도하면 메모리 부족 문제가 발생할 수 있습니다. 작은 타일 크기는 업데이트 속도가 (훨씬) 빠릅니다.

타일 크기는 경로의 품질에 영향을 미칠 수 있습니다. 더 나은 품질의 경로를 위해 거대한 열린 공간을 여러 타일로 나누는 것이 좋지만, 너무 작은 타일은 보이지 않는 장애물처럼 보이는 효과를 일으킬 수 있습니다. 이에 대한 자세한 내용은 네비메쉬 그래프에 대한 노트를 참조하십시오. 일반적으로 실험을 통해 게임에 가장 적합한 설정을 찾는 것이 좋습니다.

Recast 그래프를 스캔할 때 개별 타일은 병렬로 계산될 수 있어 큰 세계를 스캔하는 속도를 크게 높일 수 있습니다. Recast 그래프의 일부를 다시 계산하려면 타일 단위로만 수행할 수 있습니다. 따라서 타일 크기보다 훨씬 작은 영역을 자주 업데이트하려고 하면 불필요한 계산을 많이 수행하게 됩니다. 반면에 타일 크기보다 훨씬 큰 영역을 업데이트하려고 하면 많은 타일을 사용해야 하는 오버헤드 때문에 필요 이상으로 느려질 수 있습니다 (하지만 그렇게 많이 느려지지는 않습니다).

추천 값은 64에서 256 사이이지만, 이는 매우 유연한 한계입니다. 더 크거나 작은 값도 사용할 수 있습니다.

Max Border Edge Length

더 긴 에지는 세분화됩니다.

이 값을 줄이면 경로 품질이 향상될 수 있습니다. 크기가 비슷한 삼각형이 서로 매우 크거나 매우 작은 삼각형보다 더 나은 경로를 제공합니다. 그러나 더 많은 노드를 추가하게 되어 경로 탐색이 느려질 수 있습니다. 이에 대한 자세한 내용은 네비메쉬 그래프에 대한 노트를 참조하십시오.

Edge Simplification

단순화된 에지에서 실제 에지까지의 최대 거리.

이 값은 복셀 단위로 측정됩니다. 기본값 2는 최종 네비메쉬 윤곽이 월드를 복셀화할 때 계산된 경계에서 최대 2 복셀(즉, cellSize의 2배) 떨어질 수 있음을 의미합니다. 더 높은 값은 더 단순화되고 깔끔한 네비메쉬를 제공하며, 더 낮은 값은 더 많은 세부 사항을 포착할 수 있습니다. 그러나 너무 낮은 값은 개별 복셀이 보이게 할 수 있습니다 (아래 이미지 참조).

Min Region Size

최소 영역 크기.

작은 영역은 네비메쉬에서 제거됩니다. 이 값은 복셀 단위로 측정됩니다.

영역이 타일 경계에 인접해 있는 경우, 작은 영역일지라도 인접한 타일이 합쳐져 더 큰 영역을 형성할 수 있으므로 제거되지 않습니다.

Round Collider Detail

구와 캡슐 콜라이더의 래스터화 세부사항을 제어합니다.

콜라이더는 다각형으로 근사화되어 이론적 표면까지의 최대 거리가 1/(이 복셀 수)보다 작아지도록 합니다.

더 높은 값이 반드시 메쉬의 품질을 향상시키는 것은 아니지만, 더 낮은 값은 스캔 속도를 높일 수 있습니다.

메쉬 품질에 영향을 주지 않으면서 이 값을 가능한 낮게 유지하는 것이 가장 빠른 스캔 시간을 제공할 것입니다.

기본값은 1이며, 이는 최대 오차가 1 복셀에 해당합니다. 대부분의 경우, 이를 2보다 높은 값으로 설정하는 것은 (최대 오차 0.5 복셀에 해당) 유용하지 않습니다.

Runtime Settings

Affected By Navmesh Cuts

네비메쉬 컷이 이 그래프에 영향을 미쳐야 하는지 여부.

Advanced

Relevant Graph Surface Mode

모든 영역에 RelevantGraphSurface 컴포넌트가 포함되어야 합니다.

씬에 배치된 RelevantGraphSurface 컴포넌트는 해당 네비메쉬 영역이 네비메쉬에 포함되어야 함을 지정합니다.

이 설정이 OnlyForCompletelyInsideTile로 설정된 경우, 네비메쉬 영역에 RelevantGraphSurface가 포함되어 있거나 타일 경계에 인접해 있는 경우 네비메쉬에 포함됩니다. 이로 인해 타일 경계에 인접해 있기 때문에 원하지 않는 작은 영역이 포함될 수 있지만, 모든 타일에 컴포넌트를 배치해야 하는 번거로움을 줄일 수 있습니다.

이 설정이 RequireForAll로 설정된 경우, 네비메쉬 영역은 내부에 RelevantGraphSurface가 있는 경우에만 포함됩니다. 네비메쉬가 타일 간에 연속적으로 보이더라도 타일은 개별적으로 계산되므로 각 영역과 각 타일에 RelevantGraphSurface 컴포넌트가 필요합니다.

위 이미지에서, OnlyForCompletelyInsideTile 모드가 사용되었습니다. 타일 경계는 검은색으로 강조 표시되어 있습니다. 모든 영역이 타일 경계에 인접해 있기 때문에 이 모드는 이 경우 아무것도 제거하지 않으며, DoNotRequire 모드와 동일한 결과를 제공합니다. RelevantGraphSurface 컴포넌트는 파란색 평면의 오른쪽 상단에 있는 녹색 기즈모로 표시되어 있습니다.

위 이미지에서 RequireForAll 모드가 사용되었습니다. 타일은 사용되지 않았습니다. 주황색 큐브 상단의 작은 영역이 사라졌음을 주목하십시오. 이는 해당 영역이 관련 그래프 표면 컴포넌트와 같은 영역에 있지 않았기 때문입니다. 타일이 없기 때문에 결과는 OnlyForCompletelyInsideTile 모드와 동일했을 것입니다 (또는 하나의 타일로 간주할 수도 있습니다).

여기서는 RequireForAll 모드가 사용되었습니다. RelevantGraphSurface 컴포넌트가 하나만 있기 때문에, 해당 컴포넌트가 위치한 타일 내의 영역만 활성화됩니다. 만약 다른 타일에 여러 RelevantGraphSurface 컴포넌트가 있었다면, 해당 영역들도 활성화될 수 있었을 것입니다.

여기서는 다른 타일 크기와 함께 OnlyForCompletelyInsideTile 모드가 사용되었습니다. 주황색 큐브 상단의 영역은 더 이상 존재하지 않습니다. 이는 해당 영역의 경계가 그 영역과 교차하지 않으며, 내부에 RelevantGraphSurface 컴포넌트가 없기 때문입니다.

Initial Penalty

모든 노드에 적용할 기본 페널티입니다.

Recast 그래프가 작동하는 방식

Recast 그래프를 생성할 때 세계가 복셀화됩니다. 이것은 세계를 많은 상자로 구성한 근사치로 생각할 수 있습니다. Minecraft를 플레이해본 적이 있다면 매우 비슷하지만, 더 작은 상자를 사용하는 것입니다.

Recast 프로세스는 다음과 같이 설명됩니다:

• 입력 삼각형 메쉬에서 복셀 틀을 생성합니다. 삼각형을 여러 층의 높이 필드로 래스터화하여 틀을 만듭니다. 그런 다음, 캐릭터가 이동할 수 없는 위치를 제거하기 위해 몇 가지 간단한 필터가 틀에 적용됩니다.
• 틀에 의해 설명된 이동 가능한 영역은 간단한 겹침 2D 영역으로 나누어집니다. 결과 영역은 겹치지 않는 하나의 윤곽선만 가지므로 프로세스의 마지막 단계가 크게 단순화됩니다.
• 내비게이션 폴리곤은 먼저 경계를 추적한 다음 이를 단순화하여 영역에서 벗겨집니다. 최종적으로 생성된 폴리곤은 삼각형으로 변환되어 경로 찾기와 공간 추론에 완벽하게 적합합니다.

Recast 생성 프로세스는 일반적으로 세계에서 보이는 기하학적 구조에서 직접 작동합니다. 이는 일반적으로 좋은 일인데, 세계 기하학 구조가 대개 콜라이더보다 더 자세하기 때문입니다. 그러나 콜라이더를 대신 래스터화하도록 지정할 수 있습니다. 매우 자세한 세계 기하학 구조가 있는 경우, 이렇게 하면 그래프 스캔 및 업데이트 속도가 빨라질 수 있습니다.

수동 편집을 위한 내보내기

에디터에는 생성된 그래프를 .obj 파일로 내보내는 버튼이 있습니다. 보통 생성 프로세스는 게임에 직접 사용하기에 충분하지만, 일부 경우에는 세부 사항을 편집하고 싶을 수 있습니다. 이때 그래프를 .obj 파일로 내보내고, 선호하는 3D 애플리케이션에서 열어 편집한 후 Unity가 가져올 수 있는 메쉬로 내보낼 수 있습니다. 그런 다음 해당 메쉬를 네비메쉬 그래프에서 사용할 수 있습니다.

많은 3D 모델링 프로그램이 다른 축 시스템을 사용하기 때문에 (Unity는 X=오른쪽, Y=위, Z=앞을 사용) 회전과 스케일링을 올바르게 설정하는 것이 까다로울 수 있습니다. 예를 들어, 블렌더에서는 먼저 .obj 임포터를 사용하여 메쉬를 가져옵니다. 설정에서 축과 관련된 사항은 변경하지 마십시오. 그런 다음 메쉬를 선택하고 변환 탭을 열어(보통 3D 뷰 오른쪽의 얇은 도구 모음) Scale -> Z를 -1로 설정합니다. S(스케일) 단축키를 사용하여 변환하면 어떤 이유에서인지 Z와 Y가 모두 -1로 설정됩니다. 필요한 편집을 한 다음 .obj 파일로 내보내어 Unity 프로젝트의 어딘가에 저장합니다. 하지만 이번에는 "Forward"라는 설정을 "Z forward"로 변경합니다(기본값은 -Z로 설정되어 있음).

Grid Graph, layered worlds를 지원합니다.

GridGraph는 많은 면에서 훌륭하며, 신뢰성이 높고 구성 및 런타임 동안 업데이트가 용이합니다. 그러나 다층 구조의 세계, 예를 들어 여러 층이 있는 건물을 지원하지 않는다는 단점이 있습니다. 이 점에서 이 그래프 유형이 유용합니다. 이 그래프는 기본적으로 GridGraph와 동일한 기능을 지원하지만, 다층 구조도 지원합니다. 일반 GridGraph보다 메모리를 더 많이 사용하지만, 그 외에는 동등합니다.

Inspector

Shape

그리드 그래프 인스펙터의 레이아웃을 Unity 에디터에서 결정합니다.

그리드 그래프는 일반 그리드, 아이소메트릭 그리드 또는 육각형 그리드로 설정할 수 있습니다. 각 모드는 약간 다른 인스펙터 레이아웃을 사용합니다. 인스펙터에서 모양을 변경하면 관련 필드가 자동으로 적절한 값으로 설정됩니다. 예를 들어, 모양을 육각형으로 설정하면 neighbours 필드가 자동으로 6으로 설정됩니다.

이 필드는 에디터에서만 사용되며 게임의 나머지 부분에는 전혀 영향을 미치지 않습니다.

인스펙터에서처럼 그리드 모양을 변경하려면 SetGridShape 메서드를 사용할 수 있습니다.

2D

그래프가 2D 모드인지 설정하거나 가져옵니다.

Align to tilemap (grid)

이 그리드를 주어진 타일맵이나 그리드 레이아웃에 맞춥니다.

게임에서 타일맵을 렌더링에 사용하고 그래프가 정확히 동일한 방식으로 배치되도록 하려면 매우 유용합니다. 그리드 매개변수를 수동으로 일치시키는 것은 경우에 따라 상당히 까다로울 수 있습니다.

인스펙터는 장면에서 타일맵을 감지하면 타일맵에 맞추는 버튼을 자동으로 표시합니다. 타일맵이 감지되지 않으면 버튼이 숨겨집니다.

Width

노드 단위로 그리드의 너비를 설정합니다.

그리드 그래프는 일반적으로 너비가 10에서 500 노드 정도이지만, 기본적으로 최대 1024 노드 너비까지 가능합니다. 매우 고해상도의 그리드가 필요하다면 대신 리캐스트 그래프를 사용하는 것이 좋습니다.

이 값은 A* 인스펙터 -> 최적화 탭에서 ASTAR_LARGER_GRIDS가 활성화되지 않는 한 최대 1024로 고정됩니다.

Depth

노드 단위로 그리드의 깊이(높이)를 설정합니다.

그리드 그래프는 일반적으로 너비가 10에서 500 노드 정도이지만, 기본적으로 최대 1024 노드 너비까지 가능합니다. 매우 고해상도의 그리드가 필요하다면 대신 리캐스트 그래프를 사용하는 것이 좋습니다.

이 값은 A* 인스펙터 -> 최적화 탭에서 ASTAR_LARGER_GRIDS가 활성화되지 않는 한 최대 1024로 고정됩니다.

Node size

월드 유닛으로 하나의 노드 크기를 설정합니다.

그리드 레이아웃에서는 그리드 사각형의 변의 길이를 나타냅니다.

육각형 레이아웃에서는 이 값이 육각형의 특정 차원에 대응하지 않습니다. 대신 ConvertNodeSizeToHexagonSize를 사용하여 육각형의 차원으로 변환할 수 있습니다.

Aspect ratio (isometric/advanced shape)

 X 축을 따라 그래프의 스케일링을 설정합니다.

그리드의 X 축과 Y 축에 다른 스케일을 적용하려는 경우에 사용해야 합니다.

이 옵션은 그래프 모양이 아이소메트릭 또는 고급으로 설정된 경우에만 인스펙터에 표시됩니다.

Isometric angle (isometric/advanced shape)

아이소메트릭 프로젝션에 사용할 각도(도 단위)를 설정합니다.

2D 아이소메트릭 게임을 만들고 있는 경우, 이 매개변수를 사용하여 그래프 레이아웃을 게임에 맞게 조정할 수 있습니다. 이 설정은 기본적으로 그래프를 대각선 방향으로 스케일링하여 아래와 같은 효과를 냅니다:

아이소메트릭 그래프의 원근법 보기.

아이소메트릭 그래프의 상단 보기. 이 이미지는 완전히 2D이며 원근법이 적용되지 않았습니다.

자주 사용되는 값에 대해서는 StandardIsometricAngle 및 StandardDimetricAngle을 참조하세요.

일반적으로 사용하고자 하는 각도는 30도 (또는 90-30 = 60도) 또는 atan(1/sqrt(2))로, 이는 대략 35.264도 (또는 90 - 35.264 = 54.736도)입니다. 또한 게임에 필요한 방향을 얻기 위해 그래프를 Y축을 중심으로 ±45도 회전할 수도 있습니다.

자세한 내용은 아래 링크된 위키피디아 페이지를 참조하세요.

Center

월드 공간에서 그리드의 중심점을 설정합니다.

그래프는 월드의 어느 위치에나 배치할 수 있습니다.

Rotation

그리드의 회전을 도 단위로 설정합니다.

노드는 회전의 X 및 Z 축을 따라 배치됩니다.

2D 게임의 경우 회전은 일반적으로 (-90, 270, 90)으로 설정됩니다. 그래프가 XY 평면에 맞춰져 있으면 인스펙터가 자동으로 2D 모드로 전환됩니다.

Connections

각 노드의 이웃 수를 설정합니다.

노드당 네 개, 여섯 개, 여덟 개의 연결이 가능합니다.

여섯 개의 연결은 주로 육각형 그래프를 위한 것입니다.

Cut corners

비활성화된 경우, 장애물의 코너를 자르지 않습니다.

이 값이 true이고 neighbours가 Eight로 설정된 경우, 연결에 의해 장애물의 코너를 자를 수 있습니다.

Max step height

연결을 활성화하기 위해 두 노드 간의 최대 y 좌표 차이입니다.

값을 0으로 설정하면 이 값을 무시합니다.

이 설정은 예를 들어, 그래프가 절벽이나 계단 주변에서 생성되는 방식에 영향을 미칩니다.

.

Account for slopes

 maxStepHeight를 위해 경사를 고려합니다.

이 옵션을 활성화하면 지형의 노멀을 사용하여 인접한 노드 간의 계단 크기를 보다 정확하게 추정할 수 있습니다.

비활성화된 경우 두 노드 간의 계산된 계단은 y 좌표 차이입니다. 이는 특히 가파른 경사 시작 부분에서 부정확할 수 있습니다.

아래 이미지에서 경사로 근처에서 발생하는 예를 볼 수 있습니다. 맨 위의 이미지에서는 경사로가 그래프의 나머지 부분과 연결되지 않아 우리가 원하는 결과가 아닙니다. 중간 이미지에서는 maxStepUsesSlope 를 비활성화한 상태에서 최대 계단 높이를 높이려는 시도가 있습니다. 그러나 이는 너무 많은 연결을 추가하게 되어, 에이전트가 측면에서 경사로를 올라갈 수 없게 됩니다. 마지막으로 맨 아래 이미지에서는 maxStepHeight 가 원래 값으로 복원되었지만  maxStepUsesSlope 가 활성화되었습니다. 이 구성은 경사로를 더 스마트하게 처리합니다. 이미지의 모든 값은 예제 값일 뿐이며, 씬에 따라 다를 수 있습니다.

Max slope

노드가 보행 가능하도록 하는 최대 경사도를 도 단위로 설정합니다.

Erosion iterations

그래프를 침식할 횟수를 설정합니다.

그래프를 침식하여 장애물에 여분의 여유 공간을 추가할 수 있습니다. 그래프에 절벽이 포함되어 있고, 침식 없이 보행 가능한 노드가 가장자리와 너무 가까운 경우 매우 편리합니다.

아래는 침식 반복 횟수가 0, 1, 2인 그래프를 보여주는 이미지입니다:

Erosion → Erosion Uses Tags

보행 가능성 대신 태그를 사용하여 침식합니다.

노드를 보행 불가능으로 표시하는 대신 침식에 태그를 사용합니다. 노드는 erosionFirstTag로 시작하여 순차적으로 태그가 지정됩니다. 태그 모드로 디버그하여 효과를 확인할 수 있습니다. 이 옵션을 활성화하면 Seeker 컴포넌트의 Valid Tags 필드를 사용하여 다양한 AI가 벽에 얼마나 가까이 접근할 수 있는지 설정할 수 있습니다.

Use 2D physics

Unity 2D Physics API를 사용합니다.

활성화하면 2D Physics API가 사용되고, 비활성화하면 3D Physics API가 사용됩니다.

이 설정은 콜라이더 유형을 3D 버전에서 해당하는 2D 버전으로 변경합니다. 예를 들어, 구형은 원형이 됩니다.

2D 물리학을 사용할 때 heightCheck 설정은 무시됩니다.

Collision testing

Enable Collision Testing

충돌 체크를 전환합니다.

Collider type

사용할 충돌 형태를 설정합니다.

Diameter

충돌을 확인할 때 캡슐 또는 구의 직경을 설정합니다.

충돌을 확인할 때 시스템은 노드 위치에서 특정 형태와 겹치는 콜라이더가 있는지 확인합니다. 형태는  type 필드에 의해 결정됩니다.

직경이 1이면 형태의 직경이 노드의 너비와 같음을 의미하며, 다른 말로 하면 nodeSize 와 같습니다.

type이 Ray로 설정된 경우, 이 설정은 아무런 영향을 미치지 않습니다.

Height/length

충돌을 확인할 때 캡슐의 높이 또는 레이의 길이를 설정합니다.

type이 Sphere로 설정된 경우, 이 설정은 아무런 영향을 미치지 않습니다.

Offset

충돌 검사를 수행할 지면 위의 높이를 설정합니다.

예를 들어, 지면이 y=0에 있고 collisionOffset = 2, type = Capsule, height = 3으로 설정된 경우, 물리 시스템은 하단 구형이 y=2에 중심을 두고 상단 구형이 y=2+3=5에 중심을 두는 캡슐 내에 콜라이더가 있는지 확인합니다.

type이 Sphere인 경우, 이 경우 구형의 중심은 y=2에 있게 됩니다.

Obstacle layer mask

장애물로 처리할 레이어를 설정합니다.

Preview

충돌 테스트 옵션에 대한 미리보기를 표시합니다.

왼쪽에서는 노드의 그리드로 구성된 그래프의 상단 뷰를 볼 수 있습니다. 오른쪽에서는 그래프의 측면 뷰를 볼 수 있습니다. 아래의 흰색 선은 그래프의 기준선이며, 작은 점으로 노드 위치가 표시됩니다. 2D 물리학을 사용할 때는 상단 뷰만 표시됩니다.

녹색 모양은 충돌 체크에 사용할 모양을 나타냅니다.

Height testing

Enable Height Testing

높이 체크를 전환합니다.

false로 설정하면 그리드는 평평해집니다.

2D 물리학을 사용할 때는 이 설정이 무시됩니다.

Ray length

높이를 확인할 때 사용할 높이 ('인스펙터에서 레이 길이')를 설정합니다.

아래 이미지가 시각화하듯이, 다른 레이 길이는 레이가 다른 물체에 닿게 할 수 있습니다. 이 거리는 그래프 평면에서 위로 측정됩니다.

Mask

높이 검사에 포함될 레이어를 설정합니다.

Thick raycast

굵은 레이캐스트를 전환합니다.

Unwalkable when no ground

높이 레이캐스트에서 지면을 찾지 못한 경우 노드를 보행 불가능으로 만듭니다.

높이 레이캐스트가 꺼져 있으면 이 설정은 아무런 영향을 미치지 않습니다.

Rules

Grid Graph 규칙에 대한 자세한 내용은 사용 가능한 규칙 목록을 확인하세요.

Other settings

Show surface

그래프의 표면을 표시합니다.

각 노드는 사각형으로 그려집니다 (예: 육각형 그래프 모드가 활성화된 경우 제외).

Show outline

Unity 에디터에서 그리드 노드의 윤곽선을 표시합니다.

Show connections

Unity 에디터에서 그리드 노드 간의 연결을 표시합니다.

Initial penalty

모든 노드에 적용할 기본 패널티를 설정합니다.

이 스크립트를 콜라이더가 있는 장애물에 부착하여 주변 그래프의 동적 업데이트를 가능하게 합니다.

객체가 최소한 updateError 월드 유닛만큼 이동하거나 회전했을 때 AstarPath.UpdateGraphs 를 호출하여 주변 그래프를 업데이트합니다.

DynamicGridObstacle  컴포넌트가 부착된 게임 오브젝트에 부착된 콜라이더의 경계 내에서만 그래프가 업데이트되므로, 자식 콜라이더가 게임 오브젝트의 콜라이더 경계를 벗어나지 않도록 하십시오.

부착된 콜라이더의 경계 상자가 최소  updateError 월드 유닛만큼 변경(이동/확장 등)되거나, 게임 오브젝트가 회전하여 객체의 가장 바깥쪽 지점이 최소 updateError 월드 유닛만큼 이동한 경우 업데이트가 트리거됩니다.

이 스크립트는 2D 콜라이더와 일반 3D 콜라이더 모두에서 작동합니다.

checkTime

float checkTime = 0.2F

AstarPath.batchGraphUpdates 가 활성화된 경우, checkTime을 AstarPath.graphUpdateBatchingInterval 보다 훨씬 낮게 설정하는 것은 불필요한 그래프 업데이트를 추가할 뿐이므로 유익하지 않습니다.

실시간 초 단위 (Time.realtimeSinceStartup 기준).

updateError

float updateError = 1

그래프 업데이트를 트리거하기 위해 콜라이더의 바운딩 박스 축 중 하나를 따라 세계 단위로 최소 변화.

노드 그리드를 생성합니다.

GridGraph는 이름 그대로 노드를 그리드 패턴으로 생성합니다.

그리드 그래프는 이미 그리드 기반의 세계를 가지고 있을 때 매우 유용합니다. 그러나 자유형 세계에서도 잘 작동합니다.

특징

• 어떤 씬이든 최소한의 설정만으로 좋은 그래프를 생성할 수 있습니다.
• 예측 가능한 패턴.
• 그리드 그래프는 페널티와 태그와 잘 작동합니다.
• 런타임 중 그래프의 일부를 업데이트할 수 있습니다.
• 그래프 업데이트가 빠릅니다.
• 그래프 스캔이 비교적 빠릅니다.
• 라인캐스팅을 지원합니다.
• 퍼널 수정자를 지원합니다.
• 2D 및 3D 물리학을 모두 지원합니다.
• 등각 및 육각형 노드 레이아웃을 지원합니다.
• 제공된 이미지에서 페널티 및 보행 가능 값을 적용할 수 있습니다.
• 경사도에 따라 노드를 보행 가능 또는 불가능하게 만들 수 있어 지형에 적합합니다.
• 단일 레이어만 지원하지만, 더 많은 레이어가 필요하면 LayerGridGraph를 사용할 수 있습니다.

Inspector

Shape

Unity 에디터에서 그리드 그래프 인스펙터의 레이아웃을 결정합니다.

그리드 그래프는 일반 그리드, 등각 그리드 또는 육각형 그리드로 설정할 수 있습니다. 각 모드는 약간 다른 인스펙터 레이아웃을 사용합니다. 인스펙터에서 모양을 변경하면 관련 필드가 자동으로 적절한 값으로 설정됩니다. 예를 들어, 모양을 육각형으로 설정하면 이웃 필드가 자동으로 여섯 개로 설정됩니다.

이 필드는 에디터에서만 사용되며 게임의 나머지 부분에는 전혀 영향을 미치지 않습니다.

인스펙터에서와 같이 그리드 모양을 변경하려면 SetGridShape 메서드를 사용할 수 있습니다.

2D

그래프가 2D 모드인지 여부를 가져오거나 설정합니다.

Align to tilemap(grid)

지정된 타일맵 또는 그리드 레이아웃에 이 그리드를 정렬합니다.

게임에서 타일맵을 사용하여 렌더링하는 경우 그래프가 정확히 동일하게 배치되도록 하는 것이 매우 유용합니다. 경우에 따라 그리드 매개변수를 수동으로 맞추는 것은 상당히 까다로울 수 있습니다.

씬에서 타일맵이 감지되면 인스펙터에 타일맵에 정렬하는 버튼이 자동으로 표시됩니다. 타일맵이 감지되지 않으면 버튼이 숨겨집니다.

width

노드 단위의 그리드 너비.

그리드 그래프는 일반적으로 너비가 10~500 노드입니다. 그러나 기본적으로 최대 1024 노드 너비까지 가능합니다. 매우 높은 해상도의 그리드가 필요하다면 대신 리캐스트 그래프를 사용하는 것이 좋습니다.

이 값은 A* 인스펙터 -> 최적화 탭에서 ASTAR_LARGER_GRIDS가 활성화되지 않는 한 최대 1024로 제한됩니다.

Depth

노드 단위의 그리드 깊이(높이).

그리드 그래프는 일반적으로 너비가 10~500 노드입니다. 그러나 기본적으로 최대 1024 노드 너비까지 가능합니다. 매우 높은 해상도의 그리드가 필요하다면 대신 리캐스트 그래프를 사용하는 것이 좋습니다.

이 값은 A* 인스펙터 -> 최적화 탭에서 ASTAR_LARGER_GRIDS가 활성화되지 않는 한 최대 1024로 제한됩니다.

Node size
월드 유닛에서 하나의 노드 크기.

그리드 레이아웃의 경우, 이는 그리드 사각형의 한 변의 길이입니다.

육각형 레이아웃의 경우, 이 값은 육각형의 특정 차원과 일치하지 않습니다. 대신, ConvertNodeSizeToHexagonSize 를 사용하여 이를 육각형의 차원으로 변환할 수 있습니다.

Aspect ratio (isometric/advanced shape)
X축을 따라 그래프의 스케일링.

그리드의 X축과 Y축에 다른 스케일을 원할 때 사용해야 합니다.

이 옵션은 그래프 모양이 등각 또는 고급으로 설정된 경우에만 인스펙터에 표시됩니다.

Isometric angle (isometric/advanced shape)

등각 투영에 사용할 각도(도 단위).

2D 등각 게임을 만드는 경우 이 매개변수를 사용하여 그래프의 레이아웃을 게임에 맞게 조정할 수 있습니다. 이 매개변수는 그래프를 대각선 중 하나를 따라 스케일링하여 다음과 같은 결과를 만들어냅니다:

- 등각 그래프의 원근감 있는 보기.

- 등각 그래프의 탑다운 보기. 이 이미지는 완전히 2D로, 원근감이 없습니다.

자주 사용되는 값으로는  StandardIsometricAngle 과 StandardDimetricAngle 이 있습니다.

일반적으로 사용하고자 하는 각도는 30도(또는 90-30 = 60도) 또는 atan(1/sqrt(2))으로 약 35.264도(또는 90 - 35.264 = 54.736도)입니다. 게임에 필요한 방향을 얻기 위해 그래프를 Y축을 중심으로 ±45도 회전할 수도 있습니다.

자세한 내용은 아래 위키피디아 페이지를 참조하세요.

Center

월드 공간에서 그리드의 중심점.

그래프는 월드 내 어디에나 위치할 수 있습니다.

Rotation

그리드의 회전 각도(도 단위).

노드는 회전의 X 및 Z 축을 따라 배치됩니다.

2D 게임의 경우, 회전은 일반적으로 (-90, 270, 90)으로 설정됩니다. 그래프가 XY 평면과 정렬되면 인스펙터는 자동으로 2D 모드로 전환됩니다.

Connections

각 노드의 이웃 수.

노드당 연결 수는 네 개, 여섯 개, 여덟 개 중 하나입니다.

여섯 개의 연결은 주로 육각형 그래프를 위한 것입니다.

Cut corners

비활성화된 경우 장애물의 모서리를 자르지 않습니다.

이 설정이 true이고 neighbours가 Eight로 설정된 경우, 연결에 의해 장애물 모서리를 자를 수 있습니다.

Max step height

두 노드 간 연결을 활성화하기 위한 최대 Y 좌표 차이.

값을 무시하려면 0으로 설정하세요.

이 설정은 예를 들어, 그래프가 단차와 계단 주변에서 어떻게 생성되는지에 영향을 미칩니다.

Account for slopes

경사도를 maxStepHeight 에 반영합니다.

이 옵션을 활성화하면 지형의 노말을 사용하여 인접한 노드 간의 단계 크기를 더 정확하게 추정합니다.

이 옵션이 비활성화되면 두 노드 간의 계산된 단계는 Y 좌표 차이로 결정됩니다. 특히 가파른 경사에서 시작할 때 부정확할 수 있습니다.

아래 이미지에서 램프 근처에서 발생하는 예를 볼 수 있습니다. 맨 위의 이미지는 램프가 그래프의 나머지 부분과 연결되지 않아 원하는 결과가 아닙니다. 중간 이미지는  maxStepUsesSlope 를 비활성화한 상태에서  maxStepHeight  를 높이려고 시도한 예입니다. 그러나 이 경우 너무 많은 연결이 추가되어 에이전트가 측면에서 램프로 올라갈 수 없게 됩니다. 마지막 이미지에서는 maxStepUsesSlope 를 원래 값으로 복원하고 maxStepUsesSlope를 활성화한 예입니다. 이 구성은 램프를 더 스마트하게 처리합니다. 모든 값은 예시 값일 뿐이며, 씬에 따라 다를 수 있습니다.

Max slope

노드가 보행 가능하도록 하는 최대 경사도(도 단위).

Erosion iterations

그래프를 침식할 횟수.

그래프는 장애물에 추가 마진을 추가하기 위해 침식될 수 있습니다. 특히 그래프에 단차가 포함되어 있고, 침식 없이 보행 가능한 노드가 가장자리에 너무 가까운 경우에 매우 유용합니다.

아래 이미지는 0, 1, 2 회의 침식 반복을 보여줍니다:

Erosion → Erosion Uses Tags

침식에 보행 가능성을 대신하여 태그 사용.

노드를 보행 불가능으로 표시하는 대신 태그를 사용하여 침식이 이루어집니다. 노드는 erosionFirstTag로 시작하여 증가하는 순서로 태그가 지정됩니다. 효과를 확인하려면 태그 모드로 디버그하십시오. 이 옵션을 활성화하면 Seeker 컴포넌트의 Valid Tags 필드를 사용하여 다양한 AI가 벽에 얼마나 가까이 접근할 수 있는지 설정할 수 있습니다.

Use 2D physics

Unity 2D 물리 API 사용.

이 옵션을 활성화하면 2D 물리 API가 사용되며, 비활성화하면 3D 물리 API가 사용됩니다.

이 설정은 콜라이더 유형을 3D 버전에서 해당하는 2D 버전으로 변경합니다.(  type 참조) 예를 들어, 구 모양이 원으로 변경됩니다.

2D 물리가 사용될 때는 heightCheck 설정이 무시됩니다.

Collision testing

Collider type

사용할 충돌 형태.

Diameter

충돌을 확인할 때 캡슐 또는 구의 지름.

충돌을 확인할 때 시스템은 노드의 위치에서 특정 형태와 겹치는 콜라이더가 있는지 확인합니다. 형태는  type 필드에 의해 결정됩니다.

지름이 1인 경우, 형태의 지름은 노드의 너비와 같으며, 즉 nodeSize 와 동일합니다.

type 이 Ray로 설정된 경우, 이 설정은 아무런 영향을 미치지 않습니다.

Height/length

충돌을 확인할 때 캡슐의 높이 또는 광선의 길이.

type이 Sphere로 설정된 경우, 이 설정은 아무런 영향을 미치지 않습니다.

Offset

충돌 확인을 수행할 지면 위의 높이.

예를 들어, 지면이 y=0에서 발견되었고, collisionOffset = 2, type = Capsule, height = 3으로 설정된 경우, 물리 시스템은 아래쪽 구의 중심이 y=2에 있고, 위쪽 구의 중심이 y=2+3=5에 있는 캡슐 내에 콜라이더가 있는지 확인합니다.

type이 Sphere인 경우, 구의 중심은 y=2에 위치하게 됩니다.

Obstacle layer mask

장애물로 취급할 레이어.

Preview

충돌 테스트 옵션의 미리보기를 표시합니다.

왼쪽에서는 노드 그리드가 있는 그래프의 탑다운 뷰를 볼 수 있습니다. 오른쪽에서는 그래프의 측면 뷰를 볼 수 있습니다. 아래쪽의 흰 선은 그래프의 기본이며, 작은 점으로 노드 위치가 표시됩니다. 2D 물리를 사용하는 경우, 탑다운 뷰만 표시됩니다.

녹색 형상은 충돌 검사용으로 사용될 형상을 나타냅니다.

Height testing

Ray length

높이를 확인할 때의 시작 높이('인스펙터에서의 ray length').

아래 이미지가 시각화하는 것처럼, 다양한 광선 길이는 광선이 다른 것에 맞도록 할 수 있습니다. 거리는 그래프 평면에서 위쪽으로 측정됩니다.

Mask

높이 확인에 포함될 레이어.

Thick raycast

두꺼운 레이캐스트를 토글합니다.

Unwalkable when no ground

높이 레이캐스트로 지면을 찾지 못했을 때 노드를 보행 불가능하게 만듭니다.

높이 레이캐스트가 꺼져 있으면 이 설정은 아무런 영향을 미치지 않습니다.

Rules

Grid Graph Rules에서 사용 가능한 규칙 목록을 확인하세요.

Other settings

Show surface

그래프의 표면을 표시합니다.

각 노드는 사각형으로 그려집니다 (예: 육각형 그래프 모드가 활성화된 경우 제외).

Show outline

Unity 에디터에서 그리드 노드의 윤곽선을 표시합니다.

Show connections

Unity 에디터에서 그리드 노드 간의 연결을 표시합니다.

Initial penalty

모든 노드에 적용할 기본 페널티.

Updating the graph during runtime

IUpdatableGraph 인터페이스를 구현하는 모든 그래프는 런타임 중에 업데이트할 수 있습니다. 그리드 그래프의 경우, 전체 재스캔과 같은 지연을 유발하지 않고 그리드의 일부분만 업데이트할 수 있기 때문에 매우 유용한 기능입니다.

예를 들어, 씬에 장애물을 새로 생성했으며 그 장애물이 생성된 그리드를 업데이트하려면 다음과 같이 할 수 있습니다:

AstarPath.active.UpdateGraphs(obstacle.collider.bounds);

여기서 `obstacle`은 방금 인스턴스화된 GameObject입니다.

보시다시피, `UpdateGraphs` 함수는 `Bounds` 매개변수를 받아서 모든 업데이트 가능한 그래프에 업데이트 호출을 보냅니다.

그리드 그래프는 해당 경계 상자 내에서 모든 것이 변경될 수 있다고 가정하고, 영향을 받을 가능성이 있는 모든 노드를 다시 계산합니다. 따라서 경계 상자로 덮인 노드들보다 조금 더 많은 노드를 업데이트할 수 있습니다.

Hexagonal graphs

그래프는 간단한 설정으로 육각형 그래프처럼 작동하도록 구성할 수 있습니다. 그리드 그래프에는 Shape 드롭다운이 있습니다. 이를 'Hexagonal'로 설정하면 그래프가 육각형 그래프처럼 작동합니다. 종종 그래프를 +45도 또는 -45도 회전하고 싶을 것입니다.

코드를 사용하여 구성

그리드 그래프는 코드를 통해 런타임에 완전히 추가 및 구성할 수 있습니다.

// 모든 그래프 데이터를 보유합니다.
AstarData data = AstarPath.active.data;

// 그리드 그래프를 생성합니다.
GridGraph gg = data.AddGraph(typeof(GridGraph)) as GridGraph;

// 일부 값을 사용하여 그리드 그래프를 설정합니다.
int width = 50;
int depth = 50;
float nodeSize = 1;

gg.center = new Vector3(10, 0, 0);

// 위의 값으로 내부 크기를 업데이트합니다.
gg.SetDimensions(width, depth, nodeSize);

// 모든 그래프를 스캔합니다.
AstarPath.active.Scan();

나무 콜라이더

Unity는 게임이 시작될 때만 나무 콜라이더를 런타임에 생성합니다. 이러한 이유로, 그리드 그래프는 플레이 모드가 아닌 경우 나무 콜라이더를 감지하지 않지만 게임이 시작되면 감지하게 됩니다. 그래도 나무 콜라이더를 감지하지 못하면 나무에 실제로 콜라이더가 부착되어 있는지, 그리고 나무 프리팹이 올바른 레이어에 있는지 확인하십시오(해당 레이어는 'Collision Testing' 마스크에 포함되어야 합니다).