Freigeben über

Erstellen eines Eingabesystemdatenanbieters – MRTK2

Das Mixed Reality Toolkit-Eingabesystem ist ein erweiterbares System zum Aktivieren der Unterstützung von Eingabegeräten. Um Unterstützung für eine neue Hardwareplattform hinzuzufügen, ist möglicherweise ein benutzerdefinierter Eingabedatenanbieter erforderlich.

In diesem Artikel wird beschrieben, wie Sie benutzerdefinierte Datenanbieter, auch Geräte-Manager genannt, für das Eingabesystem erstellen. Der hier gezeigte Beispielcode stammt aus WindowsMixedRealityDeviceManagerdem .

Den vollständigen Code, der in diesem Beispiel verwendet wird, finden Sie im Ordner MRTK/Providers/WindowsMixedReality.

Namespace- und Ordnerstruktur

Datenanbieter können als Drittanbieter-Add-On oder als Teil des Microsoft Mixed Reality Toolkits verteilt werden. Das Genehmigungsverfahren für übermittlungen neuer Datenanbieter an MRTK variiert von Fall zu Fall und wird zum Zeitpunkt des ursprünglichen Vorschlags mitgeteilt.

Wichtig

Wenn ein Eingabesystemdatenanbieter an das Mixed Reality Toolkit-Repository übermittelt wird, muss der Namespace mit Microsoft.MixedReality.Toolkit (z. B. Microsoft.MixedReality.Toolkit.WindowsMixedReality) beginnen, und der Code sollte sich in einem Ordner unter MRTK/Providers (z. B. MRTK/Providers/WindowsMixedReality) befinden.

Namespace

Datenanbieter müssen über einen Namespace verfügen, um potenzielle Namenskonflikte zu vermeiden. Es wird empfohlen, dass der Namespace die folgenden Komponenten enthält.

  • Firmenname
  • Funktionsbereich

Beispielsweise kann ein vom Unternehmen Contoso erstellter Eingabedatenanbieter "Contoso.MixedReality.Toolkit.Input" sein.

Es wird empfohlen, den Quellcode für Datenanbieter in einer Ordnerhierarchie zu erstellen, wie in der folgenden Abbildung dargestellt.

Beispielordnerstruktur

Wenn ContosoInput die Implementierung des Datenanbieters enthält, enthält der Ordner Editor den Inspektor (und jeden anderen unity-Editor-spezifischen Code), der Ordner Textures Bilder der unterstützten Controller und Profile ein oder mehrere vorgefertigte Profile.

Hinweis

Einige gängige Controllerimages finden Sie im Ordner MixedRealityToolkit\StandardAssets\Textures.

Implementieren des Datenanbieters

Angeben der Vererbung von Schnittstellen und/oder Basisklassen

Alle Eingabesystemdatenanbieter müssen die IMixedRealityInputDeviceManager -Schnittstelle implementieren, die die für das Eingabesystem erforderliche Mindestfunktionalität angibt. Die MRTK-Grundlage enthält die BaseInputDeviceManager -Klasse, die eine Standardimplementierung dieser erforderlichen Funktionalität bereitstellt. Für Geräte, die auf der UInput-Klasse von Unity aufbauen, kann die UnityJoystickManager -Klasse als Basisklasse verwendet werden.

Hinweis

Die BaseInputDeviceManager Klassen und UnityJoystickManager stellen die erforderliche IMixedRealityInputDeviceManager Implementierung bereit.

public class WindowsMixedRealityDeviceManager :
    BaseInputDeviceManager,
    IMixedRealityCapabilityCheck
{ }

IMixedRealityCapabilityCheck wird von verwendet WindowsMixedRealityDeviceManager , um anzugeben, dass es Unterstützung für eine Reihe von Eingabefunktionen bietet, insbesondere für artikulierte Hände, Anvisieren-Gesten-Stimm-Hände und Motion-Controller.

Anwenden des MixedRealityDataProvider-Attributs

Ein wichtiger Schritt beim Erstellen eines Eingabesystemdatenanbieters besteht darin, das MixedRealityDataProvider -Attribut auf die -Klasse anzuwenden. Dieser Schritt ermöglicht das Festlegen des Standardprofils und der Standardplattform(en) für den Anbieter, wenn sie im Eingabesystemprofil ausgewählt sind.

[MixedRealityDataProvider(
    typeof(IMixedRealityInputSystem),
    SupportedPlatforms.WindowsUniversal,
    "Windows Mixed Reality Device Manager")]
public class WindowsMixedRealityDeviceManager :
    BaseInputDeviceManager,
    IMixedRealityCapabilityCheck
{ }

Implementieren der IMixedRealityDataProvider-Methoden

Nachdem die Klasse definiert wurde, besteht der nächste Schritt darin, die Implementierung der IMixedRealityDataProvider -Schnittstelle bereitzustellen.

Hinweis

Die BaseInputDeviceManager -Klasse stellt über die BaseService -Klasse nur leere Implementierungen für IMixedRealityDataProvider Methoden bereit. Die Details dieser Methoden sind im Allgemeinen datenanbieterspezifisch.

Folgende Methoden sollten vom Datenanbieter implementiert werden:

  • Destroy()
  • Disable()
  • Enable()
  • Initialize()
  • Reset()
  • Update()

Implementieren der Datenanbieterlogik

Der nächste Schritt besteht darin, die Logik zum Verwalten der Eingabegeräte hinzuzufügen, einschließlich aller controller, die unterstützt werden sollen.

Implementieren der Controllerklassen

Im Beispiel von WindowsMixedRealityDeviceManager werden die folgenden Controllerklassen definiert und implementiert.

Den Quellcode für jede dieser Klassen finden Sie im Ordner MRTK/Providers/WindowsMixedReality.

  • WindowsMixedRealityArticulatedHand.cs
  • WindowsMixedRealityController.cs
  • WindowsMixedRealityGGVHand.cs

Hinweis

Nicht alle Geräte-Manager unterstützen mehrere Controllertypen.

Anwenden des MixedRealityController-Attributs

Wenden Sie als Nächstes das MixedRealityController -Attribut auf die -Klasse an. Dieses Attribut gibt den Controllertyp (z. B. artikulierte Hand), die Händigkeit (z. B. links oder rechts) und ein optionales Controllerbild an.

[MixedRealityController(
    SupportedControllerType.WindowsMixedReality,
    new[] { Handedness.Left, Handedness.Right },
    "StandardAssets/Textures/MotionController")]
{ }

Konfigurieren der Interaktionszuordnungen

Der nächste Schritt besteht darin, den Satz von Interaktionszuordnungen zu definieren, die vom Controller unterstützt werden. Für Geräte, die ihre Daten über die Input-Klasse von Unity empfangen, ist das Controllerzuordnungstool eine hilfreiche Ressource, um die richtigen Achsen- und Schaltflächenzuordnungen zu bestätigen, die Interaktionen zugewiesen werden sollen.

Das folgende Beispiel wird von der GenericOpenVRController -Klasse abgekürzt, die sich im Ordner MRTK/Providers/OpenVR befindet.

public override MixedRealityInteractionMapping[] DefaultLeftHandedInteractions => new[]
{
    // Controller Pose
    new MixedRealityInteractionMapping(0, "Spatial Pointer", AxisType.SixDof, DeviceInputType.SpatialPointer, MixedRealityInputAction.None),
    // Left Trigger Squeeze
    new MixedRealityInteractionMapping(1, "Trigger Position", AxisType.SingleAxis, DeviceInputType.Trigger, ControllerMappingLibrary.AXIS_9),
    // Left Trigger Press (Select)
    new MixedRealityInteractionMapping(2, "Trigger Press (Select)", AxisType.Digital, DeviceInputType.TriggerPress, KeyCode.JoystickButton14),
};

Hinweis

Die ControllerMappingLibrary -Klasse stellt symbolische Konstanten für die Unity-Eingabeachsen- und Schaltflächendefinitionen bereit.

Auslösen von Benachrichtigungsereignissen

Damit Anwendungen auf Benutzereingaben reagieren können, löst der Datenanbieter Benachrichtigungsereignisse aus, die änderungen des Controllerzustands entsprechend der Definition in den IMixedRealityInputHandler Schnittstellen und IMixedRealityInputHandler<T> entsprechen.

Für digitale Steuerelemente vom Typ (Schaltfläche) lösen Sie die Ereignisse OnInputDown und OnInputUp aus.

// inputAction is the input event that is to be raised.
if (interactionSourceState.touchpadPressed)
{
    InputSystem?.RaiseOnInputDown(InputSource, ControllerHandedness, inputAction);
}
else
{
    InputSystem?.RaiseOnInputUp(InputSource, ControllerHandedness, inputAction);
}

Für analoge Steuerelemente (z. B. Touchpadposition) sollte das InputChanged-Ereignis ausgelöst werden.

InputSystem?.RaisePositionInputChanged(InputSource, ControllerHandedness, interactionMapping.MixedRealityInputAction, interactionSourceState.touchpadPosition);

Hinzufügen der Unity Profiler-Instrumentierung

Die Leistung ist in Mixed Reality-Anwendungen von entscheidender Bedeutung. Jede Komponente führt zu einem gewissen Mehraufwand, den Anwendungen berücksichtigen müssen. Zu diesem Zweck ist es wichtig, dass alle Eingabedatenanbieter unity Profiler-Instrumentierung in innerer Schleife und häufig verwendete Codepfade enthalten.

Es wird empfohlen, das vom MRTK verwendete Muster bei der Instrumentierung benutzerdefinierter Anbieter zu implementieren.

        private static readonly ProfilerMarker GetOrAddControllerPerfMarker = new ProfilerMarker("[MRTK] WindowsMixedRealityDeviceManager.GetOrAddController");

        private async void GetOrAddController(InteractionSourceState interactionSourceState)
        {
            using (GetOrAddControllerPerfMarker.Auto())
            {
                // Code to be measured.
            }
        }

Hinweis

Der Name, der zum Identifizieren des Profilermarkers verwendet wird, ist willkürlich. MRTK verwendet das folgende Muster.

"[product] className.methodName – optionaler Hinweis"

Es wird empfohlen, dass benutzerdefinierte Datenanbieter einem ähnlichen Muster folgen, um die Identifizierung bestimmter Komponenten und Methoden beim Analysieren von Ablaufverfolgungen zu vereinfachen.

Erstellen des Profils und des Inspektors

In Mixed Reality Toolkit werden Datenanbieter mithilfe von Profilen konfiguriert.

Datenanbieter mit zusätzlichen Konfigurationsoptionen (z. B. InputSimulationService) sollten ein Profil und einen Inspektor erstellen, damit Kunden das Verhalten so ändern können, dass es den Anforderungen der Anwendung am besten entspricht.

Den vollständigen Code für das Beispiel in diesem Abschnitt finden Sie im MRTK. Ordner "Services/InputSimulation".

Definieren des Profils

Profilinhalte sollten Spiegel den eigenschaften des Beobachters (z. B. Updateintervall) zugänglich sein. Alle vom Benutzer konfigurierbaren Eigenschaften, die in jeder Schnittstelle definiert sind, sollten im Profil enthalten sein.

[CreateAssetMenu(
    menuName = "Mixed Reality Toolkit/Profiles/Mixed Reality Simulated Input Profile",
    fileName = "MixedRealityInputSimulationProfile",
    order = (int)CreateProfileMenuItemIndices.InputSimulation)]
public class MixedRealityInputSimulationProfile : BaseMixedRealityProfile
{ }

Das CreateAssetMenu Attribut kann auf die Profilklasse angewendet werden, damit Kunden mithilfe des Menüs Ressourcen > Mixed Reality Toolkitprofile > erstellen > ein Profil instance erstellen können.

Implementieren des Inspektors

Profilinspektoren sind die Benutzeroberfläche zum Konfigurieren und Anzeigen von Profilinhalten. Jeder Profilinspektor sollte die BaseMixedRealityToolkitConfigurationProfileInspector-Klasse erweitern.

[CustomEditor(typeof(MixedRealityInputSimulationProfile))]
public class MixedRealityInputSimulationProfileInspector : BaseMixedRealityToolkitConfigurationProfileInspector
{ }

Das CustomEditor Attribut informiert Unity über den Typ des Medienobjekts, für das der Inspektor gilt.

Erstellen von Assemblydefinitionen

Mixed Reality Toolkit verwendet Assemblydefinitionsdateien (ASMDEF), um Abhängigkeiten zwischen Komponenten anzugeben und Unity bei der Reduzierung der Kompilierungszeit zu unterstützen.

Es wird empfohlen, Assemblydefinitionsdateien für alle Datenanbieter und deren Editorkomponenten zu erstellen.

Bei Verwendung der Ordnerstruktur im vorherigen Beispiel gibt es zwei ASMDEF-Dateien für den ContosoInput-Datenanbieter.

Die erste Assemblydefinition gilt für den Datenanbieter. In diesem Beispiel heißt es ContosoInput und befindet sich im Ordner ContosoInput des Beispiels. Diese Assemblydefinition muss eine Abhängigkeit von Microsoft.MixedReality.Toolkit und anderen Assemblys angeben, von denen sie abhängt.

Die ContosoInputEditor-Assemblydefinition gibt den Profilinspektor und jeden editorspezifischen Code an. Diese Datei muss sich im Stammordner des Editorcodes befinden. In diesem Beispiel befindet sich die Datei im Ordner ContosoInput\Editor. Diese Assemblydefinition enthält einen Verweis auf die ContosoInput-Assembly sowie folgendes:

  • Microsoft.MixedReality.Toolkit
  • Microsoft.MixedReality.Toolkit.Editor.Inspectors
  • Microsoft.MixedReality.Toolkit.Editor.Utilities

Registrieren des Datenanbieters

Nach der Erstellung kann der Datenanbieter beim Eingabesystem registriert und in der Anwendung verwendet werden.

Registrierte Eingabesystemdatenanbieter

Verpackung und Vertrieb

Datenanbieter, die als Komponenten von Drittanbietern verteilt werden, haben die spezifischen Details der Verpackung und Verteilung den Präferenzen des Entwicklers überlassen. Wahrscheinlich wird die häufigste Lösung sein, ein UNITY-Paket zu generieren und über den Unity Asset Store zu verteilen.

Wenn ein Datenanbieter als Teil des Microsoft Mixed Reality Toolkit-Pakets übermittelt und akzeptiert wird, packt und verteilt das Microsoft MRTK-Team ihn als Teil der MRTK-Angebote.

Siehe auch

  • Last updated on