OpenGL vs vật lý?


8

Tôi rất mới với lập trình trò chơi và tôi đang trong dự án đầu tiên của mình. Tôi đã đi đến một điểm mà tôi cần lời khuyên của chuyên gia:

Bây giờ để vật lý trò chơi có thể hoạt động trên các đối tượng, nó cần biết vị trí của từng đối tượng và hướng của nó trong không gian 3D. Là một phần của mô phỏng và do các đối tượng di chuyển (thay đổi vị trí) và thay đổi hướng (xoay).

Điều này có nghĩa là tính toán xoay và dịch được thực hiện hai lần? Một trong vật lý và cái còn lại được thực hiện bằng cách sử dụng glTranslate và glRotate trước khi vẽ đối tượng?

IMO điều này không nên xảy ra. Ngoài ra tính toán dịch và xoay trong phần vật lý sẽ khiến họ sử dụng CPU thay vì GPU sẽ ảnh hưởng đến hiệu suất.

Làm thế nào điều này được thực hiện bởi các chuyên gia và bạn có lời khuyên nào về kiến ​​trúc trò chơi hiệu quả để xử lý các tình huống như vậy?

Câu trả lời:


17

Có một số lý do tại sao các đường ống kết xuất và vật lý theo truyền thống được giữ riêng biệt. Hãy nhớ rằng tôi liệt kê những điều này, rằng đây không chỉ là về các trò chơi. Câu hỏi của bạn chạm vào bất kỳ ứng dụng nào sử dụng công nghệ kết xuất 3D như OpenGL, đó là đối thủ cạnh tranh hoặc là tiền thân.

  • Không phải mọi ứng dụng sử dụng 3D, đều cần vật lý. Hãy nhớ rằng OpenGL không chỉ được xây dựng cho các trò chơi, việc sử dụng nó bao gồm mọi thứ, từ mô phỏng y tế đến mô hình thống kê doanh số, mô phỏng giao thông hàng không đến các phản ứng hóa học phức tạp, v.v.
  • Bất kỳ hệ thống nào phục vụ quá nhiều mục đích đều trở nên loãng về hiệu quả. Một đường ống đồ họa phải cực kỳ nhanh. Thời điểm bạn bắt đầu giới thiệu các điểm mà đường ống đó phải giao tiếp với các hệ thống con khác, chẳng hạn như bộ nhớ hệ thống chính (nơi mã của bạn cư trú), bạn sẽ trải nghiệm việc giảm hiệu quả theo thứ tự. Phần cứng trên card đồ họa của bạn được thu hẹp rất đặc biệt và cực kỳ tối ưu hóa cho việc đẩy pixel , với chi phí lớn và nhiều năm nghiên cứu có tính cạnh tranh cao.

  • Bản chất của toán học và cấu trúc dữ liệu xung quanh các hoạt động vật lý (đặc biệt là phát hiện và giải quyết va chạm, mà không thực sự không có vật lý ) phần lớn khác với toán học cần thiết để kết xuất.

  • Có những giải pháp liên quan đến vật lý trong phần cứng. Nhưng không giống như cách chúng ta kết xuất, cách chúng ta thực hiện vật lý trong bất kỳ tình huống cụ thể nào khác nhau. Dấu hiệu cơ bản nhất của điều này là vật lý Newton không phải là một kích thước phù hợp với tất cả; có những cách khác để mô hình hóa vật lý theo toán học phù hợp hơn trong các tình huống khác, chẳng hạn như cơ học Hamilton. Và trong các trò chơi, đặc biệt, mỗi trò chơi riêng lẻ có thể chọn mô hình vật lý khác nhau, cho dù ở dạng 2D hay 3D. Những điều này thậm chí không cần phản ánh vật lý trong thế giới thực! - bởi vì một trò chơi là một sản phẩm của trí tưởng tượng. Nói cách khác, vật lý cuối cùng là một phần của trò chơi năng động của bạn và điều đó có thể thay đổi từ trò chơi này sang trò chơi khác - chứ đừng nói đến tất cả các giải pháp khác mà công nghệ như OpenGL được áp dụng.
  • Phần lớn mô phỏng vật lý chính xác ở cấp độ đỉnh-đỉnh là, phần lớn, hiện không phải là một lựa chọn khả thi. Với số lượng mô hình nhiều poly trong hầu hết các trò chơi và độ khó phát hiện va chạm liên quan đến khối đa diện lõm, không đơn giản chỉ là tính toán vật lý khỏi mô hình được cung cấp. Đối với nhiều người nếu không phải hầu hết các trò chơi 3D, khối lượng giới hạn ở dạng hình trụ hoặc hộp được sử dụng để đơn giản hóa việc phát hiện va chạm, trong đó mức độ phát hiện va chạm đó thậm chí còn được yêu cầu. Với công nghệ hiện tại, mức độ xử lý liên quan sẽ không còn nhiều chỗ cho phần còn lại của logic trò chơi của bạn chạy. Ngay cả PhysX của Nvidia cũng yêu cầu các khối đa diện lõm, phức tạp phải được phân tách thành các khối đa diện lồi đơn giản hơn, để mô phỏng vật lý.

  • Card đồ họa của bạn đang tạo ra phối cảnh với các biến đổi mà nó thực hiện. Điều đó khác với các phép biến đổi được thực hiện trong vật lý, không liên quan gì đến viễn cảnh như vậy - nó chỉ đơn giản là tính toán các vị trí và định hướng cơ bản trong thế giới của bạn. Nếu bạn biết về MVC, bạn sẽ hiểu rằng có một sự khác biệt rõ rệt giữa dữ liệu bạn giữ trong ứng dụng của bạn và cách trình bày dữ liệu đó của bạn .

Ngành công nghệ máy tính được thúc đẩy bởi nhu cầu, và mặc dù trực quan hóa là một nhu cầu gần như phổ biến, nhưng mô phỏng vật lý không có nghĩa là phổ quát theo yêu cầu hoặc về mặt triển khai tương ứng.

Vì vậy, lời khuyên của tôi là, hãy ngừng lo lắng về việc đi ngược lại ngũ cốc và bắt đầu tập trung vào cách làm hai việc bạn cần làm: kết xuất và vật lý. Bạn sẽ không nhận được dữ liệu trong đường ống xử lý của card đồ họa (CUDA / OpenCl là trường hợp ngoại lệ): bạn đẩy vào hình tam giác và dữ liệu vật liệu, nó bơm ra thế giới 3D của bạn dưới dạng hình ảnh chuyển động.


Cuối cùng, câu hỏi của bạn không phải là không có ý nghĩa. Mong muốn có một cơ sở kết hợp cho vật lý và kết xuất, và thực tế là toán học dấu phẩy động có thể chậm hơn nhiều so với điểm cố định, cho chúng ta thấy lý do tại sao các công nghệ voxel đang chứng kiến ​​sự hồi sinh rất lớn: chúng đơn giản hóa toàn bộ thế giới xuống vị trí lưới , khối đa diện lồi theo trục. Điều này cải thiện đáng kể hiệu năng, bằng cách giảm số lượng toán học vectơ dấu phẩy động cần thiết cho các hoạt động vật lý, vì hiện tại bạn đang làm việc chủ yếu trong một mạng lưới được lập chỉ mục số nguyên, không thể phân chia được. Lưới này có thể được sử dụng cho cả kết xuất và vật lý, đặc biệt là khi bạn có thể sử dụng các độ phân giải lưới khác nhau cho hai hệ thống con riêng biệt này (khi sử dụng giải pháp dựa trên octree như SVO).


3
Điểm đạn thứ năm cần được nhấn mạnh hơn: bạn thường sử dụng hình học va chạm tách biệt với hình học trực quan.
jhocking

Câu trả lời của bạn rất sâu sắc. Cảm ơn rât nhiều. Tôi đã nghĩ đến việc sử dụng OpenCL cho mã vật lý. Điều này sẽ gây ra các hoạt động ma trận chuyển đổi mà tôi đã nói về việc được thực hiện trên GPU và sẽ tăng thêm một chút hiệu suất. Bạn nghĩ gì, đây có phải là một ý tưởng tốt?
M.Sameer

3
Đó là một vinh dự. "Chúng ta nên quên đi những hiệu quả nhỏ, nói về 97% thời gian: tối ưu hóa sớm là gốc rễ của mọi tội lỗi" -Donald Knuth. Tập trung vào logic của bạn, và tối ưu hóa như và nơi bạn cần. Bạn quá quan tâm đến hiệu suất ở những gì tôi đoán là giai đoạn rất sớm trong quá trình phát triển trò chơi của bạn. Thật dễ dàng để làm chậm mọi thứ hơn khi chia sẻ xử lý giữa CPU và GPU như với CUDA / OpenCL. Google "CUDA chậm", bạn sẽ tìm thấy rất nhiều kết quả. Những gì bạn gửi cho GPU phải được xử lý rất cẩn thận. Đừng mong đợi được viết cứ sau vài mili giây, v.v.
Kỹ sư
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.