Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

애니메이션 패널

Godot에는 XR 시스템의 일부로 액션 맵 기능이 있습니다. 현재 이 시스템은 OpenXR 모듈의 일부입니다. 가까운 시일 내에 WebXR을 여기에 포함시킬 계획이 있으므로 이 문서에서는 이를 XR 액션 맵 시스템이라고 부릅니다. OpenXR의 내장 액션 맵 시스템을 제공되는 것과 거의 동일하게 구현합니다.

XR 액션 맵 시스템은 XR 컨트롤러에 대한 입력, 위치 데이터 및 출력을 게임/응용 프로그램에 노출합니다. 이는 게임/애플리케이션에 맞게 조정할 수 있는 명명된 작업을 노출하고 이를 XR 장치의 실제 입력 및 출력에 바인딩함으로써 수행됩니다.

XR 작업 맵은 현재 OpenXR 모듈의 일부이므로 이를 노출하려면 프로젝트 설정에서 OpenXR을 활성화해야 합니다.

그러면 화면 하단에서 XR Action Map 인터페이스를 찾을 수 있습니다.

참고

Godot의 내장 입력 시스템은 XR 액션 맵 시스템과 많은 공통점을 가지고 있습니다. 실제로 우리의 원래 아이디어는 기존 입력 시스템에 기능을 추가하고 데이터를 OpenXR 동작 맵 시스템에 노출하는 것이었습니다. 우리는 어느 시점에서 그 아이디어를 다시 검토할 수도 있지만, 알고 보니 극복해야 할 문제가 너무 많았습니다. 몇 가지 예를 들면 다음과 같습니다.

• Godot의 입력 시스템은 주로 버튼 입력을 중심으로 하며, XR은 트리거, 축, 포즈 및 햅틱(출력)을 믹스에 추가합니다. 이는 일반 컨트롤러에서 작동하지 않거나 현재 접근 방식과 대조되는 기능으로 입력 시스템을 크게 복잡하게 만듭니다. 이것이 대다수 Godot 사용자들에게 혼란을 초래할 것이라고 느꼈습니다.

• Godot의 입력 시스템은 구문 분석되고 방출 작업을 트리거하는 원시 입력 데이터와 함께 작동합니다. 이 입력 데이터는 최종 사용자가 사용할 수 있습니다. OpenXR은 원시 데이터를 완전히 숨기고 모든 구문 분석을 수행합니다. 우리는 이미 구문 분석된 작업 데이터에만 액세스할 수 있습니다. 이러한 불일치로 인해 의심하지 않는 사용자가 XR 장치를 일반 입력 장치로 사용하려고 할 때 버그가 발생할 수 있습니다.

• Godot의 입력 시스템은 런타임에 동작에 바인딩되는 입력에 대한 변경을 허용하지만 OpenXR은 그렇지 않습니다.

• Godot의 입력 시스템은 OpenXR에서는 의미가 없는 장치 ID를 기반으로 합니다.

이는 기존 입력과 XR 컨트롤러를 혼합하는 게임/애플리케이션이 분리된다는 의미입니다. 대부분의 응용 프로그램에서는 둘 중 하나가 사용되며 이는 문제로 간주되지 않습니다. 결국 시스템의 한계다.

빛 애니메이션

액션 맵 파일이 없으면 Godot는 자동으로 기본 액션 맵을 생성합니다.

경고

이 기본 맵은 개발자가 XR 게임/응용 프로그램을 Godot 3에서 Godot 4로 포팅하는 데 도움을 주기 위해 설계되었습니다. 결과적으로 이 맵은 기본적으로 기본적으로 지원되는 모든 컨트롤러에서 알려진 모든 입력을 일대일 작업에 바인딩합니다. 이는 액션 맵을 설정하는 좋은 예가 아닙니다. 이는 새로운 개발자가 Godot XR에 익숙해지고 싶을 때 출발점을 가질 수 있도록 해줍니다. 이를 통해 게임/애플리케이션에 대한 적절한 액션 맵을 먼저 디자인할 필요가 없습니다.

이 연습에서는 빈 작업 맵으로 시작하겠습니다. 휴지통 아이콘을 눌러 상단의 "Godot 액션 세트" 항목을 삭제할 수 있습니다. 이렇게 하면 모든 작업이 지워집니다. 설정하고 싶지 않은 컨트롤러를 제거할 수도 있습니다. 이에 대해서는 나중에 자세히 설명합니다.

액션 세트

참고

자세히 알아보기 전에 이 문서 전체에서 사용되는 XR 런타임이라는 용어를 살펴보겠습니다. XR 런타임이란 AR 또는 VR 헤드셋을 제어하고 상호 작용하는 소프트웨어를 의미합니다. 그런 다음 XR 런타임은 OpenXR과 같은 API를 통해 이를 우리에게 공개합니다. 그래서:

• Steam의 경우 SteamVR입니다.

• 데스크톱 Meta의 경우 이는 Oculus 클라이언트입니다(Quest 링크를 사용하는 경우 포함).

• Meta on Quest의 경우 이는 Quest의 기본 OpenXR 클라이언트입니다.

• Linux에서는 Monado 등이 될 수 있습니다.

액션 맵을 사용하면 액션을 세트로 구성할 수 있습니다. 각 세트는 자체적으로 활성화하거나 비활성화할 수 있습니다.

여기서의 개념은 다양한 시나리오에서 바인딩을 제공하는 다양한 세트를 가질 수 있다는 것입니다. 당신은 할 수 있습니다:

• 걸어다닐 때를 위한 Character control 세트,

• 차량 운행 시를 위한 Vehicle control 세트,

• 메뉴가 열려 있을 때 설정된 Menu.

그러면 게임/애플리케이션의 현재 상태에 적용 가능한 액션 세트만 활성화될 수 있습니다.

이는 컨트롤러의 동일한 입력을 다른 작업에 바인딩하려는 경우 특히 중요합니다. 예를 들어:

• Character control 세트에서 Jump 작업을 수행할 수 있습니다.

• Vehicle control 세트에서 Accelerate 작업을 수행할 수 있습니다.

• Menu 세트에 Select 작업이 있을 수 있습니다.

모두 컨트롤러의 트리거에 바인딩됩니다.

OpenXR은 입력 또는 출력을 단일 작업에만 바인딩합니다. 동일한 입력 또는 출력이 여러 작업에 바인딩된 경우 우선 순위가 가장 높은 활성 작업 집합의 작업이 업데이트/사용됩니다. 따라서 위의 예에서는 하나의 작업 세트만 활성화되는 것이 중요합니다.

첫 번째 XR 게임/응용 프로그램의 경우 단일 작업 세트로 시작하고 과도한 엔지니어링을 하지 않는 것이 좋습니다.

따라서 이 문서의 연습에서는 ``my_first_action_set``라는 단일 작업 세트를 만듭니다. Add action set 버튼을 눌러 이 작업을 수행합니다.

가장 일반적인 사용 케이스는 다음과 같습니다:

색상	값	설명
1	my_first_action_set	이는 액션 세트의 내부 이름입니다. OpenXR은 이 이름에 크기 이외의 특정 제한 사항을 지정하지 않지만 일부 XR 런타임은 공백이나 특수 문자를 좋아하지 않습니다.
2	나의 첫 번째 액션 세트	이는 사람이 읽을 수 있는 액션 세트 이름입니다. 일부 XR 런타임은 구성 대화 상자 등에서 최종 사용자에게 이 이름을 표시합니다.
3	0	이것이 액션 세트의 우선순위입니다. 여러 활성 작업 세트에 동일한 컨트롤러의 입력 또는 출력에 바인딩된 작업이 있는 경우 우선 순위가 가장 높은 작업 세트에 따라 업데이트되는 작업이 결정됩니다.

작업

XR 액션 맵에서 액션은 게임/애플리케이션이 상호 작용하는 엔터티입니다. 예를 들어 Shoot 작업을 정의할 수 있으며 해당 작업에 바인딩된 입력은 씬의 관련 XRController3D 노드에서 button_pressed 시그널를 트리거합니다. 시그널의 name 매개변수로 ``Shoot``를 사용합니다.

작업의 현재 상태를 폴링할 수도 있습니다. 예를 들어 XRController3D <class_xrcontroller3d>`에는 ``is_button_pressed` 메서드가 있습니다.

작업은 입력과 출력 모두에 사용될 수 있으며 각 작업에는 해당 동작을 정의하는 유형이 있습니다.

• Bool 유형은 버튼과 같은 개별 입력에 사용됩니다.

• Float 유형은 트리거와 같은 아날로그 입력에 사용됩니다.

이 두 가지는 상호 교환이 가능한 유일한 것이므로 특별합니다. OpenXR은 Bool 및 Float 입력 및 작업 간의 변환을 처리합니다. XRController3D 노드에서 get_float 메서드를 호출하여 Float 유형 작업의 값을 얻을 수 있습니다. 변경되면 input_float_changed 시그널를 방출합니다.

참고

아날로그 입력이 버튼으로 쿼리되는 경우 임계값이 적용됩니다. 이 임계값은 현재 XR 런타임에 의해서만 관리됩니다. 향후 이러한 임계값에 대해 어느 정도 제어할 수 있도록 Godot를 확장할 계획이 있습니다.

Vector2 유형은 입력을 축 입력으로 정의합니다. 터치패드, 썸스틱 및 유사한 입력은 벡터로 노출됩니다. XRController3D 노드에서 get_vector2 메서드를 호출하여 Vector2 유형 작업의 값을 얻을 수 있습니다. 변경되면 input_vector2_changed 시그널를 방출합니다.

Pose 유형은 공간적으로 추적된 입력을 정의합니다. OpenXR에서는 aim, grip 및 palm``와 같은 여러 "포즈" 입력을 사용할 수 있습니다. :ref:`XRController3D <class_xrcontroller3d>` 노드는 이 노드의 ``pose 속성에 할당된 포즈 동작을 기반으로 자동으로 배치됩니다. 포즈에 대해서는 나중에 자세히 설명합니다.

참고

Godot의 OpenXR 구현은 Skeleton``라는 특수 포즈도 노출합니다. 이는 손 추적 구현의 일부입니다. 이 포즈는 액션 맵 시스템 외부에서 지원되는 ``skeleton 액션을 통해 노출됩니다. 따라서 손 추적이 지원되는 경우 항상 존재합니다. 이 포즈를 사용하기 위해 액션을 바인딩할 필요는 없습니다.

마지막으로 유일한 출력 유형은 ``Haptic``이며 이를 통해 컨트롤러 진동과 같은 햅틱 피드백의 강도를 설정할 수 있습니다. 컨트롤러는 여러 개의 햅틱 출력을 가질 수 있으며 햅틱 조끼에 대한 지원이 OpenXR에 제공됩니다.

이제 조준 포즈에 액션을 추가해 보겠습니다. 액션 세트에 대해 + 버튼을 클릭하면 됩니다.

가장 일반적인 사용 케이스는 다음과 같습니다:

색상	값	설명
1	aim_pose	이는 작업의 내부 이름입니다. OpenXR은 크기 외에 이 이름에 대한 특정 제한을 지정하지 않지만 일부 XR 런타임은 공백이나 특수 문자를 좋아하지 않습니다.
2	조준 포즈	이는 사람이 읽을 수 있는 작업 이름입니다. 일부 XR 런타임은 구성 대화 상자 등에서 최종 사용자에게 이 이름을 표시합니다.
3	포즈	명명된 타입

OpenXR은 컨트롤러에 일반적으로 사용할 수 있는 여러 바인딩 가능한 입력 포즈를 정의합니다. 다양한 컨트롤러에 대해 포즈가 지원되는 규칙은 없습니다. OpenXR이 현재 정의하는 포즈는 다음과 같습니다.

• 대부분의 컨트롤러의 조준 포즈는 컨트롤러 약간 앞쪽에 위치하며 앞으로 향합니다. 이것은 레이저 포인터에 사용하거나 무기의 총구를 정렬하는 데 좋은 자세입니다.

• 대부분의 컨트롤러에서 그립 자세는 그립 버튼이 컨트롤러에 있는 위치에 있습니다. 이 포즈의 방향은 컨트롤러마다 다르며 다른 XR 런타임의 동일한 컨트롤러에 대해서도 다를 수 있습니다.

• 대부분의 컨트롤러에서 손바닥 자세는 컨트롤러를 잡고 있는 손바닥 중앙에 위치합니다. 이는 모든 XR 런타임에서 사용할 수 없는 새로운 포즈입니다.

참고

수동 추적을 사용하는 경우 현재 서로 다른 XR 런타임 간의 구현에 큰 차이가 있습니다. 결과적으로 액션 맵은 현재 손 추적에 적합하지 않습니다. 이에 대한 작업이 진행 중이므로 계속 지켜봐 주시기 바랍니다.

매우 간단한 슈팅 게임/애플리케이션에 대한 작업 목록을 완성해 보겠습니다.

우리가 추가한 작업은 다음과 같습니다.

• 사용자가 일반적인 실내 규모 추적 외부에서 이동할 수 있도록 하는 움직임입니다.

• Grab은 사용자가 무언가를 잡고 싶어한다는 것을 감지합니다.

• Shoot은 사용자가 들고 있는 무기를 발사하기를 원한다는 것을 감지합니다.

• 햅틱 피드백을 출력할 수 있는 햅틱입니다.

이제 우리는 왼손과 오른손을 구별하지 않는다는 점에 유의하십시오. 이는 다음 단계에서 결정되는 사항입니다. 우리는 동일한 액션을 양손에 바인딩할 수 있는 방식으로 액션 시스템을 구현했습니다. 적절한 XRController3D 노드는 시그널를 방출합니다.

경고

잡기와 발사 모두에 Bool 유형을 사용했습니다. 앞서 언급했듯이 OpenXR은 아날로그 컨트롤에서 자동 변환을 수행하지만 현재 모든 XR 런타임이 합리적인 임계값을 적용하는 것은 아닙니다.

트리거 및 그립 버튼과 상호 작용할 때 해결 방법으로 Float 유형을 사용하고 자체 임계값을 적용하는 것이 좋습니다.

A/B/X/Y 및 아날로그 옵션이 없는 유사한 버튼의 경우 Bool 유형이 제대로 작동합니다.

참고

동일한 프로필의 동일한 컨트롤러에 대한 여러 입력에 동일한 작업을 바인딩할 수 있습니다. 이 경우 XR 런타임은 입력을 결합하려고 시도합니다.

• Bool 입력의 경우 버튼 사이에서 OR 작업을 수행합니다.

• Float 입력의 경우 바인딩된 입력 중 가장 높은 값을 사용합니다.

• Pose 입력의 동작은 정의되지 않았지만 첫 번째 바인딩된 입력이 사용될 가능성이 높습니다.

동일한 액션 세트의 여러 액션을 동일한 컨트롤러 입력에 바인딩하면 안 됩니다. 이렇게 하거나 여러 액션 세트에서 액션을 바인딩했지만 우선순위가 겹치는 경우 동작이 정의되지 않습니다. XR 런타임은 단순히 액션 맵을 받아들이지 않거나 선착순으로 이를 받아들일 수도 있습니다.

이 시나리오가 타당하기 때문에 우리는 여러 작업을 동일한 출력에 바인딩하는 것과 관련된 제한 사항을 계속 조사하고 있습니다. OpenXR 사양에서는 이를 허용하지 않는 것 같습니다.

이제 기본 동작을 정의했으므로 이를 연결할 차례입니다.

프로파일러

OpenXR에서 컨트롤러 바인딩은 소위 "상호작용 프로필"에 캡처됩니다. 공간을 덜 차지하기 때문에 "프로필"로 줄였습니다.

컨트롤러가 전체 시스템을 포괄하지 않기 때문에 이 일반 이름이 선택되었습니다. 현재 추적기, 리모컨 및 추적 펜에 대한 프로필도 있습니다. 아직 사양에 포함되지는 않았지만 런닝머신, 햅틱 조끼 등과 같은 장치에 대한 조항도 있습니다.

경고

OpenXR은 지원되는 장치를 엄격하게 검사한다는 점을 아는 것이 중요합니다. 핵심 사양은 지원되는 입력 및 출력과 함께 여러 컨트롤러 및 유사한 장치를 식별합니다. 모든 XR 런타임은 적용 가능하지 않더라도 이러한 상호 작용 프로필을 허용해야 합니다.

새로운 장치는 확장을 통해 추가되며 XR 런타임은 지원하는 장치를 지정해야 합니다. 확장을 통해 추가된 장치를 지원하지 않는 XR 런타임은 이러한 프로필을 허용하지 않습니다. 추가된 입력 또는 출력 유형을 지원하지 않는 XR 런타임은 제공되면 종종 충돌이 발생합니다.

따라서 Godot는 사용 가능한 모든 장치, 해당 장치의 입력 및 출력, 해당 장치에 대한 지원을 추가하는 확장의 메타 데이터를 보관합니다. 지원하려는 모든 장치에 대한 상호 작용 프로필을 만들 수 있습니다. Godot는 사용자가 사용하는 XR 런타임에서 지원하지 않는 것을 필터링합니다.

이는 새로운 장치를 지원하려면 최신 버전의 Godot로 업데이트해야 할 수도 있음을 의미합니다.

그러나 액션 맵은 이를 염두에 두고 설계되었다는 점에 유의하는 것도 중요합니다. 새로운 장치가 시장에 출시되거나 사용자가 액세스할 수 없는 장치를 사용할 때 액션 맵 시스템은 XR 런타임에 의존합니다. 지정된 가장 적합한 상호 작용 프로필을 선택하고 이를 사용자가 사용하는 컨트롤러에 맞게 조정하는 것이 XR 런타임의 임무입니다.

XR 런타임이 이를 수행하는 방법은 런타임 구현에 달려 있으며 따라서 런타임 간에는 큰 차이가 있습니다. 일부 런타임에서는 사용자가 바인딩을 직접 편집하는 것을 허용할 수도 있습니다.

런타임에 대한 일반적인 접근 방식은 먼저 일치하는 상호 작용 프로필을 찾는 것입니다. 이것이 발견되지 않으면 "터치 컨트롤러"의 프로필과 같은 가장 일반적인 프로필을 확인하고 변환을 수행합니다. 다른 모든 방법이 실패하면 일반 :ref:`"간단한 컨트롤러" <doc_xr_action_map_simple>`을 확인합니다.

참고

여기에서 내려야 할 중요한 결론이 있습니다: 컨트롤러가 발견되고 액션 맵이 여기에 적용될 때, XR 런타임은 Godot의 액션 맵 편집기에서 설정한 정확한 구성으로 제한되지 않습니다. 런타임은 일반적으로 작업 맵에서 설정한 바인딩 중 하나를 기반으로 적합한 매핑을 선택하지만, 그 바인딩에서 벗어날 수도 있습니다.

예를 들어 Touch 컨트롤러 프로필을 사용하는 경우 다음 시나리오 중 하나가 해당될 수 있습니다.

• 컨트롤러를 코딩하기

• 컨트롤러를 코딩하기

• Quest Pro 컨트롤러를 사용할 수 있지만 Quest Pro 프로필이 제공되지 않았거나 사용 중인 XR 런타임이 Quest Pro 컨트롤러를 지원하지 않습니다.

• 프로필이 제공되지 않은 완전히 다른 컨트롤러일 수 있지만 XR 런타임은 터치 바인딩을 기본으로 사용합니다.

따라서 현재로서는 사용자가 실제로 어떤 컨트롤러를 사용하고 있는지 확실하게 알 수 있는 방법이 없습니다.

경고

마지막으로, 이로 인해 많은 사람들이 걸려 넘어지게 되었고, 바인딩은 고정되지 않았습니다. XR 런타임을 통해 사용자가 바인딩을 사용자 정의할 수 있다는 것은 완전히 허용되며 심지어 예상됩니다.

SteamVR에는 여전히 액세스할 수 있는 OpenVR 액션 맵 시스템의 기존 UI가 있지만 현재로서는 XR 런타임 중 어느 것도 이 기능을 제공하지 않습니다. 그러나 이 작업은 활발히 진행되고 있습니다.

첫 번째 컨트롤러 바인딩

Touch 컨트롤러를 예로 들어 첫 번째 컨트롤러 바인딩을 설정해 보겠습니다.

"프로필 추가"를 누르고 Touch 컨트롤러를 찾아서 추가하세요. 목록에 없다면 이미 추가되었을 수도 있습니다.

이제 UI에 왼쪽 및 오른쪽 컨트롤러 모두에 대한 패널이 표시됩니다. 패널에는 각 컨트롤러에 대해 가능한 모든 입력 및 출력이 포함되어 있습니다. 각 항목 옆에 있는 ``+``를 사용하여 해당 항목을 작업에 바인딩할 수 있습니다.

이제 구성을 마무리해 보겠습니다:

각 작업은 두 컨트롤러 모두에 대해 지정된 입력 또는 출력에 바인딩되어 두 컨트롤러 중 하나에서 작업을 지원함을 나타냅니다. 예외는 오른쪽 컨트롤러에만 바인딩된 이동 동작입니다. 텔레포트 기능과 같은 다른 목적으로 왼손 엄지스틱을 사용하고 싶을 가능성이 높습니다.

게임/애플리케이션을 개발할 때 사용자가 바인딩을 변경하고 움직임을 왼손 엄지스틱에 바인딩할 가능성을 고려해야 합니다.

또한 촬영 및 잡기 부울 동작은 Float 유형의 입력에 연결되어 있습니다. 이전에 언급했듯이 OpenXR은 둘 사이의 변환을 수행하지만 이 문서 앞부분에서 해당 주제에 대해 제공된 경고를 읽으십시오.

참고

일부 입력이 목록에 여러 번 나타나는 것 같습니다.

예를 들어 X 버튼을 두 번 찾을 수 있습니다. 한 번은 ``X click``로, 그 다음에는 ``X touch``로 찾을 수 있습니다. 이는 정전식 센서가 있는 Touch 컨트롤러 때문입니다.

• 사용자가 단순히 X 버튼을 터치하는 경우 ``X touch``는 true입니다.

• ``X click``는 사용자가 실제로 버튼을 누르고 있을 때 참이 됩니다.

마찬가지로 엄지스틱의 경우 다음과 같습니다.

• Thumbstick touch 이는 사용자가 엄지스틱을 터치하는 경우 true가 됩니다.

• ``Thumbstick``는 엄지스틱을 누르는 방향에 대한 값을 제공합니다.

• Thumbstick click 이는 사용자가 엄지스틱을 누르고 있을 때 적용됩니다.

선택된 수의 XR 컨트롤러만 터치 센서를 지원하거나 썸스틱에 클릭 기능이 있다는 점에 유의하는 것이 중요합니다. 게임/애플리케이션을 디자인할 때 이 점을 명심하세요. 게임/애플리케이션의 선택적 기능에 사용되는지 확인하세요.

컨트롤러를 코딩하기

"간단한 컨트롤러"는 OpenXR이 대체 수단으로 제공하는 일반 컨트롤러입니다. 매핑을 적용하겠습니다.

고통스럽게도 분명해지듯이, 간단한 컨트롤러는 종종 너무 단순하고 가장 단순한 VR 게임/애플리케이션 외에는 부족합니다.

이것이 바로 많은 XR 런타임이 이를 최후의 수단으로만 사용하고 가장 널리 사용되는 시스템 중 하나의 바인딩을 먼저 폴백으로 사용하려고 시도하는 이유입니다.

참고

간단한 컨트롤러가 게임의 요구 사항을 충족하지 못할 가능성이 높기 때문에 OpenXR에서 지원하는 모든 컨트롤러에 바인딩을 제공하고 싶은 유혹이 있습니다. 기본 작업 맵은 이를 유효한 작업 과정으로 제안하는 것 같습니다. 앞서 언급했듯이 기본 액션 맵은 Godot 3에서 쉽게 마이그레이션할 수 있도록 설계되었습니다.

개발자가 실제로 테스트한 컨트롤러에 대한 바인딩만 설정하는 것이 OpenXR Working 그룹의 권장 사항입니다. XR 런타임은 이를 염두에 두고 설계되었습니다. 개발자가 지식에 근거한 추측을 할 수 있는 것보다 제공된 바인딩을 다시 바인딩하는 작업을 더 잘 수행할 수 있습니다. 특히 개발자는 이것이 최종 사용자에게 편안한 경험으로 이어지는지 테스트할 수 없습니다.

이것이 우리의 조언이기도 합니다. 액션 맵을 실제로 게임을 테스트한 장치의 상호 작용 프로필로 제한하십시오. Oculus Touch 컨트롤러는 많은 런타임에서 대체 컨트롤러로 널리 사용됩니다. Meta Rift 또는 Quest를 사용하여 게임을 테스트하고 이 프로필을 추가할 수 있다면 게임이 다른 헤드셋에서도 작동할 가능성이 높습니다.

모디파이어(Modifiers)

액션 맵의 주요 목표 중 하나는 애플리케이션이 사용된 하드웨어를 알 필요를 없애는 것입니다. 그러나 때때로 하드웨어에는 동작에 바인딩되는 방식이 아닌 다른 방식으로 입력을 변경해야 하는 물리적 차이가 있습니다. 이러한 요구 사항은 임계값 설정부터 컨트롤러에서 사용 가능한 입력 변경까지 다양합니다.

바인딩 수정자는 기본적으로 활성화되어 있지 않으며 OpenXR 프로젝트 설정에서 활성화해야 합니다. 또한 이러한 수정자가 모든 런타임에서 지원된다는 보장도 없습니다. 대상으로 삼고 있는 런타임에 대한 지원을 문의하고 수정자에 의존할지 아니면 어떤 형태의 대체 메커니즘을 구현할지 결정해야 합니다.

동일한 컨트롤러를 지원하는 여러 런타임을 대상으로 하는 경우 각 런타임에 대해 별도의 작업 맵을 만들어야 할 수도 있습니다. 각 런타임에 대해 서로 다른 내보내기 템플릿을 사용하고 사용자 정의 :ref:`feature 태그 <doc_feature_tags>`를 사용하여 액션 맵을 설정함으로써 Godot가 사용하는 액션 맵을 제어할 수 있습니다.

Godot에서 바인딩 수정자는 두 그룹으로 나뉩니다: 상호 작용 프로필 수준에서 작동하는 수정자와 개별 바인딩에서 작동하는 수정자.

애니메이션 패널

전체 상호 작용 프로필에 적용되는 바인딩 수정자는 상호 작용 프로필 편집기 오른쪽에 있는 수정자 버튼을 통해 액세스할 수 있습니다.

바인딩 수정자 추가 버튼을 눌러 새로운 수정자를 추가할 수 있습니다.

경고

Godot는 어떤 컨트롤러와 런타임이 수정자를 지원하는지 모르기 때문에 수정자를 추가하는 데 제한이 없습니다. 지원되지 않는 수정자는 무시됩니다.

십자 패드 바인딩 제약

dpad 바인딩 수정자는 이 컨트롤러의 각 조이스틱 및 썸패드 입력에 대한 상호 작용 프로필에 새 입력을 추가합니다. 입력을 버튼으로 노출되는 별도의 위, 아래, 왼쪽 및 오른쪽 입력이 있는 dpad로 전환합니다.

참고

확장과 관련된 입력은 별표로 표시됩니다.

dpad 바인딩 수정자를 사용하려면 프로젝트 설정에서 dpad 바인딩 수정자 확장을 활성화해야 합니다.

확장 기능을 활성화하면 기본 설정을 사용하여 이 기능이 작동하도록 할 수 있습니다.

수정자를 추가하는 것은 선택 사항이며 dpad 기능이 작동하는 방식을 미세 조정할 수 있습니다. 수정자를 여러 번 추가하여 다양한 입력에 대해 서로 다른 설정을 지정할 수 있습니다.

가장 일반적인 사용 케이스는 다음과 같습니다:

• ``Action Set``는 이러한 설정이 적용되는 작업 세트를 정의합니다.

• ``Input Path``는 새 dpad 입력에 매핑되는 원래 입력을 정의합니다.

• Threshold``는 dpad 작업을 활성화하는 임계값을 지정합니다. ``0.6 값은 중심으로부터의 거리가 ``0.6``보다 높으면 dpad 동작이 눌러진다는 것을 의미합니다.

• Threshold Released``는 dpad 작업을 비활성화하는 임계값을 지정합니다. ``0.4 값은 중심으로부터의 거리가 0.4 아래로 떨어지면 dpad 동작이 해제됨을 의미합니다.

• ``Center Region``는 중앙 작업을 활성화한 중앙으로부터의 거리를 지정하며, 이는 트랙패드에만 지원됩니다.

• Wedge Angle``는 각 웨지의 각도를 지정합니다. ``90 degrees 이하의 값은 위쪽, 아래쪽, 왼쪽 및 오른쪽 각각이 눌려진 상태에 있는 별도의 슬라이스를 가지고 있음을 의미합니다. ``90 degrees``보다 큰 값은 슬라이스가 겹치고 여러 작업이 눌러진 상태에 있을 수 있음을 의미합니다.

• 고정 여부가 활성화될 때 동작이 쐐기 모양으로 이동하기 전까지는 썸스틱이나 트랙패드가 해당 동작을 위해 쐐기 모양을 벗어났더라도 눌린 상태로 유지됩니다.

• ``On Haptic``를 사용하면 동작을 눌렀을 때 자동으로 활성화되는 햅틱 출력을 정의할 수 있습니다.

• ``Off Haptic``를 사용하면 동작을 놓으면 자동으로 활성화되는 햅틱 출력을 정의할 수 있습니다.

개별 바인딩의 바인딩 수정자

개별 바인딩에 적용되는 바인딩 수정자는 입력에 연결된 작업 옆에 있는 바인딩 수정자 버튼을 통해 액세스할 수 있습니다.

바인딩 수정자 추가 버튼을 눌러 새로운 수정자를 추가할 수 있습니다.

경고

Godot는 각 런타임의 어떤 입력이 수정자를 지원하는지 모르기 때문에 수정자를 추가하는 데 제한이 없습니다. 수정자 확장이 지원되지 않는 경우 수정자는 런타임 시 필터링됩니다. 잘못된 입력에 수정자를 추가하면 런타임 오류가 발생할 수 있습니다.

실제 하드웨어와 런타임에서 작업 맵을 테스트하여 올바른 설정을 확인해야 합니다.

아날로그 역치값 모디파이어

아날로그 임계값 수정자를 사용하면 부울 입력이 있는 트리거와 같은 모든 아날로그 입력에 사용되는 임계값을 지정할 수 있습니다. 입력이 눌려진 상태일 때를 제어합니다.

이 수정자를 사용하려면 프로젝트 설정에서 아날로그 임계값 확장을 활성화해야 합니다.

적 씬은 다음 노드들을 사용할 것입니다:

가장 일반적인 사용 케이스는 다음과 같습니다:

• On Threshold``는 작업을 활성화하는 임계값을 지정합니다. ``0.6 값은 아날로그 값이 ``0.6``보다 높을 때 작업이 누른 상태로 설정됨을 의미합니다.

• Off Threshold``는 작업을 비활성화하는 임계값을 지정합니다. ``0.4 값은 아날로그 값이 0.4 아래로 떨어지면 작업이 해제 상태로 설정됨을 의미합니다.

• ``On Haptic``를 사용하면 입력을 누를 때 자동으로 활성화되는 햅틱 출력을 정의할 수 있습니다.

• ``Off Haptic``를 사용하면 입력이 해제될 때 자동으로 활성화되는 햅틱 출력을 정의할 수 있습니다.

모디파이어에서 햅틱

수정자는 임계값에 도달할 때 트리거되는 자동 햅틱 출력을 지원할 수 있습니다.

참고

현재 사용 가능한 두 수정자 모두 이 기능을 지원하지만 향후 수정자에도 이 기능이 있다는 규칙은 없습니다. 한 가지 유형의 햅틱 피드백만 지원되지만 앞으로는 다른 옵션도 사용할 수 있게 될 것입니다.

햅틱 진동

햅틱 진동을 통해 간단한 햅틱 펄스를 지정할 수 있습니다.

다음과 같은 주의 사항이 있습니다:

• ``Duration``는 나노초 단위의 펄스 지속 시간입니다. ``-1``를 사용하면 런타임에서 현재 하드웨어에 적합한 짧은 펄스에 대한 최적의 값을 선택할 수 있습니다.

• ``Frequency``는 펄스의 주파수(Hz)입니다. ``0``를 사용하면 런타임에서 현재 하드웨어에 적합한 짧은 펄스에 대한 최적의 주파수를 선택할 수 있습니다.

• ``Amplitude``는 펄스의 진폭입니다.