Arsitektur Interaktor — MRTK3
MRTK dibangun berdasarkan serangkaian interaksi yang ditawarkan oleh Unity's XR Interaction Toolkit. Fitur realitas campuran seperti pelacakan tangan artikulasi, tatapan, dan jepitan 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 Ulasan
Untuk pengembang yang baru menggunakan XRI, kami sarankan Anda terlebih dahulu meninjau dokumentasi arsitektur XRI Unity. Interaktor MRTK adalah subkelas dari interaktor XRI atau implementasi antarmuka interaktor XRI yang ada. Lihat dokumentasi Unity tentang arsitektur interaksi mereka yang juga berlaku untuk MRTK.
Warga Negara XRI yang baik
Interaktor MRTK kustom bertingkah baik sehubungan dengan antarmuka interaktor XRI default; dari perspektif sistem XRI, mereka tidak dapat dibedakan dari interaktor "vanili". Inversi juga benar; saat membangun interaktif tingkat lanjut di MRTK, interaksi XRI default akan tetap berfungsi untuk hover dasar dan memilih. Ini adalah bagian dari upaya MRTK untuk sepenuhnya kompatibel dengan proyek XRI yang ada. Jika Anda memiliki aplikasi XRI, mrtk dapat berinteraksi dan kontrol UI akan bekerja dengan pengaturan XRI "vanilla" yang ada.
Abstraksi Modalitas Input
Perangkat input, interaksi 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 di 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 individual, interaksi hard-coding ke jenis input individu tertentu secara artifisial membatasi dan mengurangi fleksibilitas interaksi Anda. Lebih lanjut tentang hal ini dapat ditemukan dalam dokumentasi arsitektur yang dapat berinteraksi, tetapi kunci untuk interaksi adalah bahwa mereka umumnya tidak perlu memetakan 1:1 dengan perangkat input.
AttachTransform dan Inversi Kontrol
Sebagian besar apa yang dilakukan MRTK v2 dalam "memindahkan logika" sebagai bagian ObjectManipulator
dari , 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 kompleks pada yang dapat berinteraksi yang berbeda antara modalitas input; sebaliknya, logika manipulasi terpadu Anda dapat mendengarkan attachTransform
pose terlepas dari modalitas input atau perangkat yang mengendarainya.
Misalnya, sebuah GrabInteractor
's attachTransform
terletak di titik perampasan di tangan/pengontrol. Sebuah XRRayInteractor
's attachTransform
terletak di titik hit di akhir sinar. attachTransform
Terletak CanvasProxyInteractor
di mana pun mouse telah diklik. Untuk semua interaksi 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 interaksi.
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 attachTransform
baik.
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 interaksi 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 perpanjang.
XRControllers dan Pengikatan Input
Sebagian besar interaktor tidak mengikat langsung ke tindakan input. Sebagian besar berasal dari XRBaseControllerInteractor
, yang membutuhkan XRController
di atas interaktor dalam hierarki. Ikatan XRController
ke tindakan input lalu menyebarluaskan tindakan yang relevan (pilih, dan sebagainya) ke semua interaksi 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 XRController
pengikatan, tetapi perilaku ini dapat ditimpa untuk menggunakan sumber input eksternal atau alternatif.
Antarmuka
XRI mendefinisikan dasar IXRInteractor
, , IXRHoverInteractor
IXRSelectInteractor
, dan IXRActivateInteractor
. MRTK mendefinisikan antarmuka tambahan untuk interaksi. Beberapa mengekspos informasi tambahan tentang interaksi khusus MRTK, dan yang lain hanya untuk kategorisasi dan identifikasi. Antarmuka ini semuanya terletak 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 mengodekan 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 dapat berinteraksi kecuali benar-benar diperlukan. Dalam semua kasus, lebih baik mereferensikan antarmuka. Secara eksplisit mereferensikan jenis konkret akan membatasi interaksi Anda hanya untuk 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
Interaktor 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
. Dapat berinteraksi dasar (XRI default yang dapat berinteraksi, dan MRTKBaseInteractable
) tidak akan terpengaruh oleh jumlah pilihan variabel; StatefulInteractable
, namun, mendengarkan nilai ini dan menghitungnya Selectedness
berdasarkan max()
dari semua variabel yang berpartisipasi dan interaktor non-variabel.
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 memberi bendera IsGazeHovered
saat melayang IGazeInteractor
.
IGrabInteractor
Interaksi yang mengimplementasikan antarmuka ini mewakili interaksi pengambilan bidang dekat fisik. didefinisikan attachTransform
sebagai titik ambil. 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 menusuk dari sumber non-jari. Dalam salah satu dari beberapa contoh di mana memeriksa antarmuka interaktor adalah ide yang baik, dapat berinteraksi seperti PressableButton
mendengarkan IPokeInteractor
, khususnya, untuk mendorong pers volumetrik. Setiap interaksi yang mengimplementasikan akan menginduksi IPokeInteractor
tombol 3D menekan.
IPokeInteractor
PokeRadius
mengekspos properti , yang mendefinisikan karakteristik objek poking. Poke dianggap berpusat pada attachTransform
dan meluas ke luar dari attachTransform
oleh PokeRadius
. Dapat berinteraksi seperti PressableButton
mengimbangi jarak dorongan 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 IPokeInteractor
lain yang 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. attachTransform
mewakili 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; ISpeechInteractor
s 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, secara implisit, interaktor pemilihan variabel. IGazePinchInteractor
s 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. attachTransform
bertindak dengan cara IRayInteractor
attachTransform
yang sama; itu melekat pada titik temuan pada target ketika pemilihan dimulai.
Ketika beberapa IGazePinchInteractor
s berpartisipasi dalam satu interaksi, interaksi mereka attachTransform
diimbangi oleh perpindahan mereka dari titik median antara semua titik jepitan yang berpartisipasi. Dengan demikian, dapat berinteraksi dapat menafsirkannya attachTransform
dengan cara yang sama seperti interaksi multi-tangan lainnya, seperti attachTransforms
interaksi dari ambil, atau interaksi sinar.
Implementasi MRTK adalah GazePinchInteractor
.
IHandedInteractor
Beberapa interaksi dapat memilih untuk mengimplementasikan IHandedInteractor
antarmuka untuk secara eksplisit menentukan bahwa mereka dikaitkan dengan tangan tertentu pada pengguna. Beberapa interaksi tidak terkait dengan keserangan dan dengan demikian tidak menerapkan ini. Contoh yang paling jelas adalah contoh seperti SpeechInteractor
atau FuzzyGazeInteractor
.
Interaksi 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.