Là cho thấy một sự va chạm trong chuyển động chậm tính toán thư giãn?


11

Trong rất nhiều game đua xe ( ví dụ Burnout Paradise ) khi sắp xảy ra va chạm, trò chơi sẽ tự động chuyển sang chuyển động chậm và tiếp tục theo trình tự chậm cho đến khi va chạm hoàn tất.

Tôi luôn nghĩ rằng đây là cho các hiệu ứng. Bạn không muốn bỏ lỡ bất kỳ phần nào của vụ va chạm! Nhưng một trong những người bạn của tôi gần đây đã đề xuất rằng điều này được thực hiện để đảm bảo không có tỷ lệ xử lý quá cao cần thiết khi xảy ra va chạm.

Bây giờ tôi nghĩ rằng nó thực sự là cách khác. Khi xảy ra va chạm, rất nhiều chi tiết được hiển thị trong chuyển động chậm, tôi chắc chắn có một chi phí trên đường ống dẫn tính toán và kết xuất.

Cái gì đúng?

Một cảnh chuyển động chậm có làm tăng mức sử dụng CPU / GPU hay giảm nó không?

Câu trả lời:


4

Nếu bạn đang chạy mô phỏng vật lý với dấu thời gian cố định (như bạn muốn), thì chuyển động chậm sẽ giảm tải cho mô phỏng vật lý, bởi vì sẽ phải thực hiện ít phép tính hơn trên mỗi khung.

Giả sử bạn đang chạy vật lý của mình với 200 cập nhật mỗi giây. Ví dụ. một cập nhật mỗi 0.005giây thời gian mô phỏng. Khi chạy trò chơi với 50 bản cập nhật mỗi giây, điều đó sẽ dẫn đến 4 bản cập nhật vật lý cho mỗi bản cập nhật kết xuất. Bây giờ bạn sẽ chạy trò chơi trong chuyển động chậm, điều đó có nghĩa là bạn đang làm chậm thời gian mô phỏng. Vì vậy, nếu trò chơi vẫn chạy ở tốc độ 50 cập nhật mỗi giây ( 0.02giây thời gian mô phỏng), nhưng bạn đang hiển thị thế giới ở chế độ chuyển động chậm (giả sử là một nửa tốc độ), thì một khung hình sẽ tương đương với 0.01giây của thời gian mô phỏng. Vì vậy, chỉ có 2 cập nhật vật lý trên mỗi khung hình được hiển thị. Có nghĩa là ít tính toán vật lý trên mỗi khung hình được hiển thị.

Vì vậy, nếu bạn đang xem xét nó từ góc độ sử dụng CPU trên mỗi khung hình được hiển thị, thì chuyển động chậm sẽ ít CPU hơn (trừ khi bạn chọn tăng tốc độ mô phỏng vật lý trong quá trình chuyển động chậm). Tải GPU trên mỗi khung hình dĩ nhiên là không đổi.

Nếu bạn hỏi về tải CPU / GPU tích lũy trong thời gian xảy ra một vụ va chạm , thì rõ ràng mô phỏng vật lý là như nhau, có thể là chuyển động chậm hoặc tốc độ bình thường. Tải GPU sẽ cao hơn, vì bạn kết xuất nhiều khung hình hơn.


Đoạn đầu tiên của bạn nói về tải GPU cao hơn. Tôi hy vọng tải trên GPU tương đối ổn định, hoặc được nêu rõ hơn, liên quan trực tiếp đến tốc độ khung hình (giả sử nội dung của cảnh không thay đổi).
thịt

Ông nói rằng nó cao hơn mỗi lần va chạm , nhưng đó chỉ là do vụ va chạm kéo dài lâu hơn. Như câu cuối cùng của đoạn đầu tiên nói.
MichaelHouse

Tôi nghĩ rằng trong trường hợp trung bình, tất cả các tải nên giữ nguyên như nhau - mã sẽ chạy qua cùng một đoạn và do đó sẽ có cùng tải. Trong các trường hợp đặc biệt, tôi nghĩ rằng tải trên CPU thực sự sẽ cao hơn trong trường hợp chuyển động chậm khi được quan sát trong suốt thời gian xảy ra va chạm, vì độ phân giải va chạm của chúng có thể sẽ hoạt động với một số yếu tố bước thời gian mà sẽ nhỏ hơn rất nhiều (làm cho bản dịch kết quả nhỏ hơn) trong chuyển động chậm, làm tăng khả năng va chạm sẽ được phát hiện trên mỗi khung hình, dẫn đến độ phân giải
TravisG

Tôi không thêm vào đó như một câu trả lời vì đó chỉ là những gì tôi có thể nghĩ ra ngay bây giờ và tôi không có dữ liệu hoặc trải nghiệm thực tế với các hệ thống chuyển động chậm để sao lưu: P
TravisG

2
@ Byte56 Câu hỏi là "Cảnh chuyển động chậm có làm tăng mức sử dụng CPU / GPU không?" Điều này [gần như] chắc chắn ngụ ý việc sử dụng mỗi lần, không phải mỗi lần va chạm. Vì vậy, tôi nghĩ rằng câu trả lời, theo như GPU đi, là nó vẫn không thay đổi. Tôi chỉ đưa ra điều này vì không rõ đoạn đầu tiên đang cố gắng truyền đạt điều gì.
thịt

3

thể thể là trường hợp này. Trừ khi bạn đang thực hiện vật lý cho sự va chạm trên GPU, điều đó có nghĩa là ngồi xổm cho điều đó. Nhưng về mặt vật lý ... nó có thể.

Nếu bạn đang mô phỏng chuyển động của một số cơ thể, chúng có xu hướng di chuyển theo một cách rất dễ đoán. Lực lượng và trường lực (tức là: trọng lực) có thể dễ dàng dự đoán. Nơi mà mọi thứ di chuyển nhanh chóng được tính toán.

Phải cho đến khi một điều đánh một thứ khác. Hãy xem, trong vật lý, bạn có cái được gọi là thời gian; đây là lượng thời gian mà việc thực hiện hệ thống vật lý bao trùm. Nếu thời gian của bạn bao gồm 1/30 giây (30 khung hình / giây cho cập nhật vật lý), thì mỗi cập nhật vật lý sẽ di chuyển các đối tượng 33,3 mili giây trong tương lai.

Khi các vật thể không va chạm, bạn có thể di chuyển chúng từ đầu 33.3ms đến cuối. Các vật lý để làm như vậy là đơn giản và đã nổi tiếng trong nhiều thế kỷ. Bạn chỉ cần xác định gia tốc từ các lực ròng, áp dụng gia tốc đó cho thời gian cho vật thể và di chuyển nó với vận tốc mới của nó (lưu ý: điều này có thể phức tạp hơn nếu bạn muốn độ chính xác cao hơn).

Vấn đề là khi các vật thể va chạm. Đột nhiên, bây giờ bạn phải xử lý các lực vật lý trong một khoảng thời gian, thay vì chỉ một lần lúc đầu. Nếu một vật va chạm hai lần hoặc ba lần trong khung vật lý, thì đó là nhiều tính toán vật lý mà bạn phải làm lại.

Nếu bạn có nhiều va chạm trong một lần, bạn thực sự có thể giết chết tốc độ khung hình của mình. Tuy nhiên, cơ hội va chạm trong một khoảng thời gian sẽ giảm khi kích thước của thời gian giảm. Các sim đua cao cấp như Forza và Gran Turismo chạy các hệ thống vật lý của họ ở tốc độ khung hình đáng kinh ngạc. Tôi nghĩ rằng một trong số họ đạt tới hơn 300 khung hình / giây trên bản cập nhật vật lý của họ.

Chuyển động chậm là tương đương hiệu quả của điều đó. Bằng cách giảm thời gian vật lý mà không tăng kết xuất khung hình để bù đắp, thế giới dường như chậm hơn. Và do đó, bạn làm cho ít có khả năng bạn bị va chạm nhiều lần trong một khoảng thời gian.

Điều đó đang được nói, tôi nghi ngờ rằng đây là lý do tại sao các trò chơi như thế này đi vào chuyển động chậm. Nói chung, nó nhiều hơn cho sự tinh tế trực quan và trình bày ấn tượng. Những hệ thống vật lý nói chung có thể xử lý nó, hiệu suất khôn ngoan.


1

Trước hết, điều này được thực hiện cho hiệu ứng hình ảnh, không phải vì lý do hiệu suất.

Cách tiêu chuẩn để đối phó với hiệu suất trong các trò chơi nặng vật lý là chia tỷ lệ số lượng đối tượng, chia tỷ lệ độ phức tạp của đối tượng và sử dụng các cài đặt động cơ để chia tỷ lệ giữa độ chính xác và hiệu suất mô phỏng. Nếu có vấn đề, bạn sẽ bỏ đi những gì bạn cho là những tính năng ít quan trọng nhất.

Mặc dù vậy, hãy nhớ rằng, ngành công nghiệp đã tạo ra các trò chơi ô tô khá thực tế trong 15 năm qua, với các máy tính hiện đại, không giống như họ phải thu nhỏ lại 3 bánh để vận hành.

Vấn đề:
Đúng là một vụ va chạm có thể gây ra thêm công việc, phụ thuộc rất nhiều vào chi tiết cụ thể của trò chơi, một công cụ vật lý chi tiết hơn sẽ có rất nhiều va chạm nhỏ giữa các phần khác nhau có thể tạo ra sự gia tăng đáng kể trong tính toán cần thiết . Nhưng điều đó nên được tính đến khi vật lý được thu nhỏ, không phải là vấn đề để có được vật lý tốt mà vẫn có thể xử lý một số va chạm.

Nếu bạn chỉ đơn giản chạy mô phỏng vật lý chậm hơn để có chuyển động chậm, tải sẽ giảm tương ứng. Tuy nhiên, người ta cần lưu ý rằng các yêu cầu đối với chuyển động chậm và vật lý thời gian thực là khác nhau, bạn có thể đủ khả năng để có độ chính xác thấp hơn khi mọi thứ xảy ra ở tốc độ đua. Miễn là người chơi không nhận thấy rằng động cơ vật lý sai thì đó không phải là vấn đề lớn, chuyển động chậm làm cho các cú trượt dễ dàng hơn nhiều, do đó chuyển động chậm có yêu cầu độ chính xác cao hơn.

Người ta có thể chọn sử dụng cùng một vật lý, được thu nhỏ để đáp ứng cả hai yêu cầu. Giải pháp này sẽ đòi hỏi một số khả năng xử lý bổ sung, nhưng nó dễ thực hiện và mang lại cho các máy tính hiện đại hoàn toàn khả thi.

Chuyển đổi cài đặt vật lý phức tạp hơn, nhưng có khả năng dẫn đến một số va chạm tuyệt đẹp, không chỉ có thể tăng độ chính xác, mà còn có thể chuyển đổi mô hình vật lý của ô tô để có những chi tiết tốt hơn phá vỡ thời trang thực tế hơn. Chế độ này sẽ kết thúc bằng cách sử dụng khoảng thời gian CPU tương đương với vật lý như chế độ bình thường, đơn giản vì cả hai đều được thu nhỏ để chạy ở cùng một cấu hình minspec.

Một cách trung gian là sử dụng một công cụ vật lý bước thay đổi, nói chung sẽ tăng độ chính xác khi bạn làm chậm quá trình mô phỏng, do đó giải quyết ít nhất một phần của vấn đề. Có những lý do khác để không sử dụng vật lý bước biến, nhưng bước biến vẫn khá phổ biến trong ngành.

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.