Tại sao cây oct phổ biến hơn nhiều so với bảng băm?

Khi đọc các bài báo, tôi thường tìm thấy các triển khai hình học của cây Oct để sắp xếp dữ liệu. Tuy nhiên, bất cứ khi nào tôi nghĩ về các bảng băm vấn đề có vẻ tốt hơn về tổng thể.

Các bảng băm có kịch bản trường hợp trung bình tốt hơn và xấu hơn cho hầu hết các ứng dụng:

Ví dụ, đối với tia truy tìm cây oct, các lỗi gần sẽ khiến bạn lặp qua cấu trúc cây nhị phân, đó là O (nlogn) trong khi bảng băm là O (n).

Các bảng băm dễ dàng tạo ra trong GPU hơn, vì chúng không yêu cầu bất kỳ vị trí logic nào trong bộ nhớ ngoài vị trí băm của chúng.

Hầu hết các cấu trúc cây có lợi thế đều có các bảng băm dường như không giữ GPU.

Trong đồ họa, chúng tôi không thích phân bổ lại bộ nhớ nên chúng tôi thường phân bổ bộ nhớ trong VRAM chỉ để có thể sử dụng lại cấu trúc dữ liệu. Vì vậy, cây nhị phân thuộc tính có (có hiệu quả bộ nhớ) dường như không phù hợp với các ứng dụng GPU.

Sự kết hợp dữ liệu cho bộ nhớ đệm dường như cũng không giữ được. Đối với cây được tạo ra bởi GPU, tính không đồng bộ làm cho rất khó để đảm bảo rằng các giá trị đóng logic cũng được lưu trữ gần nhau trong bộ nhớ bên dưới. Vì vậy, cuối cùng bạn sẽ nhảy xung quanh con trỏ.

Nó cũng dễ dàng hơn nhiều để thực thi các heuristic thân thiện với GPU nhất định trong bảng băm so với trong cây. Ví dụ: giới hạn số lần tra cứu băm ở một số cố định, giả sử 20 và sử dụng cùng một logic để ngăn các sợi dọc thực thi mã nhánh khác nhau. về bản chất, bạn luôn có thể kiểm tra 20 va chạm tiềm năng và chỉ nội suy kết quả với ô chứa khóa. Trong một cây, việc truyền tải qua cấu trúc dữ liệu phụ thuộc nhiều hơn vào chính dữ liệu và ít hơn vào cấu trúc dữ liệu.

Vậy tại sao cây oct được sử dụng nhiều hơn bảng băm?

2 xu của tôi từ việc viết công cụ vật lý Chipmunk2D là việc băm không gian rất tuyệt vời khi bạn có rất nhiều đối tượng có cùng kích thước. Tôi đã có bản demo 10 năm trước chạy với 20k hạt tương tác trên Core 2 Duo trong thời gian thực. Hàm băm không gian làm việc tuyệt vời cho điều đó nếu bạn điều chỉnh nó .

Kể từ đó, tôi đã thay thế hàm băm không gian bằng cây AABB nhị phân làm cấu trúc mặc định. Nó không hoàn hảo, nhưng nó nhanh hơn hàm băm không gian trong trường hợp trung bình không có điều chỉnh . Việc thêm một thành phần tạm thời vào nó cũng dễ dàng hơn để tôi có thể cập nhật dần dần một tập hợp các xung đột tiềm năng. Với tất cả những điều đó, thử nghiệm duy nhất tôi có chạy nhanh hơn với hàm băm không gian là những thử nghiệm có hàng ngàn hạt và không có hình học tĩnh.

Đối với quãng tám ... Meh, tôi không bao giờ sử dụng chúng. Quad / octrees cơ bản không thực sự phù hợp với dữ liệu thực cũng như rất nhiều các BVH khác mà bạn có thể sử dụng. Cây Basic AABB gần như đơn giản, và cách hiệu quả hơn.

Rất nhiều thứ ở đây.

• "Khi đọc báo". Giấy tờ gì? Nếu chủ đề của bài viết là về một cái gì đó ngoài cấu trúc phân vùng không gian, có thể công bằng khi sử dụng bất cứ điều gì biết rằng các ý tưởng cơ bản sẽ chuyển sang các cấu trúc khác. Hoặc không, khó nói.

• "Ví dụ: đối với tia truy tìm cây oct, các lỗi gần sẽ khiến bạn lặp lại qua cấu trúc cây nhị phân, đó là O (nlogn) trong khi bảng băm là O (n)". Ký hiệu Big O có nghĩa là không có gì trong bối cảnh này. Bạn đang làm việc với một công nghệ cụ thể ở một quy mô cụ thể khi bạn nói về những thứ phụ thuộc vào chi tiết thực hiện. Thuật toán O (nlogn) có thể chậm hơn nhiều so với thuật toán O (n) cho "n" là hiện thực ngày nay, nó xảy ra mọi lúc. Và trong khi bạn có thể nói, trong 10 năm có thể thay đổi, chắc chắn, đó có thể là trường hợp, nhưng trong 10 năm đó, GPU của bạn có thể trông hoàn toàn khác nhau và do đó, các thuật toán nghệ thuật cần phải thay đổi bất kể. Điều đó là phổ biến, nếu bạn nhìn vào các thuật toán GPU (và cụ thể là GPU vẫn đang phát triển khá nhiều)

• Số tám là gì? Bảng băm nào? Có rất nhiều sự lựa chọn ở đó. Ví dụ: "... vì họ không yêu cầu bất kỳ vị trí logic nào trong bộ nhớ ngoài vị trí băm của họ". Điều đó chỉ đúng nếu bạn không có va chạm băm, đúng không? Nếu bạn có xung đột thì bất kỳ chiến lược nào bạn sử dụng (danh sách thăm dò hoặc liên kết) bạn sẽ cần phải đồng bộ hóa giữa các luồng, do đó, quá trình xây dựng không dễ thực hiện trên GPU. Ngược lại, đối với quãng tám nếu bạn muốn "tổng thể" như bạn đề xuất thì bạn có thể phân bổ một cây đầy đủ và việc lập chỉ mục sau đó sẽ chỉ phụ thuộc vào vị trí. Trong thực tế, nếu bạn làm một số phép toán, bạn có thể thấy rằng trong những trường hợp như vậy, octrees trở thành một cách để làm mờ lưới (ví dụ: so sánh bố cục của van Ende Boas với lưới theo thứ tự Morton ... bài tập hay).

Có rất nhiều điều khác tôi có thể nói, nhưng hãy để tôi cắt theo đuổi ở đây.

• Đối với raytracing cụ thể, cả bảng Octrees và Hash đều không phổ biến. Các BVH của AABB là con đường để đi.

• Lợi ích chính của Octrees so với lưới băm là độ phân giải ô của bạn thích ứng với hình học. Các lưới sẽ không, bạn phải chọn kích thước ô và có thể quá nhỏ ở một số phần của cảnh và quá lớn ở một số phần khác.

• Có rất nhiều biến thể và rất nhiều chi tiết thực hiện. Các quãng tám ngây thơ có lẽ không bao giờ nên được sử dụng trong thực tế vì chúng quá sâu / không đủ rộng. Nếu bạn tạo một octree "lớn hơn" bằng cách nói, một lưới 4 x 4 với các lưới 4 x 4 được lồng trong mỗi ô không trống, bạn tạo ra cái gọi là lưới phân cấp. Vì vậy, lưới và octrees tồn tại trên một quang phổ, trong đó octrees là "sâu" nhất, lưới là "nông" nhất (chỉ một cấp, một lưới duy nhất trên toàn cầu trong cảnh) và lưới phân cấp có thể giao dịch giữa hai

• Điều này có thể giúp! http://www.realtimerendering.com/Real-Time_Rendering_4th-Real-Time_Ray_Tracing.pdf ;)