Web-Worker für die Simulation von HTML5-Spielphysik?

12

Ein bisschen im Zusammenhang mit dieser Frage .

Die Idee ist, das gleiche physikalische Verhalten so weit wie möglich zu gewährleisten. Wäre es möglich, eine zeitlich festgelegte Schrittphysik auf einem Web-Worker auszuführen? Die Benutzeroberfläche würde sich mit einer anderen / variablen Aktualisierungsrate aktualisieren.

Hat das schon jemand ausprobiert?

physics javascript html5

— Petteri Hietavirta
quelle

Was können Sie mit einem Web-Worker erreichen? Bisher würde meine Antwort lauten, das wird funktionieren, aber warum sich die Mühe machen?

— aaaaaaaaaaa

3

Ich habe dieses Experiment gefunden . Es führt Box2d-Physik auf einem Web-Worker aus. Ich habe noch nicht im Detail geprüft, wie es um Probleme geht, die in Vincent Scheibs Kommentaren erwähnt wurden.

— Petteri Hietavirta
quelle

Gutes Experiment. Ich verfolge auch solche Projekte. Leider sind die meisten immer noch an Java / C gebunden. Ich glaube, dass OP nach einer Möglichkeit sucht, dies nativ im Browser abzurufen (keine Plugins).

— Kevin Peno

2

Artikel über das gleiche von einem Google-Typ: t.co/AuhPptB

— Sorenbs

2

Dies könnte funktionieren, aber WebWorkers folgen dem Beobachter-Muster , die document(HTML-Seite, die dem Arbeiter gehört) kann nur Nachrichten an / von einem Arbeiter abhören und posten. Davon gibt es ein paar Möglichkeiten, denke ich. In allen Fällen, denke ich, müssen Sie einen Weg finden, um die optimale FPS des Benutzeragenten zu bestimmen, um die Informationen zu optimieren. Dann könnten Sie entweder:

Bitten Sie die Mitarbeiter, in diesen Zeitintervallen Nachrichten zu posten
- Nachteil (en?): Sie müssen davon ausgehen, dass der documentfür die Reaktion bereit ist, wenn dies geschieht.
Bitten Sie den documentMitarbeiter, in bestimmten Zeitabständen eine Nachricht an den Mitarbeiter zu senden, in der er um Physik gebeten wird. xKurz danach würde der Mitarbeiter (hoffentlich) eine Antwort veröffentlichen.
- Nachteil (en): Da alle Posts und Antworten asynchron sind, kann es zu Verzögerungen zwischen der Anforderung und der Antwort des Workers kommen. In diesem Fall müssten Sie auch das onmessageEreignis auf null setzen, um zu verhindern, dass Sie documentabhören, wenn dies nicht erwartet wird.

Ich bin mir sicher, dass es noch andere Dinge gibt, die ich verpasst habe, oder Möglichkeiten, mit der Kommunikation umzugehen. Ich freue mich auf weitere Antworten zu diesem Thema!

— Kevin Peno
quelle

1

a) Vorsicht bei der Leistung! Betrachten Sie requestAnimationFrame und signalisieren Sie Ihrem Worker, dass er am Leben bleibt, damit Sie die CPU nicht verbrennen, wenn der Tabulator im Hintergrund platziert wird (möglicherweise zu lange)

— Vincent Scheib

b) IIRC Alle Nachrichten des Workers werden im Haupt-Thread empfangen und in die Warteschlange gestellt. Überlegen Sie, welche Auswirkungen dies auf Ihren Haupt-Thread haben wird, wenn Sie 5 Updates haben, aber nur die neuesten benötigen. Sie können auch nicht sagen, dass Sie mehr kommen.

— Vincent Scheib

c) Alle Nachrichten kopieren Daten. Je mehr Daten Sie zwischen Threads senden müssen, desto mehr Kopier- und Speicherbereinigungsarbeiten fallen an. Ein Gewinn liegt hier also nur vor, wenn ein hohes Verhältnis von Berechnungs- und Nachrichtendaten vorliegt.

— Vincent Scheib

@Vincent, in Bezug auf B), deshalb habe ich gesagt, dass Sie entweder documentimmer bereit sein müssen, indem Sie ein angemessenes fps finden, oder gehen Sie zu Option 2, wo der Arbeiter nichts tut, bis er danach documentfragt.

— Kevin Peno

2

Physijs verwendet einen Web-Worker. Es verbindet die Physik von Ammojs mit den Objekten von Three.js und aktualisiert sie nach Bedarf. Ich glaube, es gibt sowohl feste als auch flüssige Zeitschritte

— Ebaum
quelle