Yang merupakan metode LOD terbaik untuk rendering planet?


23

Saat ini saya sedang mengerjakan tesis saya, ini adalah mesin untuk membuat medan ukuran planet.

Saya masih menyelesaikan penelitian saya dan saya telah menemukan banyak hal tentang subjek ini, masalahnya adalah saya tidak bisa memutuskan metode Level of Detail (LOD) mana yang harus saya gunakan.

Saya tahu tentang geomipmapping, geometri clipmaps (GPU) dan chunked LOD oleh Ulrich yang bekerja dengan baik pada medan yang besar dan dapat digunakan untuk membuat 6 wajah kubus dan kemudian "membuat kubus" kubus dengan metode ini dan saya mengerti bagaimana menerapkan semua metode ini pada GPU menggunakan C ++ / OpenGL / GLSL (menggunakan metode seperti ROAM atau metode lain yang tidak menggunakan kubus berada di luar jangkauan saya karena texturing adalah hal yang menyebalkan). Juga saya baru-baru ini masuk ke tutorial rendering medan menggunakan shading tessellation di sini

Jadi, saya tidak punya waktu untuk menerapkan SEMUA metode dan melihat mana yang terbaik dan lebih cocok untuk skala planet dan saya meminta di sini untuk melihat apakah seseorang telah membuat perbandingan semacam ini dan membantu saya memutuskan metode mana harus saya terapkan dan gunakan (tutor saya agak gila dan ingin saya melakukan sesuatu dengan icosahedron, tapi saya tidak bisa memahami metode itu kecuali menggunakan ROAM)

Bagaimanapun, jika Anda dapat membantu saya memutuskan atau memiliki saran atau metode lain, saya akan sangat menghargai. Salah satu syaratnya adalah bahwa metode tersebut harus dapat mengimplementasikan sisi GPU (setidaknya sebagian besar dari itu) untuk mencegah kemacetan CPU.

Permintaan lain adalah bahwa saya tahu ada masalah numerik tentang presisi dengan pelampung ketika mendapatkan banyak detail di medan, saya tidak tahu bagaimana menyelesaikannya, saya membaca solusi di forum tetapi tidak bisa memahami cara mengimplementasikan, saya kehilangan jejak utas itu dan saya ingin tahu bagaimana menyelesaikan masalah presisi ini.

Saat ini saya membaca tentang beberapa transformasi matriks untuk menyelesaikan ketepatan float, masalah z-fighting, frustum culling dengan nilai-z dinamis, dan representasi data untuk bongkahan (menggunakan ruang tambalan dengan pelampung dan posisinya di dunia berkoordinasi ganda) sehingga Saya pikir saya bisa menyelesaikan masalah presisi dengan mudah. Saya masih membutuhkan perbandingan antara metode LOD dengan pendapat dan saran Anda untuk memutuskan mana yang lebih baik untuk proyek ini. Mempertimbangkan kesulitan implementasi vs kualitas visual vs kinerja, saya ingin yang terbaik.

Sesuatu yang saya lupa sebutkan adalah bahwa generasi adalah hibrida, maksud saya, saya harus dapat membuat planet ini sepenuhnya menggunakan GPU (ketinggian dihitung dengan cepat) dan / atau menggunakan gambar peta ketinggian tinggi dan menambahkan rincian dengan GPU (titik) shader). Tekstur akan menjadi bagian samping. Saya akan kesulitan belakangan, saat ini saya senang menggunakan hanya warna tergantung pada ketinggian, atau mungkin menggunakan beberapa jenis tekstur suara yang dihasilkan pada fragmen shader.


6
Tidak ada metode universal "terbaik". Hanya Anda yang tahu semua persyaratan proyek Anda dan Anda tampaknya tahu tentang sejumlah opsi LOD. Akhirnya, Anda harus benar-benar mengambil keputusan ini sendiri karena itu bagian dari tesis Anda. Tesis Anda menunjukkan pengetahuan Anda tentang topik yang Anda pelajari. Jika Anda tidak tahu mana yang terbaik untuk kebutuhan Anda, mungkin Anda harus mempelajari opsi sedikit lebih banyak.
MichaelHouse

@ Byte56 Anda benar, dan saya sedang meneliti banyak tentang metode LOD, saya hanya ingin melihat beberapa saran dari orang lain yang telah menerapkan beberapa dari mereka dan berbicara tentang kinerja dan kualitas visual sehingga saya dapat memilih satu ... bagaimanapun juga, terima kasih untuk komentar Anda :) dan ngomong-ngomong, saya saat ini memahami tentang shading tessellation dan menemukan tutorial yang bagus (tautan pada pertanyaan utama) dan saya pikir saya akan melakukannya, dijelaskan untuk rendering hanya medan, tetapi saya dapat memodifikasinya untuk membuat 6 wajah dan membulatkan kubus.
nosmirck

vterrain.org/LOD memiliki banyak informasi tentang topik render medan. Bagian yang ditautkan mencantumkan makalah & sumber lain untuk tingkat algoritme detail. vterrain.org/LOD/spherical.html berkaitan dengan kisi-kisi bulat (mis. planet).
Exilyth

@sarahm Saya tahu, di situlah saya mulai, saya merah semuanya ... Saya hanya perlu perbandingan antara beberapa metode LOD untuk memilih mana yang diterapkan, saya benar-benar dapat melakukan semuanya tetapi saya tidak punya waktu ... Lagi pula , Saya akan menggunakan metode menggunakan tessellation shaders, ini adalah sesuatu yang baru dan tidak ada implementasi yang dilakukan pada permukaan bola :)
nosmirck

3
Saya tahu Anda telah melakukan banyak penelitian, dan saya tidak yakin apakah ini telah menemukan desktop Anda, tetapi lihatlah "Desain Mesin 3D untuk Globes Virtual: Patrick Cozzi dan Kevin Ring" - Saya menemukan banyak informasi praktis yang baik di sana. Itu diteliti dengan baik dan, sebagaimana dikatakan, diambil dari sudut pandang yang sangat praktis. HTH dalam beberapa cara.
Schoenobates

Jawaban:


17

Akhirnya, setelah banyak meneliti saya dapat menyimpulkan bahwa, seperti yang dikatakan seseorang sebelumnya, Tidak ada metode "terbaik" yang universal. Tetapi penelitian saya membuat saya mengetahui hal-hal berikut:

Bergantung pada jala Anda akhirnya akan menggunakan:

  • Spherified Cube: metode LOD apa pun dengan implementasi quadtree akan berfungsi dengan baik, Anda hanya harus berhati-hati pada kasus khusus seperti perbatasan antara wajah, yang mana, quadtree Anda harus memiliki pointer ke tetangga di wajah adyacent di setiap level.
  • Yang lain: Saya pikir ROAM (versi yang lebih baru 2.0 atau ekstensi lain seperti BDAM, CABTT atau RUSTIC) akan bekerja dengan baik, namun, algoritma ini sulit untuk dikerjakan, memerlukan lebih banyak memori dan sedikit lebih lambat dibandingkan dengan pendekatan lain dengan kubus.

Ada banyak metode LOD yang cocok, tetapi top 5 pribadi saya adalah:

  1. Distance-Dependent Distance LOD (CDLOD)
  2. Kliping Geometri Berbasis GPU (GPUGCM)
  3. Chunked LOD
  4. Rendering Terrains dengan OpenGL GPU Tessellation (Buku: OpenGL Insight, Bab 10)
  5. Pemetaan Geometris

Masing-masing menawarkan cara unik untuk membuat medan, misalnya, CDLOD memiliki implementasi yang sangat mudah menggunakan shader (GLSL atau HLSL) tetapi juga mampu diimplementasikan pada CPU (untuk perangkat keras sebelumnya) namun tujuan Planet Rendering adalah untuk meledakkan terbaik pada GPU modern, jadi GPUGCM adalah yang terbaik saat Anda ingin memeras GPU Anda. Keduanya bekerja sangat baik dengan rendering berbasis data, prosedural atau campuran (dataran berdasarkan data tetap atau pemetaan tinggi dan detail yang ditambah dengan pekerjaan prosedural) rendering dari medan yang besar.

Juga ekstensi bola ke metode Klip Geaps geometrik dasar ada tetapi memiliki beberapa masalah karena sampel planar dari heightmap harus diparameterisasi menggunakan koordinat bola.

Chunked LOD, di sisi lain, sangat cocok untuk hardware lama, tidak memerlukan perhitungan sisi GPU untuk bekerja, itu sempurna untuk dataset besar tetapi tidak dapat menangani data prosedural secara real time (mungkin dengan beberapa modifikasi, itu bisa)

Menggunakan Tessellation shaders adalah teknik lain, sangat baru, sejak OpenGL 4.x keluar, menurut saya itu bisa menjadi yang terbaik, tetapi, kita berbicara tentang Planet Rendering, kita menghadapi masalah yang metode lain dapat tangani dengan sangat mudah dan itu adalah tentang presisi.

Kecuali jika Anda hanya menginginkan ketelitian Anda menjadi 1Km di antara vertikal, gunakan Tessellation shaders. Masalah dengan medan yang sangat besar dengan metode ini adalah bahwa jitter agak sulit untuk dipecahkan (atau setidaknya bagi saya, karena saya baru mengenal tessellation shaders).

Geomipmapping adalah teknik yang hebat, mengambil keuntungan dari quadtree dan memiliki kesalahan pixel yang diproyeksikan rendah, tetapi, untuk rendering planet Anda perlu mengatur setidaknya 16 tingkat level rincian, yang berarti Anda akan memerlukan (untuk menjahit tumpuan) beberapa patch tambahan untuk menghubungkan level yang berbeda dan menjaga level tetangga Anda, ini bisa membosankan untuk diselesaikan, terutama menggunakan 6 permukaan medan.

Ada metode lain, sangat khusus dalam dirinya sendiri: "Pemetaan Grid Proyektif untuk Medan Planetary" sangat baik untuk visualisasi, tetapi memiliki kelemahan, jika Anda ingin tahu lebih banyak, buka tautan.

Masalah:

  • Jitter : Sebagian besar GPU saat ini hanya mendukung nilai floating-point 32-bit, yang tidak memberikan cukup presisi untuk memanipulasi posisi besar di medan skala planet. Jitter terjadi ketika pemirsa memperbesar dan memutar atau bergerak, maka poligon mulai memantul ke depan dan ke belakang.

    Solusi terbaik untuk ini adalah dengan menggunakan metode "Rendering Relative to Eye Using the GPU". Metode ini dijelaskan dalam buku "Desain Mesin 3D untuk Globes Virtual" (Saya yakin Anda dapat menemukannya di internet juga) di mana pada dasarnya Anda harus mengatur semua posisi Anda dengan dua kali lipat pada CPU (patch, clipmaps, objek, frustrum, kamera, dll) dan kemudian MV berpusat di sekitar pemirsa dengan mengatur terjemahannya ke (0, 0, 0) T dan ganda dikodekan dalam representasi titik tetap menggunakan fraksi (mantissa) bit dua float, rendah dan tinggi dengan beberapa metode (baca tentang Menggunakan implementasi Ohlarik dan The DSFUN90 Fortran library).

    Meskipun vertex shader hanya membutuhkan tambahan dua pengurangan dan satu tambahan, GPU RTE menggandakan jumlah memori buffer vertex yang diperlukan untuk posisi. Ini tidak harus menggandakan persyaratan memori kecuali hanya posisi yang disimpan.

  • Depth Buffer Precision : Z-fighting. Saat kita membuat medan yang sangat besar, dalam hal ini: planet, buffer-Z harus BESAR, tetapi tidak masalah dengan nilai yang Anda tetapkan untuk znear dan zfar, akan selalu ada masalah.

    Karena Z-buffer tergantung pada interval titik float, dan juga itu adalah linear (walaupun proyeksi perspektif non linear) nilai-nilai di dekat mata menderita Z-Fighting karena kurangnya presisi float 32-bit miliki.

    Cara terbaik untuk mengatasi masalah ini adalah dengan menggunakan "Buffer Depth Logarithmic" http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

    Buffer kedalaman logaritmik meningkatkan presisi buffer kedalaman untuk objek yang jauh dengan menggunakan distribusi logaritmik untuk zscreen. Ini memperdagangkan presisi untuk objek dekat untuk presisi untuk objek yang jauh. Karena kita merender dengan metode LOD, objek jauh membutuhkan ketelitian yang lebih kecil karena mereka memiliki lebih sedikit segitiga.

Sesuatu yang penting untuk disebutkan adalah bahwa semua metode yang tercantum (kecuali untuk grid proyektif) sangat baik ketika melakukan fisika (kebanyakan tabrakan) karena basis Quadtree, itu adalah sesuatu yang wajib jika Anda berencana untuk membuat permainan.

Kesimpulannya, cukup periksa semua opsi yang tersedia dan pilih yang menurut Anda lebih nyaman, menurut saya CDLOD bekerja dengan baik. Jangan lupa untuk memecahkan masalah jitter dan Z-buffer, dan yang paling penting: bersenang-senang membuatnya!

Untuk informasi lebih lanjut tentang LOD, periksa tautan ini .

Untuk demostrasi lengkap tentang spherifying a cube periksa tautan ini .

Untuk penjelasan yang lebih baik tentang menyelesaikan masalah jittering dan Z-Buffer, periksa buku ini .

Saya harap Anda menganggap ulasan kecil ini bermanfaat.


1
Saya ingin tahu lebih banyak tentang perjalanan riset Anda. Apakah ada yang bisa saya ikuti pembaruan Anda? Blog atau apalah?
Syaiful Nizam Yahya

@publicENEMY Saat ini, saya masih mengembangkan mesin, saya berhenti karena saya mendapat pekerjaan satu tahun dan penelitian saya sedang dalam keadaan siaga, dalam satu atau dua bulan saya akan mengambil kembali penelitian dan menyelesaikan mesin. Ketika saya sampai di sana, saya akan memberi tahu Anda di sini kapan saya akan memposting semua pembaruan di perjalanan. Terima kasih atas minatnya.
nosmirck
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.