Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
MRTK bouwt voort op de set interactors die wordt aangeboden door de XR Interaction Toolkit van Unity. Voor mixed reality-functies, zoals gearticuleerde handtracering, staren en knijpen, zijn uitgebreidere interactors vereist dan de set die standaard bij XRI wordt geleverd. MRTK definieert nieuwe interactor-interfaces, die in het algemeen worden gecategoriseerd op basis van de invoermodaliteit en de bijbehorende implementaties.
Samenvatting en beoordeling
Voor ontwikkelaars die niet bekend zijn met XRI, raden we u aan eerst de documentatie voor de XRI-architectuur van Unity te raadplegen. MRTK-interactors zijn subklassen van bestaande XRI-interactors of implementaties van de XRI-interactorinterfaces. Raadpleeg de documentatie van Unity over de interactorarchitectuur die ook van toepassing is op MRTK.
Goede burgers van XRI
De aangepaste MRTK-interactors gedragen zich goed met betrekking tot de standaard XRI-interactorinterfaces; vanuit het perspectief van XRI-systemen zijn ze niet te onderscheiden van 'vanille'-interactors. Het inverse is ook waar; bij het bouwen van geavanceerde interactables in MRTK, werken de standaard XRI-interactors nog steeds voor eenvoudige aanwijzen en selecteren. Het maakt deel uit van de MRTK-inspanning om volledig compatibel te zijn met bestaande XRI-projecten. Als u een XRI-toepassing hebt, werken MRTK interactables en UI-besturingselementen met uw bestaande XRI-installatie voor 'vanille'.
Abstractie van invoermodaliteit
Het invoerapparaat, de interactor die de interactie uitvoert en de interactie-gebeurtenissen die ze genereren, zijn allemaal architectonisch geïsoleerd in XRI. Deze isolatie is essentieel voor de strategie voor invoerabstractie in MRTK3 en stelt ons in staat om platformoverschrijdende en apparaatoverschrijdende interacties te schrijven die in alle contexten goed werken.
Vanaf MRTK v2 is er een algemeen instinct om interacties te coden die specifiek zijn voor een bepaald invoertype of apparaat. Veel ontwikkelaars zijn gewend om interacties te schrijven die specifiek reageren op een near grab, een verre straal of een ander specifiek invoertype.
Hoewel MRTK3 nog steeds de ondubbelzinnigheid en detectie van afzonderlijke invoermodi mogelijk maakt, is het coderen van interacties met specifieke afzonderlijke invoertypen kunstmatig beperkt en vermindert deze de flexibiliteit van uw interacties. Meer informatie hierover vindt u in de documentatie over interactiebare architectuur, maar de sleutel voor interactors is dat ze over het algemeen geen 1:1 hoeven toe te wijzen aan invoerapparaten.
AttachTransform en Inversie van besturingselement
Veel van wat MRTK v2 deed in 'move logics' als onderdeel van ObjectManipulator, Slider, enzovoort, is nu de verantwoordelijkheid van de interactor zelf. De interactor bepaalt nu de attachTransform om te definiëren hoe een specifiek type manipulatie zich gedraagt. Men hoeft geen complexe interactielogica meer te schrijven op de interactiebare die verschilt tussen invoermethoden; In plaats daarvan kan uw geïntegreerde manipulatielogica luisteren naar de houding van de attachTransform, ongeacht de invoermodaliteit of het apparaat dat deze aandrijft.
Een 's attachTransform bevindt zich bijvoorbeeld GrabInteractorop het grijppunt op de hand/controller. Een XRRayInteractorbevindt attachTransform zich op het trefferpunt aan het einde van de ray. De CanvasProxyInteractor's attachTransform bevinden zich overal waar de muis heeft geklikt. Voor al deze verschillende interactors hoeft de interactiebare zich geen zorgen te maken over het type interactor om op de juiste manier te reageren op manipulaties.
De interactiequery's en attachTransform kunnen elk attachTransform hetzelfde behandelen, ongeacht het type interactie.
Deze benadering is essentieel voor de compatibiliteit met bestaande XRI-interactors en het toekomstbestendig maken van uw interacties voor invoermethoden die nog niet zijn ontwikkeld. Als er een nieuwe invoermethode wordt geïntroduceerd, hoeft u bestaande interactables niet te wijzigen als de nieuwe interactie een geldige en goed gedragende attachTransforminteractie genereert.
Dus, filosofisch gezien, is de attachTransform de interactielogica. Geef voor aangepaste interacties altijd de voorkeur aan het schrijven van een nieuwe interactor met nieuwe attachTransform logica in plaats van het opnieuw schrijven of uitbreiden van interactiebare elementen die moeten worden aangepast voor uw nieuwe interactie. Op deze manier kunnen alle bestaande interacties profiteren van de voordelen van uw nieuwe interactie in plaats van alleen de interactie die u hebt herschreven of uitgebreid.
XRControllers en invoerbinding
De meeste interactors binden niet rechtstreeks aan invoeracties. De meeste zijn afgeleid van XRBaseControllerInteractor, waarvoor een XRController boven de interactor in de hiërarchie is vereist. De XRController bindt aan invoeracties en geeft vervolgens de relevante acties (selecteren, enzovoort) door aan alle gekoppelde interactors.
Sommige interactors hebben echter mogelijk speciale invoerbindingen of extra invoer nodig die de XRController niet levert. In deze gevallen hebben interactors de optie om rechtstreeks verbinding te maken met hun eigen unieke invoeracties of zelfs andere niet-Input-System-bronnen te gebruiken voor interactielogica. De XRI-basisklassen luisteren liever naar de XRControllerbindingen, maar dit gedrag kan worden overschreven om externe of alternatieve invoerbronnen te gebruiken.
Interfaces
XRI definieert de basis IXRInteractor, IXRHoverInteractor, IXRSelectInteractoren IXRActivateInteractor. MRTK definieert aanvullende interfaces voor interactors. Sommige bieden aanvullende informatie over MRTK-specifieke interacties en andere zijn alleen bedoeld voor categorisatie en identificatie. Deze interfaces bevinden zich allemaal in het Core-pakket , terwijl de implementaties zich in andere pakketten bevinden, waaronder Invoer.
Belangrijk
Hoewel deze interfaces handig zijn als u moet filteren op een specifiek type interactie, raden we u aan uw interacties niet hard te codeken om specifiek naar deze interfaces te luisteren.
Geef in elke situatie altijd de voorkeur aan de algemene XRI isSelected en isHovered, in plaats van een interactiespecifieke interface.
Tenzij nodig, moet u niet verwijzen naar de concrete MRTK-implementaties van deze interfaces in interactables, tenzij dit absoluut noodzakelijk is. In alle gevallen is het beter om te verwijzen naar de interfaces. Als u expliciet naar de betontypen verwijst, werken uw interactie-apparaten alleen met de huidige, bestaande typen. Door alleen naar de interfaces te verwijzen, zorgt u voor compatibiliteit met toekomstige implementaties die de bestaande implementaties mogelijk niet subklassen.
IVariableSelectInteractor
Interactors die deze interface implementeren, kunnen variabele (dat wil gezegd, analoge) selectiviteit voor interactie-apparaten uitgeven. De variabele select amount kan worden opgevraagd met de SelectProgress eigenschap. MRTK-interactors die deze interface implementeren, zijn onder andere de MRTKRayInteractor en de GazePinchInteractor. Base interactables (de standaard XRI interactables, en MRTKBaseInteractable) worden niet beïnvloed door de variabele selectiehoeveelheid; StatefulInteractable, luistert echter naar deze waarde en berekent de waarde Selectedness op basis van alle max() deelnemende variabele en niet-variabele interactors.
IGazeInteractor
Interactors die deze interface implementeren, vertegenwoordigen de passieve blik van de gebruiker, gescheiden van elke manipulatie of intentie. De MRTK-implementatie is FuzzyGazeInteractor, die van de XRI XRRayInteractorwordt overgenomen en fuzzy cone-castinglogica toevoegt.
XRBaseInteractable
IsGazeHovered markeert wanneer een IGazeInteractor aanwijst.
IGrabInteractor
Interactors die deze interface implementeren, vertegenwoordigen een fysieke near-field grabbing-interactie. De attachTransform wordt gedefinieerd als het grijppunt. De MRTK-implementatie is GrabInteractor, waarmee XRI's worden ingedeeld XRDirectInteractor.
IPokeInteractor
Interactors die deze interface implementeren, vertegenwoordigen een pluidende interactie. Houd er rekening mee dat dit niet noodzakelijkerwijs een vinger impliceert! Willekeurige interactors kunnen deze interface implementeren en zoekende interacties van niet-vingerbronnen bieden. In een van de weinige gevallen waar het controleren van interactor-interfaces een goed idee is, kunt u interactief werken, zoals PressableButton luisteren naar IPokeInteractors, met name om volumetrische pers aan te drijven. Elke interactor die implementeert IPokeInteractor , veroorzaakt 3D-drukken op knoppen.
IPokeInteractor geeft de PokeRadius eigenschap weer, die de kenmerken van het poking-object definieert. De poke wordt beschouwd als gecentreerd op de attachTransform en strekt zich uit van de attachTransform door de PokeRadius. Interactiemogelijkheden, zoals PressableButton , verleggen hun 3D-pushafstand door deze straal, die kan worden aangestuurd door de fysieke vingerdikte van de gebruiker in het geval van op vingers gebaseerde persen.
De MRTK-implementatie van deze interface is PokeInteractor. In ons sjabloonproject geven we ook een ander voorbeeld van IPokeInteractor dat niet door de vinger wordt gestuurd; PenInteractor biedt prik-interacties die zijn geroot op de punt van een virtuele 3D-stylus.
IRayInteractor
Interactors die deze interface implementeren, vertegenwoordigen een op ray gebaseerde aanwijsinteractie. De attachTransform vertegenwoordigt de trefferlocatie van de straal op het oppervlak van het doelobject tijdens een selectie.
De MRTK-implementatie van deze interface is MRTKRayInteractor, neemt rechtstreeks over van de XRI XRRayInteractor.
Opmerking
De XRI XRRayInteractor implementeert deze MRTK-interface niet.
ISpeechInteractor
Interactors die deze interface implementeren, vertegenwoordigen spraakgestuurde interacties. De MRTK-implementatie is SpeechInteractor.
De MRTK SpeechInteractormaakt intern gebruik van PhraseRecognitionSubsystem en abonneert zich op interactiebare registratie-gebeurtenissen van de XRI XRInteractionManager. Interactie tussen gebruikers hoeft zich echter geen zorgen te maken over welk subsysteem spraakverwerking uitvoert; ISpeechInteractors genereren dezelfde XRI-gebeurtenissen (selecteren, enzovoort) als elke andere interactie.
IGazePinchInteractor
Deze interface is gewoon een specialisatie van de IVariableSelectInteractor interface. Interactors die deze interface implementeren, zijn impliciet, variable-select interactors.
IGazePinchInteractors vertegenwoordigen uitdrukkelijk een indirect gerichte manipulatie op afstand. Een afzonderlijke interactie op basis van staren stuurt het doel van de interactie aan en de manipulatie is door een hand of controller.
attachTransformgedraagt zich op dezelfde manier als IRayInteractorattachTransform dat van; het wordt uitgelijnd op het trefferpunt op het doel wanneer een selectie wordt gestart.
Wanneer meerdere IGazePinchInteractors deelnemen aan één interactie, worden hun attachTransforms verschoven van het mediaanpunt tussen alle deelnemende knijppunten. Interactables kunnen deze attachTransforms dus op dezelfde manier interpreteren als voor elke andere interactie met meerdere handen, zoals de attachTransforms van grab-interacties of ray-interacties.
De MRTK-implementatie is de GazePinchInteractor.
IHandedInteractor
Sommige interactors kunnen ervoor kiezen om een interface te implementeren IHandedInteractor om expliciet op te geven dat ze zijn gekoppeld aan een bepaalde hand van een gebruiker. Sommige interactors zijn niet gekoppeld aan handigheid en implementeren dit dus niet. De meest voor de hand liggende voorbeelden zijn bijvoorbeeld SpeechInteractor of FuzzyGazeInteractor.
De MRTK-interactors die deze interface implementeren, zijn de HandJointInteractor, een algemene, abstracte XRDirectInteractor , aangedreven door een willekeurige handverbinding, de GazePinchInteractor, en de MRTKRayInteractor.
Interactables gebruiken deze interface momenteel om bepaalde effecten te activeren wanneer ze zijn geselecteerd en die moeten verschillen tussen een linker- of rechterhand. Het meest opvallende voorbeeld hiervan is het pulse-effect in de UX-onderdelenbibliotheek.