Tôi có nên chia sẻ dữ liệu giữa đồ họa và công cụ vật lý trong trò chơi không?


9

Tôi đang viết công cụ trò chơi bao gồm một vài mô-đun. Hai trong số đó là công cụ đồ họacông cụ vật lý .

Tôi tự hỏi nếu nó là một giải pháp tốt để chia sẻ dữ liệu giữa họ?

Hai cách (chia sẻ hay không) trông như thế:

Không chia sẻ dữ liệu

GraphicsModel{
    //some common for graphics and physics data like position

    //some only graphic data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel{
    //some common for graphics and physics data like position

    //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

engine3D->createModel3D(...);
physicsEngine->createModel3D(...);

//connect graphics and physics data 
//e.g. update graphics model's position when physics model's position will change

Tôi thấy hai vấn đề chính:

  1. Rất nhiều dữ liệu dư thừa (như hai vị trí cho cả dữ liệu vật lý và đồ họa)
  2. Sự cố với việc cập nhật dữ liệu (Tôi phải cập nhật thủ công dữ liệu đồ họa khi dữ liệu vật lý thay đổi)

Với việc chia sẻ dữ liệu

Model{
     //some common for graphics and physics data like position
};

GraphicModel : public Model{
    //some only graphics data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel : public Model{
     //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

model = engine3D->createModel3D(...);
physicsEngine->assingModel3D(&model); //will cast to 
//PhysicsModel for it's purposes??

//when physics changes anything (like position) in model 
//(which it treats like PhysicsModel), the position for graphics data 
//will change as well (because it's the same model)

Vấn đề ở đây:

  1. vật lýEngine không thể tạo các đối tượng mới, chỉ "khẳng định" các đối tượng hiện có từ engine3D (bằng cách nào đó nó có vẻ chống độc lập hơn đối với tôi)
  2. Truyền dữ liệu trong hàm assingModel3D
  3. vật lýEngine và đồ họaEngine phải cẩn thận - họ không thể xóa dữ liệu khi họ không cần chúng (vì cái thứ hai có thể cần nó). Nhưng đó là tình huống hiếm gặp. Hơn nữa, họ chỉ có thể xóa con trỏ, không phải đối tượng. Hoặc chúng ta có thể giả định rằng GraphicsEngine sẽ xóa các đối tượng, vật lýEngine chỉ trỏ đến chúng.

Cách nào tốt hơn?

Cái nào sẽ tạo ra nhiều vấn đề hơn trong tương lai?

Tôi thích giải pháp thứ hai hơn, nhưng tôi tự hỏi tại sao hầu hết các công cụ đồ họa và vật lý lại thích giải pháp thứ nhất (có thể vì chúng thường chỉ tạo ra đồ họa hoặc chỉ có công cụ vật lý và ai đó kết nối chúng trong trò chơi?).

Họ có thêm ưu & ẩn nào không?


Chính xác câu hỏi của tôi, quá.
danijar

Câu trả lời:


9

Ngày nay, nhiều công cụ trò chơi áp dụng thiết kế thành phần (ví dụ: Unity, Unreal). Trong loại thiết kế này, a GameObjectbao gồm một danh sách các thành phần. Trong tình huống của bạn, có thể có một MeshComponentPhysicalComponentcả hai, gắn vào một đối tượng trò chơi duy nhất.

Để đơn giản, bạn có thể đặt một biến đổi thế giới thành GameObject. Trong quá trình cập nhật cụm từ, PhysicalComponentđầu ra biến đổi thế giới thành biến đó. Trong quá trình kết xuất, MeshComponentđọc biến đó.

Lý do đằng sau thiết kế này là tách rời giữa các thành phần. Không biết MeshComponentcũng không PhysicalComponentbiết nhau. Họ chỉ phụ thuộc vào một giao diện chung. Và nó có thể dễ dàng mở rộng hệ thống theo thành phần hơn là sử dụng hệ thống phân cấp kế thừa duy nhất.

Tuy nhiên, trong một kịch bản thực tế, bạn có thể cần xử lý tinh vi hơn giữa đồng bộ hóa vật lý / đồ họa. Ví dụ, mô phỏng vật lý có thể cần phải được chạy trong bước thời gian cố định (ví dụ 30Hz), trong khi kết xuất cần phải thay đổi. Và bạn có thể cần phải nội suy kết quả từ đầu ra của động cơ vật lý. Một số công cụ vật lý (ví dụ Bullet) có hỗ trợ trực tiếp về vấn đề này.

Unity cung cấp một tài liệu tham khảo tốt về các Thành phần của họ , đáng để xem xét.


Điều này hoàn toàn không trả lời câu hỏi, có 2 thành phần không nói gì về việc họ có chia sẻ dữ liệu lưới hay không.
Maik

2
Trên thực tế, nó cung cấp thiết kế tốt hơn, đó là hoàn toàn hợp pháp.
jcora

7

Động cơ thường chọn tùy chọn đầu tiên (lưới vật lý riêng và lưới kết xuất riêng) vì chúng cần dữ liệu rất khác nhau, cả về chất lượng và số lượng.

Chất lượng vì công cụ vật lý không quan tâm đến tọa độ kết cấu, các nhóm bình thường và tất cả các công cụ kết xuất lạ mắt này chẳng hạn. Mỗi người trong số họ mong đợi dữ liệu trong một bố cục rất cụ thể đến các vấn đề căn chỉnh, đóng gói, xen kẽ dữ liệu, v.v.

Số lượng vì lưới vật lý thường có ít hình tam giác hơn, đây là phiên bản đơn giản của lưới kết xuất độ phân giải cao.

Bằng cách tách cả hai, chúng tôi đảm bảo rằng chúng tôi có thể thay đổi một, bao gồm thay đổi bố cục dữ liệu của nó để có hiệu suất tốt hơn, mà không làm hỏng cái khác. Đó là cách mở rộng hơn.


0

Bên cạnh câu trả lời tuyệt vời @Millo Yip tôi chỉ muốn nhắc bạn rằng bạn sẽ cần chia sẻ cùng một dữ liệu với mô-đun Điều khiển và mô-đun AI và nếu tôi không nhầm, hầu hết các thư viện âm thanh đều có khái niệm về vị trí của trình phát âm thanh vì vậy bạn cũng sẽ cần chia sẻ dữ liệu với mô-đun đó.


0

Như những người khác đã nói, một điều khá phổ biến là vật lý có trạng thái dữ liệu bên trong được quản lý tách biệt với trạng thái dữ liệu bên trong của công cụ kết xuất. Người ta thường thấy ngay cả dữ liệu biến đổi (vị trí / định hướng / tỷ lệ) được lưu trữ tách biệt với cả vật lý và kết xuất bởi vì có thể một đối tượng trò chơi tồn tại không bị áp đặt bởi vật lý cũng không được hiển thị nhưng yêu cầu vị trí thế giới cho các cơ chế khác.

Làm thế nào dữ liệu nhận được từ vật lý để kết xuất hoàn toàn phụ thuộc vào bạn.

Bạn có thể làm điều này thông qua một số quy trình gửi hệ thống con bằng cách sử dụng các sự kiện / tin nhắn. Bạn có thể làm điều này bằng cách hiển thị giao diện chung của hệ thống con kết xuất với hệ thống con vật lý để vật lý có thể chỉ cần đặt vị trí đặc biệt có thể kết xuất. Một tùy chọn khác là hệ thống con có thể kết xuất truy vấn thực thể cho biến đổi trong quá trình cập nhật và thực hiện cập nhật vị trí của thành phần có thể kết xuất sau đó tiếp theo là vẽ.

Đương nhiên, tùy thuộc vào trò chơi của bạn, một vài trong số các phương tiện này sẽ thân thiện với bộ đệm hơn và có hiệu suất tốt hơn các trò chơi khác. Tôi sẽ không bị cuốn vào quá nhiều về một cách cụ thể tại thời điểm này và chọn một mô hình giao tiếp và thử nó. Bạn có thể dễ dàng làm lại phần này sau để kiểm tra các phương tiện khác nhau để tối ưu hóa.

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.