XR SDK

Subsistem Display SDK XR menyediakan antarmuka untuk alokasi tekstur, siklus hidup bingkai, dan memblokir untuk kader.

Alokasi Tekstur

Beberapa perangkat SDK membutuhkan tekstur yang dialokasikan melalui SDK sendiri daripada API grafis yang biasa. Jika Anda menggunakan subsistem Display SDK XR, Anda tidak perlu lagi mengandalkan plug-insSatu set kode yang dibuat di luar Unity yang menciptakan fungsi dalam Unity. Ada dua jenis plug-ins yang dapat Anda gunakan di Unity: Managed plug-ins (diproduksi. Rakitan NET dibuat dengan alat-alat seperti Studio Visual) dan plug-ins asli (pustaka kode asli yang spesifik platform). More info
Lihat di Glossary eksternal untuk blitJangka waktu singkat untuk transfer blok "bit". Pengoperasian yang mudah adalah proses mentransfer blok data dari satu tempat dalam memori ke yang lain.
Lihat di Glossary atau menyalin ke dalam tekstur SDK.

Subsistem tampilan memungkinkan penyedia plug-in untuk mengalokasikan tekstur. Bila memungkinkan, render Unity langsung ke tekstur untuk menghindari salinan yang tidak perlu. Unity juga dapat mengalokasikan tekstur untuk Anda jika diperlukan.

Dalam kasus-kasus berikut, Unity tidak dapat membuat langsung ke tekstur dan bukan render ke tekstur menengah dan kemudian menyalakan atau menyalin ke tekstur Anda:

• Jika efek gambar digunakan, tekstur Anda akan berlangsung di rantai.
• Pada PC dengan MSAA, render Unity ke tekstur multisampled dan kemudian menyelesaikan tekstur Anda pada akhir tumpukan cameraKomponen yang menciptakan gambar sudut pandang tertentu di tempat kejadian Anda. Output ditarik ke layar atau ditangkap sebagai tekstur. More info
  Lihat di Glossary.
• Di ponsel, dengan ekstensi menyelesaikan otomatis multisample, tekstur akan sangat diselesaikan ketika tekstur dibilas atau digunakan sebagai sumber atau tujuan untuk operasi apa pun selain menggambarnya. Lihat ekstensi EXT_multisampled_render_to_texture.
• Mempertahankan rendering, HDRkisaran dinamis tinggi
  Lihat di Glossary, dan penyangga perintah menyebabkan Unity untuk membuat tekstur menengah.
• Jika rendering ke subset layar, render Unity untuk tekstur menengah.
• Jika “ketelemen tekstur” tidak sesuai dengan apa Unity rendering ke (misalnya, Unity rendering setiap mata untuk tekstur terpisah, tetapi RenderPass dikonfigurasi untuk membuat array tekstur atau tekstur tunggal).
• Jika bendera kUnityXRRenderTextureFlagsLockedWidthHeight ditetapkan dan renderScale tidak 1.0.
• Jika bendera kUnityXRRenderTextureFlagsWriteOnly ditetapkan dan kebutuhan Unity untuk membaca kembali dari tekstur.

MSAA

Pada PC dan ponsel, mesin selalu menyelesaikan tekstur penyedia. Mesin ini melakukan penyelesaian implicit (di ponsel dengan render multi-sample untuk ekstensi tekstur) atau menyelesaikan eksplisit.

Di ponsel, penyedia harus mengaktifkan bendera kUnityXRRenderTextureFlagsAutoResolve dan membuat tekstur mereka dengan 1 sampel.

sRGB

Gunakan UnityXRFrameSetupHints.appSetup.sRGB untuk memeriksa apakah Unity mengharapkan untuk membuat format tekstur sRGB. Penyedia akhirnya memilih output texture formatFormat file untuk menangani tekstur selama rendering real-time oleh perangkat keras grafis 3D, seperti kartu grafis atau perangkat seluler. More info
Lihat di Glossary dari bidang colorFormat UnityXRRenderTextureDesc. Jika format adalah tipe sRGB, Unity mengubah sRGB menulis pada atau off tergantung pada ruang warna yang dipilih proyek aktif. Anda harus selalu sampel dari setiap tekstur sRGB dengan sRGB ke konversi linier di compositor Anda.

Tekstur kedalaman

Jika SDK Anda membutuhkan informasi mendalam, Anda dapat memperoleh depth bufferSebuah toko memori yang memegang kedalaman nilai z setiap pixel dalam gambar, di mana nilai z adalah kedalaman untuk setiap piksel yang diberikan dari pesawat proyeksi. More info
Lihat di Glossary dengan cara yang sama seperti buffer warna di atas. Nilai nativeDepthTex pada UnityXRRenderTextureDesc menentukan sumber daya asli. Secara default, Unity mencoba untuk berbagi penyangga kedalaman antara tekstur dengan desc yang mirip jika nativeDepthTex diatur ke kUnityXRRenderTextureIdDontCare.

Jika SDK Anda tidak memerlukan informasi mendalam, Anda harus mengatur UnityXRRenderTextureDesc::depthFormat ke kUnityXRDepthTextureFormatNone untuk menghindari penyelesaian yang tidak perlu.

Penanganan penyangga ganda dan triple

Selama pengajuan (lihat bagian Mengirimkan bingkai dalam lampu di bawah), Anda dapat menentukan ID tekstur yang berbeda setiap bingkai untuk menangani kasus di mana SDK perlu gambar dua atau tiga-buffer yang disatukan. Penyedia plug-in bertanggung jawab untuk mengelola koleksi UnityXRRenderTextureIds.

Bingkai siklus hidup

Ada dua metode yang bertanggung jawab untuk siklus hidup bingkai: PopulateNextFrameDesc, yang terjadi tepat sebelum rendering dimulai, dan SubmitCurrentFrame, yang terjadi segera setelah rendering selesai. Kedua metode yang disebut pada benang grafis.

Selama PopulateNextFrameDesc, penyedia tampilan diharapkan untuk melakukan hal berikut:

• Wait untuk kader (wait sampai Unity harus mulai mengirimkan perintah rendering lagi). Atau, ini dapat dilakukan dalam SubmitCurrentFrame.
• Mengakuisisi gambar berikutnya dan memberitahukan Unity apa tekstur ID untuk membuat ke depan melalui parameter nextFrame.

Selama metode SubmitCurrentFrame, penyedia tampilan diharapkan untuk melakukan berikut:

• Submit bingkai terakhir dalam lampu (misalnya, tekstur mata atau tekstur kedalaman) untuk ditampilkan di layar.
• Wait untuk kader, sebagai alternatif untuk menunggu selama PopulateNextFrameDesc.

Memblokir kader

Untuk menjaga latency dan throughput maksimal mungkin ketika rendering ke tampilan HMD, Anda perlu memastikan waktu yang tepat ketika Anda memperoleh pos dan menyerahkan tekstur. Masing-masing HMD memiliki tingkat refresh asli yang komositor mereka berjalan. Mengirimkan lebih cepat daripada hasil tingkat dalam pengalaman sub-optimal karena waktu atau pekerjaan yang tidak tertandingi.

Unity mengharapkan penyedia tampilan untuk memblokir, atau menunggu bingkai kader, selama siklus hidup bingkai. Unity mulai mengirimkan perintah rendering sesaat setelah 'menunggu' dari panggilan pemblokiran. Anda harus menyinkronkan waktu bangun ke kompor Anda dalam jendela tertentu. Beberapa SDK menyediakan jendela waktu bangun yang mengambang berdasarkan heuristik. Oculus memanggil ini “queue depan” (lihat Dokumentasi pengembang Oculus untuk informasi lebih lanjut). Valve menyebutnya “running start” (lihat slide 18 dan 19 presentasi ini).

Unity menunggu siklus hidup bingkai untuk menyelesaikan sebelum mulai mengirimkan perintah grafis pose-dependent.

Dimana menunggu kader

Penyedia dapat menunggu kader baik di PopulateNextFrameDesc atau di SubmitCurrentFrame.

Sementara Unity menyerahkan perintah grafis untuk bingkai pada benang grafis, loop simulasi bingkai berikutnya berjalan pada benang utama. Ini mengandung fisika, logika skrip, dll. PopulateNextFrameDesc disebut pada benang grafis setelah semua perintah rendering telah diserahkan, dan hanya setelah simulasi bingkai berikutnya dan semua pekerjaan grafis yang dijadwalkan di dalamnya selesai. Salah satu pekerjaan grafis yang menunggu PopulateNextFrameDesc adalah SubmitCurrentFrame untuk bingkai saat ini. Inilah sebabnya mengapa hal ini berlaku untuk menunggu kader di SubmitCurrentFrame. Selanjutnya, Unity tidak mulai rendering sampai PopulateNextFrameDesc selesai.

Dengan rincian ini dalam pikiran, ada beberapa trade-offs untuk menunggu kader di SubmitCurrentFrame bertentangan dengan PopulateNextFrameDesc. Misalnya, menunggu kader di SubmitCurrentFrame dapat menyebabkan masalah kinerja jika jadwal aplikasi pekerjaan grafis mahal selama simulasi. Karena SubmitCurrentFrame dijadwalkan dijalankan setelah rendering, pekerjaan grafis yang aplikasi dijadwalkan akan berjalan setelah SubmitCurrentFrame, tetapi sebelum PopulateNextFrameDesc. Dalam hal ini, penyedia menunggu di SubmitCurrentFrame, kemudian bangun mengharapkan Unity untuk memulai rendering. Namun, Unity memproses pekerjaan grafis aplikasi yang dijadwalkan sebelum panggilan PopulateNextFrameDesc, yang pada gilirannya memungkinkan Unity untuk memulai rendering. Keterlambatan ini antara bangun untuk rendering dan memproses pekerjaan grafis yang dijadwalkan dalam metode pembaruan dapat menyebabkan latency. Pengembang dapat mengoptimalkan ini dengan menjadwalkan pekerjaan grafis mereka setelah rendering untuk memastikan pekerjaan grafis dijadwalkan sebelum SubmitCurrentFrame.

Sementara Penyedia menunggu kader di SubmitCurrentFrame memungkinkan komputasi pekerjaan grafis untuk berjalan sejajar dengan benang utama, menunggu kader di blok PopulateNextFrameDesc benang utama Unity sepenuhnya. Ini diterima karena simulasi dan pekerjaan grafis lainnya telah selesai. Masalah mungkin terjadi ketika benang simulasi atau grafis memakan waktu terlalu banyak dan melebihi tingkat bingkai target perangkat. Hal ini dapat menyebabkan tingkat bingkai dipotong setengah sementara PopulateNextFrameDesc menunggu siklus berikutnya dalam kader.

Mengirimkan bingkai dalam lampu

Ketika Unity panggilan SubmitCurrentFrame, tekstur yang telah Anda mendirikan bingkai terakhir telah diberikan kepada, atau Unity telah mengirimkan perintah render ke driver grafis untuk membuat mereka. Unity sekarang dilakukan dengan mereka dan Anda dapat melewatinya ke compositor Anda.

Mengisi descriptor bingkai berikutnya

Setelah memblokir atau memperoleh bingkai berikutnya untuk membuat, Anda harus memberi tahu Unity yang tekstur untuk render ke dalam bingkai berikutnya, dan apa tata letak dari render pass (lihat Render Passes di bawah).

Render passes

Sebuah UnityXRRenderPass dapat melibatkan lulusan dan traversal graf sceneAdegan berisi lingkungan dan menu permainan Anda. Pikirkan setiap file Adegan unik sebagai tingkat yang unik. Di setiap Adegan, Anda menempatkan lingkungan, hambatan, dan dekorasi, pada dasarnya merancang dan membangun permainan Anda dalam potongan-potongan. More info
Lihat di Glossary. Ini adalah operasi intensif sumber daya, dan Anda harus mencoba untuk membatasi jumlah kali Unity melakukannya melalui trik seperti rendering tunggal.

Setiap UnityXRRenderPass mengandung tekstur output (yang dapat menjadi array tekstur), dan output UnityXRRenderParams seperti tampilan, matriks proyeksi, dan rect untuk membuat atau irisan array tekstur.

Untuk setiap bingkai, penyedia tampilan mengatur UnityXRRenderPass dan mengisi UnityXRRenderTextureId yang Unity akan membuat bingkai berikutnya.

Gunakan kasus untuk UnityXRRenderPass termasuk berikut:

• Dua potong stereo rendering (2 RenderPass x 1 RenderParams)
• Satu lulus stereo rendering (1 RenderPass x 2 RenderParams)

API mendukung kasus tambahan ini (tetapi Unity mungkin tidak bereaksi dengan benar sekarang):

• QuadObjek primitif yang menyerupai pesawat tetapi tepinya hanya satu unit panjang, hanya menggunakan 4 simpul, dan permukaan berorientasi pada pesawat XY ruang koordinat lokal. More info
  Lihat di Glossary melewati rendering stereo FOV lebar (4 RenderPass x 1 RenderParams)
• Satu lulus + lebar FOV stereo rendering (1 RenderPass x 2 RenderParams + 2 RenderPass x 1 RenderParams)
• rendering di atas:
  • Dua tekstur terpisah untuk setiap mata (di dalam dan luar)
  • Satu tekstur, pemasangan UV
• skenario pandangan eksternal (HoloLens BEV, mata 3 Mayo) (extra RenderPass)
• Dekat / jauh rendering untuk membandingkan objek atau orang-orang di tempat kejadian (2 RenderPass, proyeksi yang berbeda, target yang berbeda)

Aman untuk membuat asumsi ini:

• Satu tekstur per lulus (singlepass adalah satu tekstur-array)
• Jika single-pass, dua pose / proyeksi per lulus (atau rendering foveated)

Sitemap Proyek Unity dan XR SDK harus menggunakan pengaturan yang sama (diaktifkan / dinonaktifkan) untuk rendering tunggal-pass, karena pengaturan ini mempengaruhi pengguna Note:. Untuk memeriksa apakah rendering tunggal diaktifkan, gunakan shadersProgram yang berjalan di GPU. More info
Lihat di Glossary.UnityXRFrameSetupHints.appSetup.singlePassRendering.

Culling passes

Dua rendering pass dapat berbagi lulusan jika cullingPassIndexs mereka diatur ke nilai yang sama. cullingPassIndex memilih yang UnityXRCullingPass untuk digunakan. Melawan melewati harus diisi dalam UnityXRNextFrameDesc.