Công nhân web cho mô phỏng vật lý trò chơi HTML5?

12

Một chút liên quan đến câu hỏi này .

Ý tưởng là để đảm bảo hành vi vật lý giống nhau càng nhiều càng tốt. Có thể chạy vật lý bước thời gian cố định trên một nhân viên web không? Giao diện người dùng sẽ tự cập nhật với tốc độ làm mới khác nhau / thay đổi.

Có ai đã thử như vậy chưa?

physics javascript html5

— Petteri Hietavirta
nguồn

Bạn nghĩ gì để đạt được bằng cách sử dụng một nhân viên web? Cho đến nay câu trả lời của tôi sẽ là, điều đó sẽ làm việc, nhưng tại sao phải bận tâm?

— aaaaaaaaaaaa

3

Tôi tìm thấy thí nghiệm này . Nó chạy vật lý Box2d trên một nhân viên web. Tôi chưa kiểm tra chi tiết về cách giải quyết các vấn đề được đề cập trong các bình luận của Vincent Scheib.

— Petteri Hietavirta
nguồn

Thí nghiệm tốt. Tôi cũng đã theo dõi các loại dự án này. Thật không may, hầu hết vẫn được gắn với Java / C. Tôi tin rằng OP đang tìm cách loại bỏ điều này một cách tự nhiên trong trình duyệt (không có plugin).

— Kevin Peno

2

Bài viết tương tự của một anh chàng google: t.co/AuhPptB

— sorenbs

2

Điều này có thể hoạt động, tuy nhiên WebWorkertheo mô hình người quan sát , document(trang html sở hữu công nhân) chỉ có thể nghe và gửi tin nhắn đến / từ một nhân viên. Từ đó, có một vài lựa chọn, tôi đoán vậy. Trong mọi trường hợp, tôi nghĩ rằng bạn sẽ cần phải tìm cách nào đó để xác định FPS tối ưu của tác nhân người dùng để tối ưu hóa thông tin. Sau đó, bạn có thể:

Nói với công nhân để gửi tin nhắn vào những khoảng thời gian đó
- Nhược điểm (s?): Bạn phải cho rằng documentsẽ sẵn sàng cho phản hồi khi nó xảy ra.
Yêu cầu documentgửi tin nhắn cho công nhân yêu cầu vật lý trong khoảng thời gian x, sau đó công nhân sẽ gửi phản hồi (hy vọng) ngay sau đó.
- Nhược điểm: vì tất cả các bài đăng và phản hồi không đồng bộ, có thể có sự chậm trễ giữa yêu cầu và phản hồi từ nhân viên. Trong trường hợp này, bạn cũng sẽ phải loại bỏ onmessagesự kiện này để ngăn không cho bạn documentnghe khi nó không xảy ra.

Tôi chắc chắn có những điều khác tôi đã bỏ lỡ hoặc cách để xử lý thông tin liên lạc là tốt. Tôi sẽ mong chờ câu trả lời khác về chủ đề này!

— Kevin Peno
nguồn

1

a) Chú ý về hiệu suất! Xem xét requestAnimationFrame và báo hiệu 'giữ mạng' cho nhân viên của bạn khỏi nó, để bạn không đốt CPU nếu tab được đặt ở chế độ nền (có lẽ quá lâu)

— Vincent Scheib

b) IIRC Tất cả tin nhắn từ nhân viên sẽ được nhận trên luồng chính, họ sẽ xếp hàng. Hãy suy nghĩ về những tác động sẽ có trên chủ đề chính của bạn, nếu bạn có 5 bản cập nhật nhưng chỉ cần bản cập nhật mới nhất. Bạn cũng không thể nói rằng bạn sẽ đến nhiều hơn.

— Vincent Scheib

c) Tất cả các tin nhắn đang tạo bản sao của dữ liệu. Càng nhiều dữ liệu bạn phải gửi giữa các luồng, càng nhiều dữ liệu sao chép và thu gom rác hoạt động. Vì vậy, một chiến thắng ở đây sẽ chỉ tồn tại nếu có tỷ lệ dữ liệu tính toán / thông báo cao.

— Vincent Scheib

@Vincent, liên quan đến B) đó là lý do tại sao tôi nói rằng bạn cần phải documentluôn sẵn sàng bằng cách tìm một khung hình / giây hợp lý hoặc đi với tùy chọn 2 trong đó công nhân không làm gì cho đến khi documentyêu cầu.

— Kevin Peno

2

Physijs sử dụng một nhân viên web. Nó kết hợp vật lý ammojs với các đối tượng Three.js và cập nhật chúng khi cần. Nó có cả các bước thời gian cố định và chất lỏng, tôi tin rằng

— ebaum
nguồn