Arsitektur Interaktor — MRTK3

MRTK dibangun berdasarkan serangkaian interaksi yang ditawarkan oleh Unity's XR Interaction Toolkit. Fitur realitas campuran seperti pelacakan tangan, tatapan, dan jepitan yang diartikulasikan membutuhkan interaksi yang lebih rumit daripada set yang disediakan dengan XRI secara default. MRTK mendefinisikan antarmuka interaktor baru, dikategorikan umumnya oleh modalitas input, dan implementasi yang sesuai.

Ringkasan dan Tinjauan

Untuk pengembang yang baru menggunakan XRI, kami sarankan Anda terlebih dahulu meninjau dokumentasi arsitektur XRI Unity. Interaksi MRTK adalah subkelas dari interaktor XRI yang ada atau implementasi antarmuka interaktor XRI. Lihat dokumentasi Unity tentang arsitektur interaktor mereka yang juga berlaku untuk MRTK.

Warga Negara XRI yang Baik

Interaksi MRTK kustom bersifat baik sehubungan dengan antarmuka interaktor XRI default; dari perspektif sistem XRI, mereka tidak dapat dibedakan dari interaksi "vanilla". Kebalikannya juga benar; saat membangun interaktif tingkat lanjut di MRTK, interaksi XRI default masih akan berfungsi untuk hover dasar dan memilih. Ini adalah bagian dari upaya MRTK agar sepenuhnya kompatibel dengan proyek XRI yang ada. Jika Anda memiliki aplikasi XRI, kontrol MRTK interactables dan UI akan berfungsi dengan pengaturan XRI "vanilla" yang ada.

Abstraksi Modalitas Input

Perangkat input, interaktor yang melakukan interaksi, dan peristiwa interaksi yang mereka hasilkan semuanya terisolasi secara arsitektur di XRI. Isolasi ini sangat penting untuk strategi abstraksi input di MRTK3, dan memungkinkan kami menulis interaksi lintas platform dan lintas perangkat yang berfungsi dengan baik dalam semua konteks.

Dari MRTK v2, ada naluri umum untuk mengodekan interaksi khusus untuk jenis input atau perangkat tertentu. Banyak pengembang terbiasa menulis interaksi yang bereaksi khusus terhadap penangkapan dekat, sinar jauh, atau beberapa jenis input spesifik lainnya.

Meskipun MRTK3 masih memungkinkan disambiguasi dan deteksi mode input individu, interaksi hard-coding ke jenis input individu tertentu secara artifisial membatasi dan mengurangi fleksibilitas interaksi Anda. Lebih lanjut tentang ini dapat ditemukan dalam dokumentasi arsitektur yang dapat berinteraksi, tetapi kunci untuk interaktor adalah bahwa mereka umumnya tidak perlu memetakan 1:1 dengan perangkat input.

AttachTransform dan Inversion of Control

Sebagian besar hal yang dilakukan MRTK v2 dalam "memindahkan logika" sebagai bagian ObjectManipulatordari , Slider, dan sebagainya, sekarang menjadi tanggung jawab interaksi itu sendiri. Interaktor sekarang mengontrol attachTransform-nya untuk menentukan bagaimana jenis manipulasi tertentu berakibat. Seseorang tidak perlu lagi menulis logika interaksi yang kompleks pada interaktif yang berbeda antara modalitas input; sebagai gantinya, logika manipulasi terpadu Anda dapat mendengarkan attachTransformpose 's terlepas dari modalitas input atau perangkat yang mengendarainya.

Misalnya, GrabInteractor's attachTransform terletak di titik perampasan di tangan/pengontrol. Sebuah XRRayInteractor's attachTransform terletak di titik hit di akhir sinar. Lokasinya CanvasProxyInteractorattachTransform di mana pun mouse telah diklik. Untuk semua interaktor yang berbeda ini, yang dapat berinteraksi tidak perlu peduli tentang jenis interaksi untuk merespons manipulasi dengan tepat.

Kueri yang dapat attachTransform berinteraksi dan dapat memperlakukan setiap attachTransform hal yang sama terlepas dari jenis interaktor.

Pendekatan ini sangat penting untuk kompatibilitas dengan interaksi XRI yang ada serta pemeriksaan masa depan interaksi Anda untuk modalitas input yang belum dikembangkan. Jika metode input baru diperkenalkan, Anda tidak perlu mengubah interaktif yang ada jika interaksi baru menghasilkan yang valid dan berperilaku attachTransformbaik .

Dengan demikian, secara filosofi, attachTransform adalah logika interaksi. Untuk interaksi kustom apa pun, selalu berikan preferensi untuk menulis interaksi baru dengan logika baru attachTransform daripada menulis ulang atau memperluas interaktif yang akan disesuaikan untuk interaksi baru Anda. Dengan cara ini, semua interaktif yang ada dapat menikmati manfaat interaksi baru Anda alih-alih hanya yang telah Anda tulis ulang atau diperpanjang.

XRControllers dan Pengikatan Input

Sebagian besar interaktor tidak mengikat langsung ke tindakan input. Sebagian besar berasal dari XRBaseControllerInteractor, yang memerlukan XRController interaksi di atas dalam hierarki. Ikatan XRController ke tindakan input lalu menyebarluaskan tindakan yang relevan (pilih, dan sebagainya) ke semua interaktor yang terpasang.

Meskipun demikian, beberapa interaksi mungkin memerlukan pengikatan input khusus atau input tambahan yang XRController tidak disediakan. Dalam kasus ini, interaktor memiliki opsi untuk mengikat langsung ke tindakan input unik mereka sendiri atau bahkan menggunakan sumber non-Input-System lainnya untuk logika interaksi. Kelas dasar XRI lebih suka mendengarkan XRControllerpengikatan , tetapi perilaku ini dapat ditimpa untuk menggunakan sumber input eksternal atau alternatif.

Antarmuka

XRI mendefinisikan dasar IXRInteractor, , IXRHoverInteractorIXRSelectInteractor, dan IXRActivateInteractor. MRTK mendefinisikan antarmuka tambahan untuk interaktor. Beberapa mengekspos informasi tambahan tentang interaksi khusus MRTK, dan yang lain hanya untuk kategorisasi dan identifikasi. Antarmuka ini semuanya terletak di dalam paket Core , sementara implementasi berada di paket lain, termasuk Input.

Penting

Meskipun antarmuka ini berguna jika Anda perlu memfilter jenis interaksi tertentu, kami sarankan Anda tidak mengkodekan interaksi Anda secara permanen untuk mendengarkan antarmuka ini secara khusus. Dalam setiap situasi, selalu berikan preferensi pada XRI generikPilih dan dipisahkan, bukan antarmuka khusus interaksi apa pun.

Kecuali perlu, Anda tidak boleh mereferensikan implementasi MRTK konkret dari antarmuka ini dalam interaktif kecuali jika benar-benar diperlukan. Dalam semua kasus, lebih baik mereferensikan antarmuka. Secara eksplisit merujuk jenis beton akan membatasi interaktif Anda untuk hanya bekerja dengan jenis yang ada saat ini. Dengan hanya mereferensikan antarmuka, Anda memastikan kompatibilitas dengan implementasi di masa mendatang yang mungkin tidak mensubkelas implementasi yang ada.

IVariableSelectInteractor

Interaksi yang mengimplementasikan antarmuka ini dapat mengeluarkan variabel (yaitu, analog) yang dipilih ke dapat berinteraksi. Jumlah pilih variabel dapat dikueri dengan SelectProgress properti . Interaksi MRTK yang mengimplementasikan antarmuka ini mencakup MRTKRayInteractor dan GazePinchInteractor. Base interactables (XRI interactables default, dan MRTKBaseInteractable) tidak akan terpengaruh oleh jumlah pilihan variabel; StatefulInteractable, namun, mendengarkan nilai ini dan menghitungnya Selectedness berdasarkan max() semua variabel yang berpartisipasi dan non-variabel interaktor.

IGazeInteractor

Interaksi yang mengimplementasikan antarmuka ini mewakili tatapan pasif pengguna, terpisah dari manipulasi atau niat apa pun. Implementasi MRTK adalah FuzzyGazeInteractor, yang mewarisi dari XRI XRRayInteractor, dan menambahkan logika pengecoran kerucut fuzzy. XRBaseInteractable akan menandai IsGazeHovered ketika melayang IGazeInteractor .

IGrabInteractor

Interaktor yang mengimplementasikan antarmuka ini mewakili interaksi fisik mendekati bidang yang mengambil interaksi. didefinisikan attachTransform sebagai titik perampasan. Implementasi MRTK adalah GrabInteractor, yang mensubkelas XRI XRDirectInteractor.

IPokeInteractor

Interaksi yang mengimplementasikan antarmuka ini mewakili interaksi poking. Perhatikan bahwa ini tidak selalu menyiratkan jari! Interaktor arbitrer dapat mengimplementasikan antarmuka ini dan menawarkan interaksi yang menusuk dari sumber non-jari. Dalam salah satu dari beberapa instans di mana memeriksa antarmuka interaktor adalah ide yang baik, dapat berinteraksi seperti PressableButton mendengarkan IPokeInteractor, khususnya, untuk mendorong pers volumetrik. Setiap interaktor yang mengimplementasikan akan menginduksi IPokeInteractor tombol 3D menekan.

IPokeInteractorPokeRadius mengekspos properti , yang mendefinisikan karakteristik objek poking. Poke dianggap berpusat pada attachTransform dan meluas ke luar dari attachTransform oleh PokeRadius. Interaktif seperti PressableButton mengimbangi jarak dorong 3D mereka oleh radius ini, yang dapat didorong oleh ketebalan jari fisik pengguna dalam kasus penekanan berbasis jari.

Implementasi MRTK dari antarmuka ini adalah PokeInteractor. Dalam proyek templat kami, kami juga memberikan contoh lain yang IPokeInteractor tidak digerakkan oleh jari; PenInteractor menyediakan interaksi poke yang berakar pada ujung stylus 3D virtual.

IRayInteractor

Interaksi yang mengimplementasikan antarmuka ini mewakili interaksi penunjuk berbasis sinar. mewakili attachTransform lokasi hit sinar pada permukaan objek yang ditargetkan selama pemilihan.

Implementasi MRTK dari antarmuka ini adalah MRTKRayInteractor, mewarisi langsung dari XRI XRRayInteractor.

Catatan

XRI XRRayInteractor tidak mengimplementasikan antarmuka MRTK ini.

ISpeechInteractor

Interaksi yang mengimplementasikan antarmuka ini mewakili interaksi berbasis ucapan. Implementasi MRTK adalah SpeechInteractor.

MRTK SpeechInteractor, secara internal, menggunakan PhraseRecognitionSubsystem dan berlangganan peristiwa pendaftaran yang dapat berinteraksi dari XRI XRInteractionManager. Namun, interaktif tidak perlu khawatir tentang subsistem apa yang melakukan pemrosesan ucapan; ISpeechInteractors menghasilkan peristiwa XRI yang sama (pilih, dan sebagainya) yang dilakukan oleh interaksi lain.

IGazePinchInteractor

Antarmuka ini hanyalah spesialisasi antarmuka IVariableSelectInteractor . Interaksi yang mengimplementasikan antarmuka ini adalah, secara implisit, interaktor pemilihan variabel. IGazePinchInteractors secara tegas mewakili manipulasi jarak jauh yang ditargetkan secara tidak langsung. Interaksi berbasis tatapan terpisah mendorong target interaksi, dan manipulasinya adalah dengan tangan atau pengontrol. attachTransformbertindak dengan cara IRayInteractorattachTransform yang sama; itu melekat pada titik temuan pada target ketika pemilihan dimulai.

Ketika beberapa IGazePinchInteractors berpartisipasi dalam satu interaksi, interaksi mereka attachTransformdiimbangi oleh perpindahannya dari titik median antara semua titik pinch yang berpartisipasi. Dengan demikian, dapat diinterpretasikan dengan attachTransformcara yang sama seperti interaksi multi-tangan lainnya, seperti attachTransforms interaksi dari ambil, atau interaksi sinar.

Implementasi MRTK adalah GazePinchInteractor.

IHandedInteractor

Beberapa interaktor dapat memilih untuk menerapkan IHandedInteractor antarmuka untuk secara eksplisit menentukan bahwa mereka dikaitkan dengan tangan tertentu pada pengguna. Beberapa interaktor tidak terkait dengan keserangan dan dengan demikian tidak menerapkan ini. Contoh yang paling jelas adalah contoh seperti SpeechInteractor atau FuzzyGazeInteractor.

Interaktor MRTK yang mengimplementasikan antarmuka ini adalah HandJointInteractor, generik, abstrak XRDirectInteractor yang didorong oleh sendi tangan arbitrer, GazePinchInteractor, dan MRTKRayInteractor.

Interactables saat ini menggunakan antarmuka ini untuk menembakkan efek tertentu ketika dipilih yang harus membedakan antara tangan kiri atau kanan. Contoh yang paling mencolok dari ini adalah efek pulsa di pustaka komponen UX.