Đồ thị cảnh như đối tượng chứa?


8

Biểu đồ cảnh chứa các nút trò chơi đại diện cho các đối tượng trò chơi. Thoạt nhìn, có vẻ thực tế khi sử dụng Biểu đồ cảnh làm vật chứa cho các đối tượng trò chơi, thay vì std :: vector <> chẳng hạn.

Câu hỏi của tôi là, có thực tế không khi sử dụng Biểu đồ cảnh để chứa các đối tượng trò chơi , hay chỉ nên sử dụng nó để xác định các liên kết / đối tượng cảnh, trong khi giữ các đối tượng được lưu trữ trong thùng chứa riêng biệt, chẳng hạn như std :: vector <>?


Có ai có ý kiến ​​nào không nhỉ? Tôi dự định sử dụng cả Biểu đồ cảnh để tổ chức các Diễn viên / Nút trò chơi và sau đó Vector để thực hiện các cách sắp xếp khác nhau, nhanh hơn so với sắp xếp một cây Cảnh đa chiều.
Bunkai.Satori

@ Tất cả: Tôi có thêm một câu hỏi nữa: Cảnh có chứa toàn bộ bản đồ hay chỉ nên chứa một phần bản đồ, nói khu vực có thể nhìn thấy của nó? Obvioulsly, Biểu đồ cảnh sau đó sẽ được cập nhật liên tục, khi người chơi di chuyển trên bản đồ.
Bunkai.Satori

Câu trả lời:


5

Quyết định sử dụng loại quản lý cảnh nào phụ thuộc rất nhiều vào loại logic bạn đang cố chạy. Xem xét những người tiêu dùng khác nhau trong cảnh của bạn:

Kết xuất người tiêu dùng

Trình kết xuất có thể chỉ muốn biết những gì hiện đang hiển thị cho người dùng tại bất kỳ điểm nào. Nó muốn một hệ thống phân cấp âm lượng giới hạn để loại bỏ nhanh ( bài viết wiki của BVH) để có thể nhận ra rằng một chiếc ghế bên trong thuyền không cần phải rút ra vì giới hạn của chiếc thuyền nằm ngoài tầm nhìn. Điều này có thể được nhúng vào một octree .

Nó cũng có thể muốn có một ý tưởng rằng chiếc ghế nằm ngửa trong thuyền, và chiếc thuyền đang lăn lên xuống trên một số sóng khi cuối cùng nó xuất hiện. Bằng cách đó để tìm tọa độ thế giới cuối cùng của các đỉnh của ghế, nó có thể ghép các biến đổi của ghế và thuyền và được thực hiện với nó (điều này cũng giúp công việc của bạn trở thành một lập trình viên dễ dàng hơn).

Một cách khác để xem xét vấn đề này là trình kết xuất có thể đang chạy một thẻ tốt và cuối cùng chỉ muốn một đống hình tam giác được sắp xếp để giảm thiểu kết cấu, đổ bóng, vật liệu, ánh sáng và thay đổi trạng thái. Điều cuối cùng này có thể sẽ giúp bạn nhiều hơn một BVH, khôn ngoan.

Người tiêu dùng logic trò chơi

Logic trò chơi có lẽ chỉ muốn một danh sách phẳng những thứ có thể nói chuyện với nhau bằng một hệ thống nhắn tin, vì vậy một std :: vector có lẽ là tốt.

Trò chơi cũng có thể muốn có một cách theo dõi ai là người gần gũi nhất với cái gì, vì vậy một số thông tin [hàng xóm gần nhất] [3] có thể hữu ích trong trường hợp đó. Điều này cũng có thể được cung cấp bởi một BVH, nhưng việc phải lên và xuống biểu đồ có thể gây khó chịu.

Trò chơi thậm chí có thể chỉ muốn biết rằng khi nó di chuyển A, vật phẩm B của A cũng sẽ di chuyển ... trong trường hợp đó chúng ta quay lại một hệ thống phân cấp biến đổi.

Vật lý tiêu dùng

Vật lý trò chơi của bạn có thể muốn có [đại diện đặc biệt] [4] không gian trong nhà để phát hiện va chạm rất nhanh. Thay phiên, nó có thể sử dụng một số loại octree hoặc [băm không gian] [5] để tìm hiệu quả những thứ có thể va chạm.

Không có cấu trúc dữ liệu vật lý nào ở trên thực sự trông giống như một "biểu đồ cảnh" theo nghĩa Java3D.

Âm thanh tiêu dùng

Một công cụ âm thanh chỉ muốn hình học, có thể là một bộ có thể nhìn thấy (có thể nghe được) hoặc một loại phân cấp âm lượng giới hạn nào đó để tính toán suy giảm và phát âm. Một lần nữa, không thực sự là một loại biểu đồ cảnh bình thường, mặc dù nó cũng có thể là một biểu đồ hình học trong cảnh của bạn.

Cuối cùng ... ... nó thực sự chỉ phụ thuộc vào nhu cầu chính xác của ứng dụng của bạn. Tôi khuyên bạn nên sử dụng một danh sách phẳng để bắt đầu và xem vấn đề của bạn phát sinh ở đâu. Bạn thậm chí có thể thử một danh sách phẳng với hệ thống phân cấp biến đổi, bởi vì đó có lẽ là một loại biểu đồ hữu ích vì những lý do khác ngoài hiệu quả.

Chúc may mắn!


@ChrisE: +1 cho câu hỏi xuất sắc. Theo tôi, đây là câu trả lời tốt nhất ở đây, vì vậy hãy để tôi đánh dấu câu này là Câu trả lời được chấp nhận . Nếu tôi hiểu chính xác, bạn đã chứng minh rằng Biểu đồ cảnh không phải lúc nào cũng là giải pháp tối ưu. Đặc biệt trong Game Logic, bạn có thấy Biểu đồ cảnh là cách chính xác để cập nhật chuyển đổi (tỷ lệ, dịch) của các đối tượng liên quan không? Ví dụ, một chiếc ghế nằm trên thuyền, vậy tọa độ của chiếc ghế có được cập nhật khi thuyền di chuyển không? Ngoài ra, bạn có thấy giải pháp nào tốt hơn để cập nhật tọa độ tương đối không?
Bunkai.Satori

@ChrisE: Ngoài các trường hợp được đề cập ở trên, trong trường hợp Biểu đồ cảnh được sử dụng, bản thân nó có thể được sử dụng làm chủ sở hữu đối tượng duy nhất cho cảnh không, hoặc bạn có khuyên bạn nên có một thùng chứa khác (giả sử std :: vector <>) bên cạnh Cảnh Đồ thị?
Bunkai.Satori

2
Tôi thực sự đang trong quá trình đề xuất điều đó. Tôi sẽ thử giữ một hệ thống phân cấp chuyển đổi (ở đây, một cây n-ary nơi các nút có một cha và nhiều con và không có con nào được chia sẻ giữa các nút) với mỗi nút có chứa một tham chiếu đến đối tượng trò chơi. Các đối tượng trò chơi được giữ trong một mảng phẳng, riêng biệt (giả sử, std :: vector).
ChrisE

Trong quá trình cập nhật, bạn có thể thảo luận về danh sách phẳng và thực hiện logic trò chơi, và bất cứ khi nào chuyển động tương đối xảy ra (giả sử, chiếc ghế được đẩy về phía trước trên thuyền), bạn sử dụng hệ thống phân cấp biến đổi để tìm biến đổi cục bộ cuối cùng bằng cách đi bộ lên cha mẹ của đối tượng của bạn và nối các biến đổi của họ. Điều này sử dụng hệ thống phân cấp biến đổi cho những gì tốt nhất (đơn giản hóa chuyển động tương đối) và vẫn cho phép bạn giữ một danh sách các đối tượng thuận tiện xung quanh.
ChrisE

Một cải tiến nữa là giữ cho mỗi đối tượng một lá cờ bẩn và một sự biến đổi của mọi thứ phía trên nó trong hệ thống phân cấp biến đổi. Biến đổi cha mẹ sang thế giới được lưu trong bộ nhớ cache (biến đổi mà tôi vừa đề cập) có nghĩa là đối với bất kỳ cập nhật vị trí đối tượng nào, bạn chỉ phải thực hiện một phép nhân ma trận (biến đổi tương đối thành cha mẹ với biến đổi cha mẹ sang thế giới). Mỗi khi bạn cập nhật biến đổi tương đối, bạn cũng cập nhật cờ bẩn của mình.
ChrisE

3

Có một lý do chính đáng để không sử dụng biểu đồ cảnh làm vật chứa cho các đối tượng trò chơi và đó là sự bất ổn. Nếu bạn muốn sử dụng lại một số tài nguyên, sẽ tốt hơn nhiều nếu chỉ tham khảo tài nguyên từ biểu đồ cảnh của bạn nhiều lần hơn là có một vài bản sao thực tế.


@Jari: +1 cho câu trả lời hay. Theo tôi hiểu, cách tiếp cận chung, là có một thùng chứa các lưới có thể kết xuất riêng biệt. Biểu đồ cảnh thường đề cập đến thùng chứa lưới có thể kết xuất, để lấy thông tin hình dạng đối tượng. Bên cạnh đó, mỗi nút biểu đồ cảnh chứa thông tin chuyển đổi. Jari, có thiết kế như vậy, tôi muốn biết, nếu vẫn nên có std :: vector <> container riêng cho các nút trò chơi, hãy nói với mục đích sắp xếp nhanh hơn hoặc lý do khác ..
Bunkai.Satori

2
Phụ thuộc - có thể hữu ích khi thực sự có một số danh sách các nút tuyến tính để xử lý nhanh hơn AI, vật lý, bất cứ điều gì. Nhưng tôi sẽ đến đó sau khi tôi thấy có vấn đề gì khác không.
Jari Komppa

Vì vậy, để kết luận, nên bắt đầu chỉ có một Cảnh duy nhất, có thể chứa tất cả các đối tượng trong cảnh. Bạn có thể tư vấn xin vui lòng, nếu máy ảnh, đèn, kích hoạt cũng nên có trong biểu đồ cảnh không?
Bunkai.Satori

Mọi thứ bị ảnh hưởng bởi hệ thống phân cấp chuyển đổi phải có trong biểu đồ cảnh, nhưng tôi vẫn không cho quyền sở hữu biểu đồ cảnh mà lưu trữ chúng ở nơi khác để xử lý dễ dàng hơn (hoạt hình, vật lý, v.v.).
Jari Komppa

Hiểu Jari. Cảm ơn. Tôi sẽ bắt đầu với phiên bản nhỏ hơn và thêm các thùng chứa khác để xử lý dễ dàng hơn sau này khi cần.
Bunkai.Satori

2

Tách đối tượng của bạn và viewmodel (khung cảnh của bạn) thường là một ý tưởng tốt.

Xem này bài viết về đề tài này.

Trong số nhiều thứ, điều này sẽ cho phép sử dụng các nhóm đối tượng. Đó có thể là bản chất để quản lý bộ nhớ hiệu quả.


+1 để đóng góp tốt. Tôi đã đi qua bài viết. Nó thảo luận về các mẫu lập trình và nếu tôi hiểu chính xác, Mô hình đối tượng sẽ giữ danh sách các đối tượng trong cảnh được sắp xếp theo dạng std: vector <>, trong khi ViewModel sẽ chứa các đối tượng tương tự được sắp xếp vào Biểu đồ cảnh? Tuy nhiên, chỉ các đối tượng được hiển thị hiện tại mới được chứa trong Biểu đồ cảnh?
Bunkai.Satori

Và những gì về máy ảnh, kích hoạt, lighs? họ cũng sẽ là một phần của đồ thị cảnh chứ?
Bunkai.Satori

@ Bunkai.Satori Vâng, bạn có thể có những thứ trong khung cảnh không được hiển thị trên màn hình. Bạn xây dựng khung cảnh của mình, sau đó bạn có thể chạy một thuật toán loại bỏ trên khung cảnh trước khi hiển thị các nút có thể nhìn thấy. Máy ảnh và đèn kích hoạt có thể tồn tại cả trong mô hình và chế độ xem.
Thợ làm móng

Cám ơn phản hồi của bạn. Như bạn đã đề cập đến việc loại bỏ , nó được thực hiện như thế nào trong thực tế? toàn bộ cảnh có trong Biểu đồ cảnh hay chỉ có phần hiển thị? Nếu toàn bộ cảnh nằm trong Biểu đồ cảnh, toàn bộ biểu đồ cảnh có đi qua mỗi khung hình để chỉ gửi vùng hiển thị vào API OpenGL / DirectX không? Tôi nghi ngờ rằng toàn bộ cảnh được gửi tới API trên cơ sở từng khung, vì phần hiển thị thường nhỏ hơn 5% so với cảnh hoàn chỉnh. Ngoài ra, có phải biểu đồ cảnh được tổ chức bằng cách nào đó, để nhanh chóng truy xuất các khu vực gần nhất mà không cần di chuyển đầy đủ trên cơ sở từng khung hình không?
Bunkai.Satori

Đặt toàn bộ cảnh của bạn trong khung cảnh. Cân bằng biểu đồ dựa trên tiêu chí nhất định (ví dụ: bạn có thể tạo một cây oc-ra khỏi nó). Đi qua cây và xác định các nút nào là "Hiển thị", "Hiển thị một phần" và "Vô hình" dựa trên việc các hộp giới hạn nằm trong chế độ xem của bạn. Bạn có thể xây dựng một "biểu đồ khả năng hiển thị" siêu nhẹ, về cơ bản chỉ bao gồm các tham chiếu đến các nút SG và một cờ. Sau khi loại bỏ bực bội, bạn có thể đi ngang qua cây một lần nữa để thực hiện loại bỏ tắc. Làm lại việc loại bỏ mọi khung hình, hoặc mọi khung hình nơi máy ảnh hoặc cảnh đã được đánh dấu là "bẩn".
Thợ làm móng
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.