Quản lý dữ liệu Voxel

Tôi đã lập trình trong C ++ như một sở thích trong khoảng 4 tháng nay và tôi thực sự yêu thích việc tạo ra các công cụ bằng cách sử dụng voxels. Tôi đã viết một "trò chơi" (Không chỉ là một thử thách cá nhân, vì tôi thực sự chỉ làm địa hình, không chơi trò chơi) tạo ra một thế giới giống như Minecraft, nhưng gần đây tôi đã nghĩ đến việc cố gắng viết một trò chơi / thử thách / v.v. sử dụng thuật toán như Marching Cubes hoặc Dual Contouring và giảm kích thước voxel. Khi tôi viết dự án giống Minecraft của mình, tôi đã lưu trữ dữ liệu của từng khối trong một loạt các quần short không dấu (do đó cung cấp cho tôi tới 65536 loại khối khác nhau). Ngoài ra, để kết xuất, tôi chỉ lưu trữ một điểm (dưới dạng GLubyte) và một GLubyte khác để chỉ ra điểm nào trong số 6 mặt mà điểm được biểu thị. Sau đó, tôi kết xuất khuôn mặt bằng cách sử dụng một shader hình học.

Với dự án mới mà tôi đã nghĩ đến, điều tôi không thể nghĩ tới là làm thế nào tôi có thể lưu trữ đủ dữ liệu voxel để có voxels khoảng ~ 5cm hoặc 10cm so với các voxels cỡ 1m mà tôi có. Khi tôi kết xuất một khối 704x704x704, dự án cũ của tôi đã sử dụng khoảng 670 MB RAM. Nếu tôi thu nhỏ kích thước voxel xuống còn 10cm và giữ cùng khoảng cách kết xuất, đó sẽ là khoảng 649GB dữ liệu Voxel (giả sử 2 byte cho mỗi voxel và diện tích 7040 ^ 3 voxels). Có cách nào để tôi có thể lưu trữ dữ liệu voxel một cách hiệu quả hơn mà vẫn cho phép tôi một loạt các loại voxel khác nhau không?

Bạn có cần phải có từng khối (giả sử bạn đang sử dụng khối) trong bộ nhớ cùng một lúc không? Một số sẽ bị chặn lại - đặc biệt là dưới lòng đất - hoặc phía sau những ngọn núi, v.v ... Rất nhiều thứ có thể sẽ chỉ là không khí / trống rỗng và do đó có thể được đánh dấu bằng một lá cờ.

Ngoài ra, bạn có thể sử dụng một octree LOD hoặc cấu trúc tương tự để thử giữ chi tiết hiện có thể nhìn thấy liên quan nghịch với khoảng cách từ người quan sát. Như Jason đã nói, điều này có nhiều khả năng mua hiệu suất của bạn, nhưng đó là một sự thay đổi lớn về cấu trúc từ bản đồ khối phẳng.

Xem bài viết này về clipmap từ blog yêu thích của tôi (anh ấy có một công cụ voxel tương tự như những gì bạn mô tả với kích thước voxel là ~ một decimetre).

Cách tiếp cận tiêu chuẩn cho các công cụ như VoxLap của Ken Silverman và là người kế nhiệm Ace of Spades, là sử dụng nén RLE và một số thủ thuật cấp bit khác để lưu trữ và truy cập dữ liệu. Kiểu nén 1D này có xu hướng hiệu quả cao và dễ sử dụng hơn đáng kể so với octrees. Tôi tin rằng động cơ của Silverman đã đạt được độ phân giải voxel của một cái gì đó giống như hình khối 10cm. Một cái gì đó bạn không thường thấy ngày nay, và đã đạt được trên phần cứng yếu hơn nhiều.

Tôi tin rằng cũng đúng là cách tiếp cận của anh ta không lưu trữ màu sắc cho các voxels không phơi sáng, mà thay vào đó, nó tính màu cho các voxels bề mặt như một chức năng của chiều cao, hoặc bằng cách nhớ những khu vực nào của địa hình đã bị nổ tung và tô màu chúng là "đất tươi" ". Bạn có thể sử dụng một số loại chức năng liên tục như nhiễu perlin để làm điều này, nhưng nó có thể nhanh chóng gây tốn kém cho các khu vực bề mặt lớn (trừ khi, có lẽ, được thực hiện trên GPU).

Octrees không phải là xấu, nhưng chúng rất khó sử dụng trong thực tế và phân bổ hiệu quả bộ đệm là thách thức hơn đáng kể so với RLE, dễ dàng tuyến tính hóa theo từng đoạn. Bài báo chuyên đề về các SVO của Tero Karras và Samuli Laine chỉ ra rằng có bao nhiêu nỗ lực để thực hiện octree thực sự hiệu quả - và đó chỉ xem xét kết xuất, không phải trò chơi hoặc truyền thông mạng.

Tôi không biết bạn đã đi được bao xa trong dự án của mình nhưng tôi và một người bạn của tôi đang sử dụng thuật toán Dual Marching Cubes , dựa trên cấu trúc chunck của Octree và sử dụng lưới kép để hiển thị dữ liệu. Nó có nhiều ưu điểm, như yêu cầu bộ nhớ thực sự thấp và hiển thị thực sự nhanh. Có thể hơi khó để triển khai Cấp chi tiết (LOD) trong các đường viền chunk với các khối khác, nhưng nếu bạn có thời gian rảnh, bạn có thể tìm hiểu cách các nhà phát triển của Ogre3D đã làm .