1: Saya tidak bisa mengerti pada titik mana turun pipa LOD Chunked bahwa mesh akan terpecah menjadi potongan-potongan. Apakah ini selama pembuatan mesh awal, atau apakah ada algoritma terpisah yang melakukan ini.
Tidak masalah. Misalnya, Anda dapat mengintegrasikan chunking ke dalam algoritma generasi mesh Anda. Anda bahkan dapat melakukan ini secara dinamis, sehingga level yang lebih rendah ditambahkan secara dinamis (misalnya saat pemain bergerak lebih dekat) menggunakan algoritma penyempurnaan seperti plasma. Anda juga dapat menghasilkan mesh resolusi tinggi dari input artis atau data pengukuran elevasi dan menggabungkannya ke dalam semua potongan LOD pada waktu penyelesaian aset. Atau Anda bisa mencampur dan mencocokkan. Itu sangat tergantung pada aplikasi Anda.
2: Saya mengerti bahwa struktur data Quadtree digunakan untuk menyimpan data LOD Chunked, saya pikir saya sedikit kehilangan intinya, tetapi Apakah quadtree menyimpan data vertex dan segitiga untuk setiap tingkat pembagian?
Belum tentu. Pohon hanya menyimpan informasi tentang geometri dan cara membuatnya. Ini bisa berarti memiliki daftar simpul / wajah di setiap simpul pohon. Lebih realistis di zaman sekarang ini, Anda akan menyimpan gagang jerat / instance dalam memori GPU.
3a: Bagaimana jarak kamera biasanya dihitung. Ketika membaca tentang quadtree, kotak pembatas yang selaras dengan Axis disebutkan banyak. Dalam hal ini akankah masing-masing potongan memiliki kotak tabrakan untuk mendeteksi kamera atau pemain terdekat? atau adakah cara yang lebih baik untuk melakukan ini? (raycast mungkin?)
Opsi yang sangat murah dan mudah adalah dengan menggunakan jarak ke titik tengah potongan dan kemudian memperbaikinya. Anda tahu bahwa jarak ini selalu dianggap remeh: jika titik pusatnya berada pada jarak Z, ini berarti bahwa separuh bongkahannya lebih dekat dari itu. Namun yang tidak kita ketahui adalah orientasinya. Jika kita melihat potongan lebar wedge-on, bit terdekat dari jarak akan berada di kejauhan Z-w. Namun, jika kita melihat chunk corner-first, bit terdekat akan berada di kejauhan Z-sqrt(2)*w. Jika Anda bisa hidup dengan ketidakpastian ini (Anda hampir selalu bisa), Anda sudah selesai. Perhatikan bahwa Anda juga dapat memperbaiki sudut tampilan menggunakan trigonometri dasar.
Saya lebih suka menghitung jarak minimum absolut dari kamera ke bongkahan untuk meminimalkan artefak. Dalam praktiknya, ini berarti melakukan uji jarak titik-kuadrat . Ini sedikit lebih banyak pekerjaan daripada menghitung jarak ke titik-titik pusat, tetapi tidak seperti Anda akan melakukan miliaran dari setiap frame ini.
Jika Anda dapat memanfaatkan mesin fisika Anda untuk melakukan ini maka tentu saja melakukannya, tetapi Anda benar-benar ingin memikirkannya lebih dalam hal "kueri jarak" daripada "tabrakan".
3b: Apakah potongan menghitung jarak kamera sendiri?
Itu benar-benar tergantung pada desain mesin Anda. Saya akan merekomendasikan menjaga daun relatif ringan. Bergantung pada platform Anda, hanya panggilan overhead yang memiliki beberapa ribu terrain-chunks melakukan pembaruan mereka sendiri setiap frame dapat berdampak serius pada kinerja.
4: Apakah setiap chunk memiliki "resolusi" yang sama. misalnya pada tingkat atas mesh akan menjadi 32x32, masing-masing node akan dibagi lagi menjadi 32x32.
Mereka tidak harus, tetapi nyaman jika semua bongkahan mengambil jumlah ruang yang sama. Kemudian Anda dapat melakukan manajemen memori (GPU) Anda dalam unit "chunks". Ini juga lebih mudah untuk menghapus / menyembunyikan jahitan antara dua bongkahan dengan ukuran yang berbeda jika satu resolusi merupakan kelipatan dari yang lain karena mereka berbagi lebih banyak simpul. (mis: 32x32 dan 64x64 lebih mudah dikelola daripada 32x32 dan 57x57) (terima kasih Guiber!). Jika Anda memiliki alasan yang baik untuk memvariasikan ukuran geometri chunk, tentu saja lakukanlah.
