Cuối cùng, sau rất nhiều nghiên cứu tôi có thể kết luận rằng, như một số người đã nói trước đây, không có phương pháp "tốt nhất" nào. Nhưng nghiên cứu của tôi đã dẫn tôi đến kiến thức về những điều sau đây:
Tùy thuộc vào lưới cuối cùng bạn sẽ sử dụng:
- Spherified Cube: bất kỳ phương pháp LOD nào với triển khai tứ giác đều hoạt động tốt, bạn chỉ cần quan tâm đến các trường hợp đặc biệt như đường viền giữa các mặt, trong trường hợp, tứ giác của bạn phải có một con trỏ tới hàng xóm ở mặt tiếp giáp ở mỗi cấp.
- Bất kỳ cách nào khác: Tôi nghĩ rằng ROAM (phiên bản mới hơn 2.0 hoặc bất kỳ tiện ích mở rộng nào khác như BDAM, CABTT hoặc RUSTIC) sẽ hoạt động tốt, tuy nhiên, các thuật toán này khó hoạt động, yêu cầu nhiều bộ nhớ hơn và chậm hơn một chút so với các lỗi khác với các hình khối.
Có nhiều phương pháp LOD có thể phù hợp, nhưng top 5 cá nhân của tôi là:
- LOD phụ thuộc khoảng cách liên tục (CDLOD)
- Clipmomet Geomety dựa trên GPU (GPUGCM)
- Chunked LOD
- Kết xuất các địa ngục với Tessname GPU OpenGL (Sách: OpenGL Insight, Chương 10)
- MipMapping hình học
Mỗi phương thức cung cấp một cách duy nhất để hiển thị địa hình, ví dụ, CDLOD có cách triển khai rất dễ dàng bằng cách sử dụng trình đổ bóng (GLSL hoặc HLSL) nhưng cũng có khả năng thực hiện trên CPU (đối với phần cứng cũ), tuy nhiên mục tiêu trên Planet Rendering là phát nổ tốt nhất trên GPU hiện đại, vì vậy GPUGCM là tốt nhất khi bạn muốn siết chặt GPU của mình. Cả hai đều hoạt động rất tốt với dữ liệu dựa trên dữ liệu, thủ tục hoặc hỗn hợp (địa hình dựa trên dữ liệu cố định hoặc chiều cao và chi tiết được thêm vào với công việc theo thủ tục) hiển thị các địa hình lớn.
Ngoài ra, phần mở rộng hình cầu cho phương pháp Clipmaps hình học cơ bản tồn tại nhưng có một số vấn đề vì các mẫu phẳng của sơ đồ chiều cao phải được tham số hóa bằng cách sử dụng tọa độ hình cầu.
Chunked LOD, mặt khác, hoàn hảo cho phần cứng cũ, không cần bất kỳ tính toán bên GPU nào để hoạt động, nó hoàn hảo cho các bộ dữ liệu lớn nhưng không thể xử lý dữ liệu thủ tục trong thời gian thực (có thể với một số sửa đổi, có thể)
Sử dụng trình tạo bóng Tessname là một kỹ thuật khác, rất mới, kể từ khi OpenGL 4.x xuất hiện, theo tôi nó có thể là tốt nhất, nhưng, chúng ta đang nói về Planet Rendering, chúng ta gặp phải một vấn đề mà các phương pháp khác có thể xử lý rất dễ dàng và đó là về độ chính xác.
Trừ khi bạn chỉ muốn độ chính xác của bạn là 1Km giữa các đỉnh, hãy tìm các shader Tessname. Vấn đề với các địa hình thực sự lớn với phương pháp này là jitter là loại khó giải quyết (hoặc ít nhất là đối với tôi, vì tôi chưa quen với các shader tessname).
Geomipmapping là một kỹ thuật tuyệt vời, tận dụng lợi thế của tứ giác và có lỗi pixel được chiếu thấp, nhưng, để hiển thị hành tinh, bạn sẽ cần đặt ít nhất 16+ cấp chi tiết, điều đó có nghĩa là bạn sẽ cần (để ghép các lần đổ) để kết nối các cấp độ khác nhau và chăm sóc cấp độ của hàng xóm của bạn, điều này có thể rất khó giải quyết, đặc biệt là sử dụng 6 mặt địa hình.
Có một phương pháp khác, rất đặc biệt theo cách riêng của nó: "Ánh xạ lưới chiếu cho địa hình hành tinh" tuyệt vời để trực quan hóa, nhưng có nhược điểm của nó, nếu bạn muốn biết thêm, hãy truy cập liên kết.
Các vấn đề:
Jitter : Hầu hết các GPU ngày nay chỉ hỗ trợ các giá trị dấu phẩy động 32 bit, không cung cấp đủ độ chính xác để thao tác các vị trí lớn trong địa hình quy mô hành tinh. Jitter xảy ra khi người xem phóng to và xoay hoặc di chuyển, sau đó các đa giác bắt đầu nảy qua lại.
Giải pháp tốt nhất cho việc này là sử dụng phương pháp "Kết xuất tương đối với mắt bằng cách sử dụng GPU". Phương pháp này được mô tả trong cuốn sách "Thiết kế động cơ 3D cho các quả cầu ảo" (Tôi chắc chắn bạn có thể tìm thấy nó trên internet) trong đó về cơ bản bạn phải đặt tất cả các vị trí của mình với nhân đôi trên CPU (bản vá, clipmap, đối tượng, Bực bội, máy ảnh, v.v.) và sau đó MV được tập trung xung quanh người xem bằng cách đặt bản dịch của nó thành (0, 0, 0) T và các nhân đôi được mã hóa trong một biểu diễn điểm cố định bằng cách sử dụng các bit phân đoạn (mantissa) của hai phao, thấp và cao bằng một số phương pháp (đọc về Sử dụng triển khai của Ohlarik và thư viện DSFUN90 Fortran).
Mặc dù trình tạo bóng đỉnh chỉ yêu cầu thêm hai phép trừ và một phép cộng, GPU RTE nhân đôi số lượng bộ nhớ đệm đỉnh cần thiết cho các vị trí. Điều này không nhất thiết phải tăng gấp đôi yêu cầu bộ nhớ trừ khi chỉ lưu trữ các vị trí.
Độ sâu đệm chính xác : Chiến đấu Z. Vì chúng ta đang hiển thị các địa hình rất lớn, trong trường hợp này: các hành tinh, bộ đệm Z phải rất LỚN, nhưng không có vấn đề gì với các giá trị bạn đặt cho zgần và zfar, sẽ luôn có vấn đề.
Vì bộ đệm Z phụ thuộc vào khoảng thời gian dấu phẩy và cũng là giá trị tuyến tính (mặc dù hình chiếu phối cảnh là không tuyến tính) gần mắt phải chịu cảnh Z vì thiếu phao 32 bit chính xác.
Cách tốt nhất để giải quyết vấn đề này là sử dụng "Bộ đệm sâu logarit"
http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html
Một bộ đệm độ sâu logarit cải thiện độ chính xác của bộ đệm độ sâu cho các đối tượng ở xa bằng cách sử dụng phân phối logarit cho zscreen. Nó giao dịch chính xác cho các đối tượng gần với độ chính xác cho các đối tượng ở xa. Vì chúng ta đang kết xuất với phương thức LOD, các đối tượng ở xa đòi hỏi độ chính xác thấp hơn vì chúng có ít hình tam giác hơn.
Một điều quan trọng cần đề cập là tất cả các phương pháp được liệt kê (ngoại trừ lưới chiếu) đều rất tốt khi thực hiện vật lý (chủ yếu là va chạm) vì cơ sở Quadtree, đó là điều bắt buộc nếu bạn dự định làm một trò chơi.
Tóm lại, chỉ cần kiểm tra tất cả các tùy chọn có sẵn và chọn một tùy chọn mà bạn cảm thấy dễ hiểu hơn, theo ý kiến của tôi, CDLOD thực hiện rất tốt. Đừng quên giải quyết các vấn đề jitter và Z-buffer, và quan trọng nhất: hãy vui vẻ thực hiện nó!
Để biết thêm thông tin về LOD kiểm tra liên kết này .
Để có một sự phân rã hoàn toàn về việc tạo khối lập phương, hãy kiểm tra liên kết này .
Để được giải thích rõ hơn về việc giải quyết các vấn đề jitter và Z-Buffer, hãy xem cuốn sách này .
Tôi hy vọng bạn thấy nhận xét nhỏ này hữu ích.