Teknologi UE5 Nanite di WebGPU

 (github.com/Scthe)
1 poin oleh GN⁺ 2024-09-06 | 1 komentar | Bagikan ke WhatsApp
  • Nanite WebGPU adalah proyek yang mengimplementasikan rendering bergaya Nanite milik UE5 di dalam browser dengan WebGPU, mencakup hierarki LOD meshlet, software rasterizer, billboard impostor, serta culling per instance/meshlet
  • Implementasi ini menjadikan kesederhanaan prapemrosesan input OBJ di browser dan eksperimen perubahan performa dengan mengubah pengaturan melalui checkbox dan slider sebagai tujuan utama
  • Demo menyediakan scene Jinx 640M triangles, Lucy/Dragons, dan scene hingga 1.7B triangles; segitiga putih pada Jinx adalah hasil software rasterization yang diproses dengan kompresi 32-bit karena keterbatasan WebGPU
  • Karena WebGPU tidak memiliki atomic<u64>, software rasterizer efisien berbasis visibility buffer sulit diimplementasikan secara langsung; implementasi saat ini memasukkan depth u16 dan octahedron normal 2*u8 ke dalam 32-bit dengan konsekuensi artefak presisi
  • Dalam implementasi bergaya Nanite yang sesungguhnya, tantangan utama bukan sekadar jumlah segitiga melainkan mesh simplification dan error metric; penulis menegaskan implementasinya, tidak seperti UE5, tidak memiliki simplification, streaming, compression, visibility buffer, atau 2-pass occlusion culling

Gambaran proyek

  • Nanite WebGPU adalah proyek yang mengimplementasikan rendering bergaya Nanite di browser web menggunakan WebGPU
  • Elemen utama yang disertakan adalah meshlet LOD hierarchy, software rasterizer, billboard impostor, serta culling per instance dan per meshlet
  • Mendukung model bertekstur dan per-vertex normal, serta menyediakan slider atau checkbox untuk tiap pengaturan
  • WebGPU hanya dapat digunakan di Chrome
  • Seluruh aplikasi dapat dijalankan secara offline dengan Deno, dan unit test shader juga ditulis dengan cara ini

Scene demo dan skalanya

  • Demo Jinx memiliki 120×120 instance dengan skala 640M triangles
    • Model Jinx tunggal disederhanakan dari 44k triangles menjadi 3k triangles, dengan 59 root meshlets
    • Segitiga putih adalah segitiga hasil software rasterization yang berada di antara area hardware rasterization dan impostor pada latar belakang yang jauh
  • Lucy and dragons menempatkan masing-masing dua objek sebagai 70×70 instance untuk membentuk 1.7B triangles
    • Pada scene sampel, hampir 98% segitiga dirasterisasi lewat software, dan disebutkan bahwa jalur ini jauh lebih cepat daripada hardware
  • Lucy adalah scene 110×110 instance dengan 1.2B triangles
    • Satu patung Lucy disederhanakan dari 100k triangles menjadi satu root meshlet berisi 86 triangles
  • Dragons adalah scene 70×70 instance dengan 1.2B triangles
    • Satu dragon disederhanakan dari 250k triangles menjadi satu root meshlet berisi 102 triangles
  • Bunnies adalah scene 500×500 instance dengan 1.2B triangles
    • Satu bunny disederhanakan dari 5k triangles menjadi satu root meshlet berisi 96 triangles
    • Karena ukurannya kecil, sebagian besar bunny terkena frustum culling

Fitur yang diimplementasikan

  • Meshlet LOD hierarchy

    • mesh preprocessing dijalankan di browser
    • meshoptimizer dan METIS digunakan melalui WebAssembly
    • File exporter juga disediakan agar tidak perlu menunggu prapemrosesan di antara refresh halaman

  • Software rasterizer

    • WebGPU tidak memiliki atomic<u64> yang dibutuhkan untuk implementasi efisien
    • Implementasi saat ini mengemas depth u16 dan normal berkode octahedron 2*u8 ke dalam 32-bit
    • Karena batasan 32-bit, presisi banyak dikorbankan, dan tujuannya adalah menunjukkan bahwa rasterizer ini berfungsi
    • Batasan ini juga memengaruhi depth pyramid yang digunakan untuk occlusion culling

  • Billboard impostors

    • Menggunakan 12 gambar di sekitar sumbu UP, lalu melakukan blend dengan dithering sesuai posisi kamera
    • Sudut pandang dari atas/bawah tidak ditangani
    • Mencakup diffuse dan normal untuk melakukan shading saat runtime
    • Impostors preview adalah demo dengan ukuran tekstur impostor yang diperbesar

Culling dan jalur rendering

  • Culling terdiri dari beberapa tahap
    • Per-instance: frustum culling dan occlusion culling
    • Per-meshlet: frustum culling dan occlusion culling
    • Per-triangle: hardware backface culling dan z-buffer
  • WebGPU tidak memiliki early-z
  • occlusion culling hanya menggunakan depth pyramid yang dibuat dari depth buffer frame sebelumnya
    • Tidak ada reprojection maupun pendekatan two-pass
    • Implementasi saat ini dianggap sudah cukup untuk melakukan culling pada banyak segitiga dan menilai peningkatan performa
  • Dapat beralih antara GPU-driven rendering dan implementasi CPU yang sederhana
    • Versi CPU tidak memiliki banyak optimasi, tetapi dapat dijalankan langkah demi langkah dengan debugger
  • Fitur “Freeze culling” memungkinkan pemeriksaan hanya pada apa yang dirender di frame terakhir sambil menggerakkan kamera

Kemudahan penggunaan dan debugging

  • Pergerakan menggunakan [W, S, A, D], naik/turun menggunakan [Z, SPACEBAR], dan gerak cepat menggunakan [Shift]
  • Jika hasil terlihat aneh, dapat diperiksa dengan menyalakan dan mematikan opsi culling
    • Ada beberapa bug kecil dalam implementasi
  • Segitiga putih adalah segitiga yang dirasterisasi lewat software
    • Karena WebGPU tidak memiliki atomic<u64>, depth dan normal dikompresi ke 32-bit
    • depth 16-bit dapat menimbulkan banyak artefak seperti z-fighting atau leak
    • Jika software rasterizer dimatikan, raw Nanite meshlets akan lebih mudah dilihat, tetapi performa bisa turun drastis
  • FPS dapat berfluktuasi karena VSync paksa dari browser, dan tombol “Profile” digunakan untuk memeriksa timing

Tujuan desain

  • Tujuan pertama proyek ini adalah kesederhanaan
    • Dimulai dari file OBJ dan seluruh pemrosesan dilakukan di dalam aplikasi
    • Tidak memerlukan tahap pra-pemrosesan terpisah seperti export Blender
    • Mengarah pada alur yang memungkinkan memasang breakpoint di loadObjFile() dan mengikutinya sampai frame pertama selesai
  • Tujuan kedua adalah eksperimental
    • Karena dibuat sebagai halaman web alih-alih dengan Rust dan Vulkan, Anda bisa mengeklik tautan serta mengubah checkbox atau slider untuk melihat perubahan performa
    • Anda bisa langsung memeriksa opsi mana yang penting, misalnya saat hanya mengubah satu pengaturan lalu FPS turun drastis
  • Banyak kode masih bisa dioptimalkan, tetapi sebelum masalah simplification terselesaikan, optimasi itu dianggap tidak terlalu penting

Perbedaan dari UE5 Nanite

  • Error metric menggunakan projected simplification error yang sederhana
  • Meshlet simplification menggunakan pendekatan sederhana
  • Tidak ada two-pass occlusion culling
    • Menambahkannya tidak sulit, tetapi merepotkan untuk di-debug dan menimbulkan interaksi dengan pengaturan GUI
    • Karena merusak keterbacaan kode, hal itu tidak sesuai dengan tujuan proyek
  • Tidak ada visibility buffer
    • Tidak dapat diimplementasikan karena batasan atomic<u64>
  • Tidak ada built-in shadows dan multiview
  • Tidak ada work queue di dalam shader
    • Untuk meshlet culling dan LOD selection, thread di-dispatch per meshlet
  • Tidak ada eviction dan streaming VRAM untuk LOD yang tidak digunakan
  • Tidak ada compression
  • Skalabilitasnya rendah untuk banyak objek yang berbeda
    • Fokusnya pada penggunaan memori yang dapat diprediksi dalam kasus demo
    • Perlu mengetahui sebelumnya batas atas drawn meshlets untuk buffer yang menyimpan data antar stage
  • Tidak ada implementasi BVH atau hierarki untuk instance
    • Frustum dan occlusion culling dilakukan terhadap semua instance

Kondisi yang diwakili oleh jumlah segitiga

  • Sulit menilai performa hanya dari angka “puluhan miliar triangles”, dan performa dipengaruhi banyak faktor

  • Dense meshes

    • Jika ada banyak dense mesh di dekat kamera, hal itu bisa berdampak buruk pada performa
    • Namun, jika cukup dekat hingga menutupi banyak area layar, occlusion culling akan bekerja
    • Dense geometry memiliki meshlet kecil, sehingga area yang ditempati di layar kecil dan lebih mudah terkena occlusion/cone culling

  • Instance count

    • Setiap instance memiliki transform matrix mat4x3, sehingga mengonsumsi VRAM
    • Selama frame, daftar item yang akan dirender juga harus disimpan
    • Dalam kasus terburuk, setiap instance merender meshlet yang paling dense
    • Dalam implementasi ini dialokasikan instanceCount * bottomLevelMeshletsCount * sizeof(vec2u) byte
    • Batas default storage buffer WebGPU di Chrome adalah 128MB, dan scene demo disesuaikan dengan batas ini

  • Scene arrangement

    • Scene dalam aplikasi menata objek dalam bentuk persegi
    • Objek yang jauh hanya terlihat sebagian, tetapi coarse meshlet LOD mencakup area yang lebih luas sehingga menimbulkan overdraw
    • Penempatan grid yang rapat merender lebih banyak segitiga dekat, tetapi karena perbedaan kedalamannya kecil, ini menguntungkan bagi occlusion culling
    • Objek yang berjauhan dapat menyebabkan piksel jauh acak mencemari depth pyramid

Mengapa scene Jinx sulit

  • Karakter Jinx bertubuh ramping dan memiliki ruang kosong antara lengan dan badan, sehingga menyulitkan occlusion culling
  • Modelnya tidak tersederhanakan dengan baik, sehingga LOD paling coarse sekalipun masih memiliki 3k triangles
  • Muncul situasi di mana banyak segitiga berukuran 1 piksel menumpuk
  • Software rasterizer sangat membantu, tetapi karena penataan scene, sebagian besar instance dirender sebagai impostor
  • Untuk area dekat, hardware rasterizer yang menangani, dan hardware rasterizer, software rasterizer, serta impostor masing-masing punya keunggulan berbeda

Hal yang mengejutkan dalam implementasi Nanite

  • Tujuan DAG bukan sekadar memakai lebih sedikit segitiga untuk objek jauh, melainkan menjaga konsistensi mendekati 1 pixel == 1 triangle di seluruh layar
  • Discrete LOD mesh memiliki geometry terpisah untuk tiap LOD, sehingga sulit menangani saat diperlukan tahap perantara; yang dibutuhkan adalah continuous LOD
  • Hierarki meshlet memungkinkan geometry di-sampling pada tingkat detail yang dipilih
  • Lebih banyak waktu dihabiskan untuk culling dan pekerjaan meshlet daripada untuk Nanite itu sendiri
  • Hierarki LOD meshlet mudah dibuat agar berjalan, tetapi sulit dibuat efisien
  • Jika mesh tidak tersederhanakan dengan rapi, bisa muncul situasi seperti Jinx, dengan sekitar 3.000 triangles yang menutupi satu piksel saja
  • Jika menginginkan pixel-sized triangles, software rasterizer diperlukan, dan billboard impostor juga berguna sebagai fallback yang berfokus pada stabilitas

Masalah mesh simplification

  • Simplification bukan masalah “menerima mesh lalu menguranginya menjadi X% triangles”, melainkan masalah yang dilakukan dalam konteks meshlet dan METIS
  • UE5 menggunakan mesh simplification code miliknya sendiri sebagai tahap pertama dalam asset pipeline
    • Pengurangan biaya di sini memberi manfaat berantai ke seluruh sistem setelahnya
    • Dalam materi SIGGRAPH Brian Karis, disebutkan bahwa graph LOD berakhir pada satu root cluster, dan model apa pun dapat disederhanakan hingga 128 triangles
  • Model Jinx mengalami masalah karena simplification berhenti pada titik tertentu
    • Bahkan jika memasukkan X triangles sebagai input, hasilnya bisa kembali menjadi X triangles yang sama
    • Algoritme crash karena assertion
    • Setelah itu, bagian mesh yang tidak cukup berkurang diubah agar DAG mengizinkan beberapa root
  • Model bunny awalnya disederhanakan menjadi satu meshlet 128 tris, tetapi setelah kondisinya diubah, muncul masalah bahwa ia tidak menuju single root
    • Banyak meshlet tidak berhasil cukup mengurangi triangle, dan juga banyak meshlet “tidak penuh” dengan kurang dari 128 triangles
  • Diskusi terkait:

Error metric

  • Saat merender mesh 20.000.000 triangle sebagai hierarki meshlet, perlu dipilih meshlet mana yang “benar”
  • Masalah pemilihan ini adalah inti Nanite, dan simplification, meshlet DAG, serta software rasterizer lebih merupakan prasyarat untuk menanganinya
  • Implementasinya menggunakan projected simplification error yang disediakan oleh meshoptimizer
  • Penulis menilai metrik ini bukan metrik yang baik untuk Nanite, dan atribut vertex lain juga seharusnya dimasukkan ke dalam fungsi
    • Harus bisa memberikan bobot untuk tiap atribut
    • Normal pada wajah Jinx menjadi masalah besar
  • Referensi yang digunakan:

Mengapa software rasterizer tidak menghasilkan tekstur

  • Pada hardware rasterizer, depth texture, color, dan normal dapat ditulis bersama sesuai hasil depth test
  • Jika beberapa thread menulis ke piksel yang sama pada software rasterizer, akan terjadi race condition
  • Solusi umum untuk ini adalah visibility buffer
    • Menghasilkan sceneUniqueTriangleId dari triangle terdekat untuk tiap pixel
    • Menggabungkannya dengan depth 32-bit menjadi nilai 64-bit dan menggunakan 64-bit atomic operation
    • Pada pass terpisah, triangle dirasterisasi ulang dan barycentric coordinates dihitung untuk shading
  • WebGPU tidak memiliki 64-bit atomics sehingga pendekatan ini tidak bisa digunakan
  • Tujuan proyek ini adalah menunjukkan bahwa software rasterize dapat bekerja, sehingga model software-rasterize di latar belakang dibuat berwarna putih dan hanya menyediakan shading yang masuk akal

Penilaian terhadap implementasi Nanite sendiri

  • Jawaban paling sederhana adalah menggunakan UE5
  • Untuk memasukkan teknologi ini ke engine yang sudah ada, penulis menilai perlu lebih dulu mengimplementasikan compute-based graphics pipeline dan GPU-driven rendering pipeline
  • Masalah seperti multi-step culling, scene/world chunk management, dan animated meshes akan muncul lebih dulu
  • Setelah tahap-tahap ini stabil, urutan yang disarankan adalah mencoba software rasterizer, lalu menambahkan teknologi mirip Nanite
  • Pada toy renderer, hierarki meshlet dasar bisa menjadi proyek akhir pekan, tetapi implementasi nyata harus menangani masalah simplification dan error metric

Alat dan referensi yang digunakan

  • meshoptimizer adalah fondasi inti implementasi proyek
    • Pada versi meshoptimizer yang lebih baru, ada meshopt_SimplifySparse untuk membuat clone Nanite
    • Proyek ini tidak diperbarui ke versi tersebut agar tetap mempertahankan status yang diuji selama pengembangan
  • Menggunakan METIS
  • Emscripten digunakan untuk menjalankan meshoptimizer dan METIS di browser
  • Model Jinx menggunakan Arcane - Jinx dari Sketchfab, dengan penggabungan tekstur, penyesuaian UV, dan penghapusan senjata

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-06
Komentar Hacker News

  • Oh, bagus. Ini bisa dibilang implementasi pihak ketiga untuk pemutaran Nanite
    Nanite merepresentasikan mesh grafis dengan sangat cerdas. Ia bukan tree, melainkan directed acyclic graph, sehingga pengulangan menjadi link, bukan salinan; sebuah mesh berbagi sub-mesh, dan sub-mesh itu juga bisa dibagikan lagi. Level of Detail (LOD) internal mesh juga didukung, sehingga sub-mesh akan dikeluarkan ketika sudah cukup kecil
    Karena itu, konten berulang yang sangat besar bisa ditangani dengan data terbatas dan waktu rendering yang cepat. Wawasannya adalah bahwa jumlah piksel di layar terbatas, jadi jumlah pekerjaan rendering yang benar-benar diperlukan pun memiliki batas atas
    Video SIGGRAPH yang dijelaskan oleh orang dari Epic sangat bagus. Desain GPU saat ini kurang cocok dengan Nanite, sehingga diperlukan operasi hardware baru jika ingin memindahkan lebih banyak pemrosesan ke GPU. Dengan Nvidia yang sedang tersita perhatiannya oleh pasar AI, saya ragu perubahan seperti itu akan terjadi
    Agar pendekatan ini efektif, scene perlu memiliki banyak instancing. Ini cocok untuk game AAA yang membuat konten luas dengan memakai ulang sejumlah objek terbatas, seperti aula dengan patung-patung identik dalam demo Unreal Engine. Jika menonton video Cyberpunk 2077 sambil mencari pagar pembatas dan tumpukan sampah, Anda bisa melihat hal-hal yang sama terus berulang dalam konteks yang benar-benar berbeda
    Pembuatan mesh Nanite rumit karena banyak offset link internal, dan sejauh ini hanya editor Unreal Engine yang menanganinya. Karena sisi playback sudah menjadi open source, besar kemungkinan seseorang akan membuat tool authoring-nya juga
    Namun offset internal dalam format ini bisa menjadi attack surface, dan tampaknya dapat disalahgunakan melalui konten yang dimanipulasi, seperti file Microsoft Word .doc berbahaya

    • Memang dibuat directed acyclic graph untuk graph cut, tetapi data akhir di disk hanyalah daftar datar cluster dengan kriteria include/exclude. Sepertinya ada salah paham yang cukup besar tentang untuk apa DAG dipakai dan bagaimana ia dibuat
      DAG dibuat secara dinamis berdasarkan data vertex, dan tidak berkaitan dengan bagaimana artist menyusun sub-mesh. Ini juga bukan seperti “pengulangan menjadi link”
      Selain itu, hasil graph cut berbeda untuk tiap instance objek sehingga instancing tradisional tidak bisa dipakai, jadi saya tidak mengerti mengapa scene harus punya banyak instancing agar efektif
    • Dulu pada era 2000-an, saat mengembangkan untuk PS3, kami mencari cara untuk memanfaatkan banyak resource komputasi Cell dengan cukup baik dan mengakali bandwidth memori RSX yang terbatas. Ruang penyimpanan Blu-ray bisa dipakai dengan cukup lapang
      Saat itu saya cukup jauh mengerjakan sesuatu yang mirip Nanite, yang kami sebut compressed mesh. Itu adalah contoh klasik arogansi engineering yang meleset
      Pekerjaan awal tampak menjanjikan, tetapi semakin dalam kami menggali masalahnya, semuanya menjadi semakin kompleks. Kami harus membuat seluruh pipeline pembuatan asset, dan lingkupnya terlalu besar untuk diselesaikan tepat waktu dengan hasil yang terlihat bagus tanpa membuat memori meledak
      Kami sempat sampai pada tahap yang terlihat seperti merender mesh skala besar dengan Level of Detail bertingkat, tetapi sangat lambat dan harus memaksa GPU bekerja keras untuk mencapai akurasi subpiksel; kalau tidak, hasilnya tampak buruk. Itu eksperimen yang menarik, tetapi terlalu berat untuk hardware, dan tugasnya terlalu besar untuk ditangani sendirian
      Ketika Epic memperkenalkan Nanite, saya benar-benar terkejut. Mereka berhasil melakukan hal yang tidak bisa saya lakukan, dengan cara yang jauh lebih baik daripada bayangan terbaik saya. Ini salah satu teknologi yang saat muncul bukan sekadar hype, melainkan benar-benar solusi, dan merupakan permata teknis dalam dunia grafis modern. Seandainya Epic adalah perusahaan publik, saya bahkan akan mempertimbangkan menaruh uang cukup besar hanya karena teknologi Nanite
    • Presentasi SIGGRAPH yang disebut mungkin adalah "A Deep Dive into Nanite Virtualized Geometry": https://www.youtube.com/watch?v=eviSykqSUUw
      Video pengantar singkat tingkat tinggi juga cukup bagus. Judulnya "What is virtualized micropolygon geometry? An explainer on Nanite": https://www.youtube.com/watch?v=-50MJf7hyOw
    • Meski bukan engine arus utama, engine game ECS kecil berbasis Rust, Bevy, juga mendukung sesuatu yang mirip dengan nama fitur "Virtual Geometry": https://bevyengine.org/news/bevy-0-14/#virtual-geometry-expe...
      Ada juga tulisan teknis mendalam dari salah satu penulis fitur ini: https://jms55.github.io/posts/2024-06-09-virtual-geometry-be...
    • Setelah membaca paper-paper-nya, kesan saya manfaat terbesarnya berasal dari koordinat terkuantisasi dan Level of Detail dinamis pada patch kecil, bukan pada keseluruhan mesh
      Logika Nanite yang saya pahami adalah mempertahankan akurasi mesh kira-kira pada presisi 1 piksel. Misalnya, jika setelah proyeksi perspektif error hanya sekitar setengah piksel, kita bisa memakai mesh detail rendah dengan koordinat yang dibulatkan kira-kira ke 10 bit
      Saya samar-samar ingat kuantisasi punya dua peran. Selain mengurangi ukuran penyimpanan data, ia juga membantu pembuatan Level of Detail dengan men-snap vertex ke posisi yang sama di ruang, sehingga duplikasi bisa dihapus setelahnya

  • Sudah disebut beberapa kali di thread ini, tetapi Bevy juga memiliki implementasi ide Nanite. Kadang ini disebut virtual geometry. Saya adalah penulisnya, jadi bisa menjawab pertanyaan :)
    Scthe melakukan pekerjaan yang sangat bagus pada proyek ini. Kami berdiskusi tentang berbagai bagian proses pengerjaannya, dan berdasarkan pengalaman itu kode Bevy juga diperbaiki: https://github.com/bevyengine/bevy/pull/15023
    Selalu menyenangkan melihat lebih banyak orang masuk ke bidang ini. Nanite punya begitu banyak ide keren

  • Apakah demo ini memakai string user agent untuk menentukan kompatibilitas? Itu tidak bagus. Kompatibilitas fitur seharusnya dinilai per kasus dengan mendeteksi atau mencoba fitur tertentu secara langsung
    Saya memakai Chromium, bukan Chrome, dan selalu memakai WebGPU, tetapi demo ini menyuruh saya memakai Chrome. Secara etis saya tidak bisa begitu. Saya benar-benar ingin mencoba demo ini, dan proyeknya tampak digarap dengan banyak usaha

    • Sebagai catatan, ini juga tidak berjalan di Chrome di Linux maupun di Android. Meski untuk browsing sehari-hari saya hampir selalu memakai Firefox. Ada sesuatu yang cukup aneh pada logika deteksinya
    • Sepertinya bukan begitu. Di Firefox dengan dukungan WebGPU eksperimental diaktifkan, demo gagal dengan kesalahan kompilasi shader, bukan pesan terpisah
    • Menargetkan deteksi per fitur itu bagus
      Saat membuat framework komponen untuk browser sendiri, deteksi sering kali tidak memungkinkan sehingga saya harus bergantung pada browser sniffing. Kode Modernizr berisi banyak peretasan yang sangat cerdas untuk deteksi fitur, dan kadang peretasan yang sangat kotor. Ada pekerjaan luar biasa besar untuk membuat kode deteksi yang dapat dipercaya, dan deteksi pun biasanya dilakukan lewat efek samping
      Dugaan saya, deteksi fitur Web3D tidak sederhana. Dari pencarian cepat pun saya tidak melihat pustaka deteksi fitur Web3D yang jelas
      Sebagian kode Modernizr untuk mendeteksi dukungan :checked seperti ini:
      Modernizr.addTest('checked', function(){
      return Modernizr.testStyles('#modernizr input {width:100px} #modernizr :checked {width:200px;display:block}', function(elem, rule){
    • Saya tidak tahu build yang Anda pakai, tetapi saya memakai Ungoogled Chromium dan string user agent-nya persis sama dengan Google Chrome
      Apakah Anda sudah mengaktifkan izin WebGL untuk situs itu di pengaturan situs? Seingat saya, di tempat saya default-nya mati
    • Sepertinya demonya sendiri memang rusak. Muncul kesalahan seperti ini:
      WebGPU error [frame][validation]: Fill size (7160950) is not a multiple of 4 bytes.
      • While encoding [CommandEncoder "main-frame-cmd-buffer"].ClearBuffer([Buffer "rasterize-sw"], 0, 7160950).

  • Ini disertasi doktoral tahun 2009 yang agak tenggelam dari Federico Ponchio, penemu algoritma penyederhanaan mesh dinamis yang menjadi dasar Nanite. Gambarnya juga banyak
    https://vcg.isti.cnr.it/~ponchio/download/ponchio_phd.pdf halaman 107

  • Keren bahwa ini berjalan sampai taraf tertentu, tetapi karena WebGPU tidak memiliki operasi atomik 64-bit, harus ada kompromi yang cukup kasar
    Semoga suatu saat ditambahkan sebagai ekstensi opsional. Setidaknya di hardware kelas desktop, dukungan hardware-nya hampir universal. AMD dan Nvidia sudah memilikinya sejak lama, dan Apple mendukungnya mulai M3

    • Operasi atomik dipakai untuk apa di rasterizer? Saya tidak tahu apa yang dilakukan operasi atomik di dalam pipeline rendering. Saya juga sudah melihat GitHub-nya, tetapi tidak menemukan lokasi yang saya kira akan memakai operasi atomik
    • Mulai M2

  • Di iPhone 12 Pro Max tertulis tidak ada WebGPU, tetapi setelah saya mengaktifkannya di fitur eksperimental, situs demo WebGPU lain[1] berjalan. Ada yang berhasil menjalankan ini di iPhone? Akan bagus kalau aplikasi web-nya memberi tahu lebih detail apa yang gagal
    [1] https://webgpu.github.io/webgpu-samples/?sample=texturedCube

    • Saya mengaktifkan WebGPU di Safari, tetapi muncul banyak kesalahan shader
      WebGPU error [init][validation]: 6 errors generated while compiling the shader: 50:22: unresolved call target 'pack4x8snorm' 50:9: cannot bitcast from '⊥' to 'f32' 54:10: unresolved call target 'unpack4x8snorm' 59:22: unresolved call target 'pack4x8unorm' 59:9: cannot bitcast from '⊥' to 'f32' 63:9: unresolved call target 'unpack4x8unorm'
    • Dukungan WebGPU di Safari belum selesai, jadi masih berada di fitur eksperimental

  • Nama dan deskripsinya sangat membingungkan dan tampaknya juga berpotensi melanggar merek dagang. Berbeda dari klaimnya, ini sama sekali tidak terkait dengan Nanite asli di UE5, dan tampaknya merupakan implementasi serupa oleh seseorang yang tidak terkait dengan UE5
    Ada juga Virtual Geometry milik Bevy yang menyediakan fungsi serupa. Ditulis dalam Rust dan terintegrasi ke game engine, jadi kemungkinan jauh lebih berguna: https://jms55.github.io/posts/2024-06-09-virtual-geometry-be...

    • Sepertinya bukan masalah besar. Dari README, jelas bahwa ini adalah implementasi
      Kalau saya mengatakan “mengimplementasikan GPT-3 milik OpenAI dalam JS”, orang akan memahami bahwa saya mengambil arsitektur dari whitepaper lalu mengimplementasikannya ulang

  • Ini sebenarnya bukan UE5 Nanite yang berjalan di WebGPU. Ini adalah implementasi independen dari ide yang sama seperti Nanite
    Teknik ini mulai muncul di beberapa tempat. Memang benar Nanite membuat ide itu terkenal, tetapi Nanite bukan nama tekniknya, melainkan nama implementasi tertentu

  • Saya penasaran sejauh mana engine lain dalam hal level of detail dan sistem serupa
    Godot memiliki fitur level of detail otomatis, dan kelihatannya cukup bagus: https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod...
    Unity juga memiliki sistem level of detail, tetapi meski engine ini populer, model level of detail harus dibuat secara manual: https://docs.unity3d.com/Manual/LevelOfDetail.html kecuali jika mencari plugin di Asset Store
    Saya juga melihat pendekatan menarik di engine yang kurang dikenal bernama NeoAxis: https://www.neoaxis.com/docs/html/NeoAxis_Levels.htm Namun performanya sangat buruk di RX580 lama saya, dan saya belum mencobanya di A580 saya sekarang
    Menurut saya, dalam kemampuan menampilkan banyak hal di layar, Unreal cukup jauh di depan para pesaingnya. Kekurangannya adalah para artist jadi ingin memasukkan aset berkualitas lebih tinggi ke dalam game, sehingga ukuran instalasi bisa membengkak besar

    • Secara teori, Nanite lebih unggul daripada level of detail yang sudah diprakomputasi. Dalam praktiknya, sulit untuk menyimpulkannya begitu saja. Sulit menandingi level of detail yang dibuat langsung oleh artist, dan tidak masuk akal juga mengharapkan demikian
      Biaya performanya juga besar. Nanite atau virtual geometry tidak terlalu cocok dengan GPU modern. Seingat saya, fill rate maksimumnya sekitar 1/4. Ini karena rasterisasi GPU bekerja dalam unit quad 2x2, bukan per piksel seperti shader
    • Intel Arc GPU sangat buruk untuk rendering Nanite. Alasannya, ia tidak mendukung secara hardware baik indirect draw yang banyak digunakan dalam renderer berbasis GPU maupun operasi atomik 64-bit yang diperlukan Nanite. Intel mengemulasikan indirect draw lewat software, sehingga lambat

  • Setiap kali melihat scene rendering dengan begitu banyak geometri statis berulang seperti ini, saya teringat suara orang menyebalkan dari video vaporware lama yang menggembar-gemborkan “detail tak terbatas”
    Berbeda dengan sesuatu yang lama itu, Nanite tampaknya benar-benar menyelesaikan masalah tersebut. Seingat saya, pihak sana pernah disebut menggunakan sesuatu seperti octree

    • Perusahaan yang membuat klaim itu sepertinya bernama Euclidean. Sepertinya perusahaan Australia
      Menurut rumor online, mereka menggunakan octree, tetapi video-video Euclidean berikutnya dengan tegas membantahnya