Der Witz „Verlet ist nur Verlet, wenn es aus der französischen Region Verlet kommt, sonst ist es nur sprudelnder Euler“ ist großartig.
Ich frage mich, wie man von Kenntnissen in Webentwicklung, Gradle und Java zu dem Punkt kommt, so etwas zu bauen.
Da ich kein Informatikstudium gemacht habe, habe ich manchmal das Gefühl, dass ich so etwas nie verstehen werde, egal wie viele Programmiersprachen ich lerne. Ich habe OPENLY, LIBGDX, GODOT und Unity ein wenig ausprobiert, aber eine Stoffsimulation von Grund auf zu bauen wirkt wirklich einschüchternd.
Es ist viel einfacher, als man denkt. Die an anderer Stelle in diesem Thread verlinkte Demo mit „reißendem Stoff“ habe ich gebaut, bevor ich überhaupt meine Laufbahn als Software Engineer begonnen hatte.
Hier wird grundlegende Verlet-Integration verwendet: 2D-Vektoren, die ein Gitter bilden, werden anhand ihrer aktuellen und vorherigen Position aktualisiert, und es wird erzwungen, dass sie zu ihren direkten Nachbarpunkten einen bestimmten Abstand einhalten. Zeichnet man Linien zwischen diesen Punkten, erhält man Stoff. Ich war von Physiksimulationen fasziniert, habe danach gesucht und bin darauf gestoßen, weil es eines der am leichtesten zu implementierenden Dinge ist; der Aufwand im Verhältnis zum Ergebnis war sehr gut. Danach wird es natürlich deutlich komplizierter.
Ich habe mich ähnlich gefühlt, als ich Physiksimulation lernen wollte. Mit der Zeit habe ich gelernt, dass man Wissensbereiche wie Physik von den Programmierwerkzeugen trennen muss, mit denen man sie implementiert.
Besonders wenn man mit Spieleentwicklung anfängt, hat man den Eindruck, dass es für jede große Simulation – starre Körper, Stoff, Federn, Fluide – eine natürliche, idiomatische Art zu programmieren geben müsste. Anfangs dachte ich, auch Fluidsimulation würde sich ganz natürlich in einer Sprache ausdrücken lassen, etwa indem man ein Gitter erstellt und pro Zeitschritt Aktualisierungsregeln auswählt. Tatsächlich modelliert man das Problem aber zuerst mathematisch und physikalisch und bildet es dann auf Sprache und Werkzeuge ab; diese Werkzeuge können das nicht immer idiomatisch ausdrücken.
Es gibt Algorithmen wie Stoffsimulationen auf Basis von Partikelpositionen und Federn, die sich leicht in Code übertragen lassen, aber als ich weitergehen wollte, hat genau das eher zu Missverständnissen geführt. Am Ende musste ich tiefer in Physik und numerische Mathematik einsteigen und das Problem dann in Code übersetzen; der resultierende Code kann grob wirken und viele Magic Numbers enthalten.
Webentwicklung ist nicht nur auf Java beschränkt und wird im Allgemeinen stark von Problemen der Komponentenintegration geprägt. Es gibt viel Struktur, aber wenig Inhalt; Berechnungen werden an Bibliotheken delegiert, zur Build-Zeit ist Integrationskomplexität das Problem, zur Laufzeit die Größenordnung verteilter Systeme.
Das Schreiben von Simulationen ist dagegen rechenintensiv, sodass der größte Teil des Codes tatsächlicher Inhalt ist. Wenn Webentwicklung eine Kombination heterogener Dinge ist, dann sind Simulationen homogener. Die Einschränkung ist das Zeitbudget, das durch die Frames pro Sekunde vorgegeben wird, und die Performance eines einzelnen Prozesses.
Deshalb kann man sich auf eine einzige Laufzeitumgebung konzentrieren. Ich empfehle den Browser, weil er das Deployment-Problem löst. Ganja[1] ist vielleicht das ultimative Simulationsprojekt, das eher „Inhalt statt Struktur“ ist. Es ist sehr ungewöhnlich und schwer zu verstehen, weshalb die Wartung eingestellt wurde, aber es funktioniert. Etwas strukturierter ist D3; die Autoren haben moderne Visualisierungs-/Layout-Algorithmen wie force-basierte Graphen[2] bereits umgesetzt. Ein zugänglicherer Einstieg könnte die Processing[3]-Familie sein, die mit Java begann und unter anderem nach Python und JavaScript portiert wurde.
Eine einzelne Stoffsimulation ist allerdings, verglichen mit einer Game Engine, etwa so etwas wie eine einzelne Zelle einer Maus. Game Engines sind sehr groß, und auch dort macht man eher viel interne Integration, statt Simulationen direkt selbst zu schreiben.
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
Letztlich ist das alles Mathematik und Physik.
Du hast zwar nicht ausdrücklich nach Spieleentwicklung gefragt, aber Wissen zu Grafik, Mathematik, Beleuchtung und Physik ist in diesem Bereich im Allgemeinen stark verbreitet. Wenn man nur nach einem Nischenthema wie Stoffsimulation sucht, kann es schwierig sein, Informationen zu finden, die nicht mit Materialien zur Spieleentwicklung verknüpft sind.
Heute habe ich https://alextardif.com/LearningGraphics.html gelesen; das kann in mehrere Richtungen ein guter Wegweiser sein. https://learnopengl.com/ wird auch heute noch, trotz neuerer APIs wie Vulkan, Metal und DX12, durchweg gut bewertet. Die API sollte man allerdings als etwa 5 % des zu lösenden Problems betrachten. Ehrlich gesagt vielleicht sogar weniger, aber Vulkan ist noch schwergewichtiger, als man hört.
Wenn du kein C/C++ lernen willst, ist die WebGL-Community groß; du kannst also auch in entsprechenden Subreddits oder Foren anfangen. Trotzdem sind API und Plattform eher die Hülle um den beeindruckenden und neuen Teil, nämlich die eigentliche Physiksimulation.
Als Kontext: Ich bin Webentwickler/Gradle-/Java-Entwickler und baue in meiner Freizeit wieder an einer Game Engine, nachdem ich es vor einigen Jahren schon einmal versucht hatte.
So schwierig ist es nicht. In JavaScript stellt man jeden Punkt als (x,y,z) dar, gibt ihm eine Masse und wendet in jedem Frame Schwerkraft an; bei Bedarf fügt man etwas Rauschen hinzu.
Jedes Mal, wenn sich ein Partikel bewegen will, überträgt man die Kraft mithilfe von Trigonometrie über die Kanten auf andere Punkte und fügt etwas Dämpfung hinzu, damit nichts außer Kontrolle gerät. Die Masse bestimmt später, wie stark jeder Punkt von Kräften beeinflusst wird. Wenn 3D zu viel ist, kann man zuerst mit 2D anfangen.
Mir fällt das Polygon-Video ein, das das erstaunliche Stoffdesign in Elden Ring analysiert: https://youtu.be/wSSqx-Dh6ko
Was im Video nicht ausreichend betont wird: Stoff hat auch einen funktionalen Zweck. Er verdeckt die Form von Gegnern und macht es schwieriger, das Modell zu erkennen.
In einem Spiel, dessen Kern präzise Hit Detection und Nahkampf sind – wohl einer der innovativsten Aspekte der FromSoft-Spiele –, macht frei fließender Stoff es schwerer einzuschätzen, wie nah man an eine Figur heran muss, um einen Angriff zu treffen, oder wie weit man entfernt bleiben muss, um nicht getroffen zu werden. Zusammen mit schwer vorhersehbaren Bewegungen und Angriffsmustern erhöht das die Schwierigkeit weiter und macht jeden Kampf einzigartig.
Auch in der Realität hat Stoff diese Eigenschaft. Ein Gegner in Robe oder Umhang wirkt deutlich bedrohlicher und ist schwerer einzuschätzen.
Wegen der Gameplay-Schleife machen mir FromSoft-Spiele persönlich keinen Spaß, aber vom Design her halte ich einige von ihnen für die bestgemachten Videospiele aller Zeiten.
Es gibt auch meine Version von vor 14 Jahren: https://www.youtube.com/watch?v=G05M_Y6NQVM
Ich stimme zu: So ein Grundaufbau ist sehr einfach zu implementieren, und das Ergebnis sieht wirklich großartig aus.
Das war von mir. Die ursprüngliche Version, die ich auf CodePen gestellt habe, war ungefähr vor 13 Jahren.
Ich kann es selbst kaum glauben, aber wenn ich daran denke, dass das noch vor meinem ersten Programmierjob war, fühlt es sich wirklich sehr lange her an.
Schon das Videospiel Hitman von 2000 hatte Stoff, und Mirror's Edge von 2008 hatte reißbaren Stoff. Vermutlich war keines von beiden das erste.
Solche Stoffsimulatoren wirken immer ein Stück weit instabil. Wenn man Grid-Stoff erzeugt, springt er herum und beginnt, sich zufällig zu bewegen.
Ich frage mich, ob das an sich aufsummierenden IEEE-754-Gleitkommafehlern liegt.
Im Kontext von Physiksimulationen oder Game Engines lohnt es sich, nach numerischer Integration zu suchen. Als Einstieg kann man https://en.wikipedia.org/wiki/Numerical_methods_for_ordinary... lesen.
Soweit ich es verstehe, liegt es nicht nur an einfachen Gleitkommafehlern, sondern an der Natur der Approximation kontinuierlicher Funktionen durch einfache diskrete Schritte. Der verlinkte Wikipedia-Artikel enthält auch ein Diagramm, das zeigt, dass sich bei großen Schritten Fehler anhäufen, lange bevor die Gleitkommapräzision zum Problem wird.
Verschiedene Verfahren zur numerischen Integration haben unterschiedliche Trade-offs. Es gibt etwa Euler-Verfahren, Verlet und Runge-Kutta; manche Verfahren neigen dazu, Gesamtenergie aufzubauen, andere dazu, Energie zu verlieren – beides ist falsches Verhalten. Komplexere Verfahren funktionieren tendenziell etwas besser, aber dann stellt sich die Frage, ob der Gewinn durch komplexere Einzelschritte besser ist, als einen einfacheren und schnelleren Algorithmus häufiger zu iterieren.
In Physiksimulationen funktioniert Energieerhaltung nicht automatisch, wenn man sie nicht explizit einprogrammiert. Man braucht zum Beispiel regelmäßige direkte Korrekturen.
Nicht nur Rundungsfehler, sondern auch die Quantisierung der Zeit und andere kleine Fehler aus dem mathematischen Modell selbst spielen eine Rolle.
Wenn der Fehler in Richtung Dämpfung geht, wirkt es wie in der Realität: Energie wird dissipiert und die Bewegung kommt irgendwann zum Stillstand. Geht er in Richtung Beschleunigung, läuft die Simulation davon.
Dem Autor dieser Website möchte ich sagen: gut gemacht. Sie läuft einfach so, ohne externes JavaScript, und funktioniert auch auf Mobilgeräten.
Das kann man heutzutage über die meisten textbasierten Websites kaum noch sagen.
Wirklich beeindruckende Arbeit. Einfach, aber man schaut immer wieder hin, und sie zeigt gut, wie mächtig Verlet-Integration ist, um natürliche und plausible Stoffsimulationen zu erzeugen.
Wer sich dafür interessiert: Ich empfehle auch Jakobsens Paper aus der Hitman-Game-Engine. Ein Klassiker.
Es ist schön zu sehen, wie hier tatsächlich die schwierige Frage gestellt wird, wie so etwas funktioniert. Man bekommt jedes Mal das Gefühl, dass alles aus unzähligen kleinen Schritten entsteht, die sich über Jahre angesammelt haben.
Ich frage mich, ob man an den Punkt kommt, an dem Mathematik wie eine Wand wirkt, oder ob man einfach so lange dagegenklopft, bis man es versteht.
Am faszinierendsten ist, dass schon ein paar Parameter und Constraints reichen, um derart realistische Bewegungen entstehen zu lassen.
Da kommt einem der Gedanke, dass auch die Welt um uns herum vielleicht nur eine Menge verborgener Modelle und Kräfte ist – und dass unsere Aufgabe darin besteht, sie zu entdecken und zu simulieren. Schöne Arbeit.
1 Kommentare
Hacker-News-Kommentare
Ein weiteres Beispiel, das man im Browser ansehen kann: https://oimo.io/works/cloth/
Nachdem ich den Artikel von Marian Pekár gelesen und die Verlet-Integration verstanden hatte, konnte ich selbst eine Stoffsimulation bauen: https://pikuma.com/blog/verlet-integration-2d-cloth-physics-...
Ich frage mich, wie man von Kenntnissen in Webentwicklung, Gradle und Java zu dem Punkt kommt, so etwas zu bauen.
Da ich kein Informatikstudium gemacht habe, habe ich manchmal das Gefühl, dass ich so etwas nie verstehen werde, egal wie viele Programmiersprachen ich lerne. Ich habe OPENLY, LIBGDX, GODOT und Unity ein wenig ausprobiert, aber eine Stoffsimulation von Grund auf zu bauen wirkt wirklich einschüchternd.
Hier wird grundlegende Verlet-Integration verwendet: 2D-Vektoren, die ein Gitter bilden, werden anhand ihrer aktuellen und vorherigen Position aktualisiert, und es wird erzwungen, dass sie zu ihren direkten Nachbarpunkten einen bestimmten Abstand einhalten. Zeichnet man Linien zwischen diesen Punkten, erhält man Stoff. Ich war von Physiksimulationen fasziniert, habe danach gesucht und bin darauf gestoßen, weil es eines der am leichtesten zu implementierenden Dinge ist; der Aufwand im Verhältnis zum Ergebnis war sehr gut. Danach wird es natürlich deutlich komplizierter.
Besonders wenn man mit Spieleentwicklung anfängt, hat man den Eindruck, dass es für jede große Simulation – starre Körper, Stoff, Federn, Fluide – eine natürliche, idiomatische Art zu programmieren geben müsste. Anfangs dachte ich, auch Fluidsimulation würde sich ganz natürlich in einer Sprache ausdrücken lassen, etwa indem man ein Gitter erstellt und pro Zeitschritt Aktualisierungsregeln auswählt. Tatsächlich modelliert man das Problem aber zuerst mathematisch und physikalisch und bildet es dann auf Sprache und Werkzeuge ab; diese Werkzeuge können das nicht immer idiomatisch ausdrücken.
Es gibt Algorithmen wie Stoffsimulationen auf Basis von Partikelpositionen und Federn, die sich leicht in Code übertragen lassen, aber als ich weitergehen wollte, hat genau das eher zu Missverständnissen geführt. Am Ende musste ich tiefer in Physik und numerische Mathematik einsteigen und das Problem dann in Code übersetzen; der resultierende Code kann grob wirken und viele Magic Numbers enthalten.
Das Schreiben von Simulationen ist dagegen rechenintensiv, sodass der größte Teil des Codes tatsächlicher Inhalt ist. Wenn Webentwicklung eine Kombination heterogener Dinge ist, dann sind Simulationen homogener. Die Einschränkung ist das Zeitbudget, das durch die Frames pro Sekunde vorgegeben wird, und die Performance eines einzelnen Prozesses.
Deshalb kann man sich auf eine einzige Laufzeitumgebung konzentrieren. Ich empfehle den Browser, weil er das Deployment-Problem löst. Ganja[1] ist vielleicht das ultimative Simulationsprojekt, das eher „Inhalt statt Struktur“ ist. Es ist sehr ungewöhnlich und schwer zu verstehen, weshalb die Wartung eingestellt wurde, aber es funktioniert. Etwas strukturierter ist D3; die Autoren haben moderne Visualisierungs-/Layout-Algorithmen wie force-basierte Graphen[2] bereits umgesetzt. Ein zugänglicherer Einstieg könnte die Processing[3]-Familie sein, die mit Java begann und unter anderem nach Python und JavaScript portiert wurde.
Eine einzelne Stoffsimulation ist allerdings, verglichen mit einer Game Engine, etwa so etwas wie eine einzelne Zelle einer Maus. Game Engines sind sehr groß, und auch dort macht man eher viel interne Integration, statt Simulationen direkt selbst zu schreiben.
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
Du hast zwar nicht ausdrücklich nach Spieleentwicklung gefragt, aber Wissen zu Grafik, Mathematik, Beleuchtung und Physik ist in diesem Bereich im Allgemeinen stark verbreitet. Wenn man nur nach einem Nischenthema wie Stoffsimulation sucht, kann es schwierig sein, Informationen zu finden, die nicht mit Materialien zur Spieleentwicklung verknüpft sind.
Heute habe ich https://alextardif.com/LearningGraphics.html gelesen; das kann in mehrere Richtungen ein guter Wegweiser sein. https://learnopengl.com/ wird auch heute noch, trotz neuerer APIs wie Vulkan, Metal und DX12, durchweg gut bewertet. Die API sollte man allerdings als etwa 5 % des zu lösenden Problems betrachten. Ehrlich gesagt vielleicht sogar weniger, aber Vulkan ist noch schwergewichtiger, als man hört.
Wenn du kein C/C++ lernen willst, ist die WebGL-Community groß; du kannst also auch in entsprechenden Subreddits oder Foren anfangen. Trotzdem sind API und Plattform eher die Hülle um den beeindruckenden und neuen Teil, nämlich die eigentliche Physiksimulation.
Als Kontext: Ich bin Webentwickler/Gradle-/Java-Entwickler und baue in meiner Freizeit wieder an einer Game Engine, nachdem ich es vor einigen Jahren schon einmal versucht hatte.
Jedes Mal, wenn sich ein Partikel bewegen will, überträgt man die Kraft mithilfe von Trigonometrie über die Kanten auf andere Punkte und fügt etwas Dämpfung hinzu, damit nichts außer Kontrolle gerät. Die Masse bestimmt später, wie stark jeder Punkt von Kräften beeinflusst wird. Wenn 3D zu viel ist, kann man zuerst mit 2D anfangen.
Mir fällt das Polygon-Video ein, das das erstaunliche Stoffdesign in Elden Ring analysiert: https://youtu.be/wSSqx-Dh6ko
In einem Spiel, dessen Kern präzise Hit Detection und Nahkampf sind – wohl einer der innovativsten Aspekte der FromSoft-Spiele –, macht frei fließender Stoff es schwerer einzuschätzen, wie nah man an eine Figur heran muss, um einen Angriff zu treffen, oder wie weit man entfernt bleiben muss, um nicht getroffen zu werden. Zusammen mit schwer vorhersehbaren Bewegungen und Angriffsmustern erhöht das die Schwierigkeit weiter und macht jeden Kampf einzigartig.
Auch in der Realität hat Stoff diese Eigenschaft. Ein Gegner in Robe oder Umhang wirkt deutlich bedrohlicher und ist schwerer einzuschätzen.
Wegen der Gameplay-Schleife machen mir FromSoft-Spiele persönlich keinen Spaß, aber vom Design her halte ich einige von ihnen für die bestgemachten Videospiele aller Zeiten.
Solche Stoffanimationen haben mir schon immer gefallen. Zum ersten Mal habe ich das vermutlich in dissimulates CodePen-Demo mit reißbarem Stoff gesehen; kaum zu glauben, dass dieser Code vor 9 Jahren geschrieben wurde.
[1] - https://codepen.io/dissimulate/pen/eZxEBO
[2] - https://github.com/Dissimulate/Tearable-Cloth
Ich stimme zu: So ein Grundaufbau ist sehr einfach zu implementieren, und das Ergebnis sieht wirklich großartig aus.
Ich kann es selbst kaum glauben, aber wenn ich daran denke, dass das noch vor meinem ersten Programmierjob war, fühlt es sich wirklich sehr lange her an.
Solche Stoffsimulatoren wirken immer ein Stück weit instabil. Wenn man Grid-Stoff erzeugt, springt er herum und beginnt, sich zufällig zu bewegen.
Ich frage mich, ob das an sich aufsummierenden IEEE-754-Gleitkommafehlern liegt.
Soweit ich es verstehe, liegt es nicht nur an einfachen Gleitkommafehlern, sondern an der Natur der Approximation kontinuierlicher Funktionen durch einfache diskrete Schritte. Der verlinkte Wikipedia-Artikel enthält auch ein Diagramm, das zeigt, dass sich bei großen Schritten Fehler anhäufen, lange bevor die Gleitkommapräzision zum Problem wird.
Verschiedene Verfahren zur numerischen Integration haben unterschiedliche Trade-offs. Es gibt etwa Euler-Verfahren, Verlet und Runge-Kutta; manche Verfahren neigen dazu, Gesamtenergie aufzubauen, andere dazu, Energie zu verlieren – beides ist falsches Verhalten. Komplexere Verfahren funktionieren tendenziell etwas besser, aber dann stellt sich die Frage, ob der Gewinn durch komplexere Einzelschritte besser ist, als einen einfacheren und schnelleren Algorithmus häufiger zu iterieren.
Nicht nur Rundungsfehler, sondern auch die Quantisierung der Zeit und andere kleine Fehler aus dem mathematischen Modell selbst spielen eine Rolle.
Wenn der Fehler in Richtung Dämpfung geht, wirkt es wie in der Realität: Energie wird dissipiert und die Bewegung kommt irgendwann zum Stillstand. Geht er in Richtung Beschleunigung, läuft die Simulation davon.
Dem Autor dieser Website möchte ich sagen: gut gemacht. Sie läuft einfach so, ohne externes JavaScript, und funktioniert auch auf Mobilgeräten.
Das kann man heutzutage über die meisten textbasierten Websites kaum noch sagen.
Wirklich beeindruckende Arbeit. Einfach, aber man schaut immer wieder hin, und sie zeigt gut, wie mächtig Verlet-Integration ist, um natürliche und plausible Stoffsimulationen zu erzeugen.
Wer sich dafür interessiert: Ich empfehle auch Jakobsens Paper aus der Hitman-Game-Engine. Ein Klassiker.
Es ist schön zu sehen, wie hier tatsächlich die schwierige Frage gestellt wird, wie so etwas funktioniert. Man bekommt jedes Mal das Gefühl, dass alles aus unzähligen kleinen Schritten entsteht, die sich über Jahre angesammelt haben.
Ich frage mich, ob man an den Punkt kommt, an dem Mathematik wie eine Wand wirkt, oder ob man einfach so lange dagegenklopft, bis man es versteht.
Am faszinierendsten ist, dass schon ein paar Parameter und Constraints reichen, um derart realistische Bewegungen entstehen zu lassen.
Da kommt einem der Gedanke, dass auch die Welt um uns herum vielleicht nur eine Menge verborgener Modelle und Kräfte ist – und dass unsere Aufgabe darin besteht, sie zu entdecken und zu simulieren. Schöne Arbeit.