ZFX + Developia

Jonathan hat geschrieben: ↑14.10.2024, 12:31 Ich sehe das größere Problem ehrlich gesagt in den Normalen / Tangenten. Die Bitmap ist ja nicht die Geometrie, sondern ein niedrigaufgelöstes Sampling der Geometrie. Betrachtet man die Bitmap als echte Geometrie aus Blöcken dann gibt es nur perfekt senkrechte und perfekt waagerechte Linien, keine Schrägen. Natürlich kann man diese Treppen mit Kugeln kollidieren lassen, aber das Verhalten wird vermutlich nicht das sein, was man erwartet.

Da könnte man eine 2D-Version von "Marching Cubes" implementieren. Marching Squares?

Ja, heißt Marching Squares, und jetzt klingt ihr mit Euren Bedenken exakt wie der Box2D-Discord, der meine Fragen gar nicht erst zur Kenntnis genommen hat, sondern gleich meinte, ich solle es sein lassen.

Was die Kontaktnormalen angeht, wollte ich das wie bei meinem Survival-Voxel-Spiel damals machen: die 5x5-Umgebung zu ner Normale verwursten. Ich mach aber erstmal Kugel vs. Bitmap, und da hast Du ganz bequem die Kugel-Richtung als Normale. Für Kugeln >> 1px Radius wird das schon ordentlich funktionieren. Kritisch wird's später bei Bitmap vs. Bitmap - da kann man sich Grenzfälle ausdenken, wo jede Heuristik scheitert. Aber erstmal soweit sein und dann sehen wir weiter.

TomasRiker hat geschrieben: ↑14.10.2024, 13:05 Da könnte man eine 2D-Version von "Marching Cubes" implementieren. Marching Squares?

Aber Marching Cubes hat doch als Eingabe ein Signed Distance Field, und das gibts hier doch nicht, oder?

Ich mach aber erstmal Kugel vs. Bitmap, und da hast Du ganz bequem die Kugel-Richtung als Normale. Für Kugeln >> 1px Radius wird das schon ordentlich funktionieren.

Ich bin da skeptisch. Habs mal eben aufgemalt: Nicht exakt gezeichnet, aber die selbe Kugel triff immer die selbe Ecke von dem mittleren 2-er Steinchen zuerst. Ich nehme an, das meintest du - Kugel mit exakten Quadraten kollidieren lassen und dann annehmen, dass die Berührungsebene tangential zur Kugel liegt.
Für den selben Kontaktpunkt kannst du jetzt aber sehr unterschiedliche Richtungen rausbekommen, nämlich alles zwischen den zwei roten Linien. Das ist dann doch arg ungenau. In "Wirklichkeit" approximieren die grünen Quadrate aber die blau Linie, wie man sieht ist die korrekte Normale also ungefähr zwischen den zwei maximalen.

Hier wird es jetzt philosophisch, ob die grüne oder die blaue Geometrie die wahre ist. Die meisten Spieler werden aber intuitiv von der blauen ausgehen, nicht von der grünen. Wenn du hundert Bälle gegen diese grüne Wand prallen lässt, springt jeder in eine andere Richtung, auch wenn die Wand "glatt" ist.

Was die Kontaktnormalen angeht, wollte ich das wie bei meinem Survival-Voxel-Spiel damals machen: die 5x5-Umgebung zu ner Normale verwursten.

Das ist, denke ich, die richtige Lösung. Lokal an die Geometrie eine kontinuierliche Funktion fitten, deren Normale man dann an der Kontaktstelle exakt berechnen kann. So kannst du auch für Runde Objekte sehr glatte (im Sinne von differenzierbare) Normalen bekommen, und nicht nur Stückweis-Lineare Funktionen, bei denen die Normalen dann plötzlich springen, wenn man ein kleines bisschen anders aufkommt.

Jonathan hat geschrieben: ↑Gestern, 10:35

TomasRiker hat geschrieben: ↑14.10.2024, 13:05 Da könnte man eine 2D-Version von "Marching Cubes" implementieren. Marching Squares?

Aber Marching Cubes hat doch als Eingabe ein Signed Distance Field, und das gibts hier doch nicht, oder?

Ja, stimmt. Ist nicht genau das gleiche. Die Idee dahinter wäre ähnlich. Man guckt sich an, welche der 4 Eckpunkte eines Quadrats 1 bzw. 0 sind, und erzeugt dann entsprechend Kanten.

Marching Cubes war auch der Vorschlag der Box2D-Community, und nach meinem Wissen macht z.B. Noita das so. Anekdote am Rande: xq hatte mir erzählt, dass die jetzt ihr "FallingEverything"-Engine zur Lizenzierung anbieten. Ich hatte lange mit mir gerungen, ob ich das überhaupt will, aber bevor ich dann überhaupt mit Box2D und dem Kollisionsthema anfing, sendete ich ihnen doch erstmal ne Mail. Immerhin haben die ja all diese Probleme schon gelöst, nämlich mit Marching Squares und Konvex-Zerlegung, wie in dem dort verlinkten Video auch erklärt.

Leider haben sie nie geantwortet. Ist jetzt drei Wochen her oder so, da kommt also wohl nix mehr. Also hab ich selbst angefangen. Und bevor ich 64x pro Sekunde Marching Squares und Konkavkrieg betreibe, wollte ich doch erstmal gucken, ob ich nicht auch Pixel-Kollision in Box2D reingepatcht kriege. Würde ja reichen, wenn ich nur die bewegten Trümmerteile marchen und konvex zerlegen müsste.

Clonk hat das ganze glaube ich mit wenigen "Testpixeln" gelöst. Die sind dann die Eckpunkte der Gefährte. Das spielt vor allem bei den Loren eine Rolle. Es kann dabei natürlich passieren, dass man den Loren auf einen "Erdspieß" schiebt und die Testpixel links und rechts vom Erdspieß hängen. Dadurch dass Clonk von einem frickeligen Spielgefühl lebt, hat mich das nie gestört. Ich glaube bei den Ubooten in Clonk gibt es mindestens drei Testpunkte. Vielleicht reicht das ja? Ich bin mir allerdings nicht sicher, wie die auf der Basis eine Normale zum schieben der Objekte berechnen. Vermutlich einfach ein paar Lookups entlang der Bewegungsrichtung oder so.