Giải pháp cấu trúc dữ liệu tốt cho trình quản lý cảnh trong XNA là gì?


8

Tôi đang chơi với XNA cho một dự án trò chơi của chính mình, tôi đã tiếp xúc với OpenGL trước đây và làm việc một chút với Ogre, vì vậy tôi đang cố gắng để các khái niệm tương tự hoạt động trên XNA.

Cụ thể, tôi đang cố gắng thêm vào XNA một trình quản lý cảnh để xử lý các biến đổi phân cấp, sự bực bội (thậm chí có thể là tắc) phân loại đối tượng và minh bạch.

Kế hoạch của tôi là xây dựng một trình quản lý cảnh cây để xử lý các biến đổi phân cấp và ánh sáng, sau đó sử dụng một Octree để loại bỏ sự thất vọng và phân loại đối tượng. Vấn đề là làm thế nào để sắp xếp hình học để hỗ trợ trong suốt một cách chính xác. Tôi biết rằng việc sắp xếp rất tốn kém nếu được thực hiện trên cơ sở đa giác, đắt đến mức nó thậm chí không được quản lý bởi Ogre. Nhưng hình ảnh từ Ogre nhìn đúng.

Bất kỳ ý tưởng về cách làm và cấu trúc dữ liệu để sử dụng và khả năng của họ? Tôi biết mọi người xung quanh đang sử dụng:

  • Tháng mười
  • Kd-cây (một người nào đó trên diễn đàn GameDev nói rằng những thứ này tốt hơn nhiều so với Octrees)
  • BSP (cần xử lý đơn hàng theo đa giác nhưng rất tốn kém)
  • BVH (nhưng chỉ để loại bỏ sự thất vọng và tắc nghẽn)

Cảm ơn bạn

Tunnuz

Câu trả lời:


6

Octtrees (hoặc thậm chí chỉ là bốn phần tư) và cây Kd đều là các sơ đồ phân vùng không gian cho mục đích chung tốt, và nếu đường ống xây dựng và / hoặc công cụ của bạn tạo ra chúng, thì bạn sẽ thấy chúng hữu ích theo mọi cách khác nhau để tối ưu hóa các truy vấn / lặp đi lặp lại. Chúng hoạt động bằng cách phân chia một âm lượng cố định theo cách phân cấp, điều này làm cho các truy vấn như chiếu tia vào không gian đối tượng của bạn rất rẻ để truy vấn (rất tốt cho kiểm tra va chạm).

Phân cấp khối lượng giới hạn hoạt động theo một cách hơi khác (chúng tổng hợp các khối lượng của các đối tượng trong cây thay vì các không gian phân chia phụ) và là một cách đơn giản để cắt xén những thứ không cần thiết khỏi bị lặp đi lặp lại. Nhưng vì BVH không đặt ra bất kỳ hạn chế nào về cách hai nút anh chị em có liên quan với nhau, nên đó không phải là một kế hoạch tốt để tìm ra thứ tự kết xuất hoặc cho các truy vấn va chạm tùy ý.

Các hệ thống BSP rất tốt khi bạn phân chia thế giới dựa trên các đa giác riêng lẻ, nhưng đối với các đối tượng lớn hơn, cách tiếp cận dựa trên khối lượng có ý nghĩa hơn.

Trên hết, điều đáng chú ý là không có hệ thống nào trong số này là hoàn hảo để xác định thứ tự kết xuất để minh bạch, ngay cả phương pháp BSP. Nó sẽ luôn có thể xây dựng hình học phá vỡ thuật toán của bạn, trừ khi bạn có thể chia nhỏ các đa giác một cách nhanh chóng. Những gì bạn có thể tìm kiếm nhiều nhất là một giải pháp 'nỗ lực tốt nhất', trong đó hình học có thể được sắp xếp chính xác trong phần lớn các trường hợp; và nhóm nghệ thuật có thể chia nhỏ các mô hình cho bất kỳ trường hợp nào không hoạt động (vì mô hình / đa giác có kích thước lớn bất thường, dài hoặc tự giao nhau). Các mô hình / nút nhỏ hơn luôn dễ dàng hơn để sắp xếp 'chính xác', nhưng bạn phải trả tiền cho nó theo chi phí lặp lại.

Kd-cây và Oct / quad-cây đều là những giải pháp cho mục đích chung tốt, có thể viết ra một triển khai thân thiện với nền tảng, nhưng cuối cùng bạn sẽ phải cân bằng độ sâu / độ phức tạp của cây phân vùng không gian của bạn với chi phí lặp lại nó và chi phí cho mỗi mô hình (nghĩa là rút ra chi phí cuộc gọi). Nếu bạn đang nhắm mục tiêu XNA, tôi khuyên bạn nên giữ nó ở mức độ đơn giản và cao và nếu có vấn đề sắp xếp với một số nội dung, thì hãy cân nhắc mạnh mẽ thay đổi nội dung trước khi cố gắng cải thiện công cụ của bạn cho đến khi nó có thể đối phó với nó; lợi nhuận giảm rất nhanh sau khi sắp xếp kết xuất cơ bản nhất được thực hiện.


Tôi đã đọc được rằng ngay cả các kỹ thuật Lột sâu để xử lý phân loại theo từng mảnh thường thu được kết quả tốt. Bạn có nghĩ rằng điều này là khả thi trên một công cụ trò chơi nhỏ? Các trò chơi AAA có sử dụng các kỹ thuật này không?
tunnuz

Bạn nghĩ điều gì tốt hơn / dễ thực hiện hơn giữa Kd-tree và Octrees?
tunnuz

Tôi sẽ rất ngạc nhiên nếu không có triển khai C # cho cả hai bên ngoài đó: đó là điều mà phần thịt của nó (phân mục và truy vấn) giống nhau cho tất cả các triển khai, nhưng các bit thú vị (làm thế nào để bạn lặp lại / truy vấn / liên kết các mục với các nút) có thể khác nhau. Theo tôi, tháng 10 / cây tứ giác đơn giản hơn về mặt khái niệm, nhưng như đã được chỉ ra, cây kd hiệu quả hơn theo nhiều cách khác nhau. Có lẽ tôi sẽ đi kd-tree chỉ vì nếu bạn có thể làm điều đó, bạn có thể thực hiện oct-tree (nhưng điều ngược lại không nhất thiết là đúng).
MrCranky

1
Đối với phân loại theo từng mảnh: không biết gì về động cơ của bạn, thật khó để nói, nhưng nó cảm thấy giống như một chút tối ưu hóa sớm. Đúng, các trò chơi AAA có thể sử dụng các kỹ thuật đó, nhưng chúng cũng sẽ xáo trộn nhiều đối tượng hơn là một công cụ XNA sẽ có thể quản lý và do đó yêu cầu nhiều kỹ thuật tối ưu hóa cực đoan hơn để tận dụng tối đa. Lời khuyên của tôi sẽ luôn là làm cho các vấn đề cơ bản (phân loại trong suốt) được thực hiện một cách vững chắc, và nếu bạn thấy hiệu suất đó không bị trầy xước, thì hãy chuyển toàn bộ con lợn và phân loại hạt mịn hơn. Cơ hội là một cái gì đó khác sẽ ràng buộc hiệu suất đầu tiên.
MrCranky

1
Có những nhà phát triển AAA thực sự đã bỏ qua việc sử dụng cây của BV kể từ khi thực hiện nó một cách mạnh mẽ trong khi đảm bảo rằng bạn thực sự sử dụng hầu hết các đồng hồ hiệu quả (Không có LHS / L2 + L1 Cache nào v.v.) cung cấp hiệu suất đủ tốt. Thật đáng ngạc nhiên khi có bao nhiêu bài kiểm tra bạn có thể đưa ra với một hệ thống được thiết kế tốt.
Simon

3

McCranky bao phủ một cách đáng kinh ngạc tất cả các cấu trúc dữ liệu bạn đã đề cập, tuy nhiên tôi thấy rằng bạn chưa coi R-Plants. Cơ thể kiến ​​thức về các cấu trúc đó là rất lớn và chúng rất phù hợp cho các truy vấn phạm vi không gian (hầu hết các công việc đã được thực hiện bởi các nhà lý thuyết cơ sở dữ liệu và các nhà thực hành) trong 30 năm qua. Gần đây, Sebastian Sylvain từ Rare đã đưa ra một khóa học về GDC về lý do tại sao họ cũng làm việc cho các trò chơi (đặc biệt là trên các bảng điều khiển với bộ xử lý theo thứ tự). Bạn có thể tìm hiểu thêm từ pdf của nó: http://www.gdcvault.com/play/1012452/R-Trees-Adapting-out-of

Việc thực hiện đơn giản và ngây thơ là khá dễ dàng và cấu trúc cơ bản mang đến cho bạn nhiều cơ hội để cải thiện (quản lý tốt hơn các phương pháp phân tách, tìm kiếm trước, tìm kiếm song song, v.v.).


2

Câu trả lời phụ thuộc rất nhiều vào số lượng mô hình mà bạn dự định sử dụng. Tôi chưa thực sự làm việc với những thứ này cho XNA, nhưng nếu bạn sử dụng AABB cho các bài kiểm tra và không có quá nhiều mô hình, bạn có thể đủ tốt với bài kiểm tra sức mạnh vũ phu. Có lẽ thậm chí ném nó ra trên một chủ đề. Tôi không chắc chắn làm thế nào / nếu có bất kỳ tối ưu hóa SSE / VMX nào có thể được sử dụng cho C # nhưng nếu bạn quản lý để có được tuyến tính của AABB trong bộ nhớ (để bạn không bị lỗi bộ nhớ cache cho CPU), bạn sẽ có thể để vượt qua một số lượng lớn các bài kiểm tra trong thời gian khá ngắn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.