joeydee hat geschrieben:Ich glaube ich verstehe wie du das machst.
Prinzipiell müsste man ähnlich iterativ den geringsten Abstand (respektive ob eine Überschneidung stattfindet) zwischen zwei Brushes annähern können. Prinzip: beliebigen Surface-Punkt von Brush 1 auf die Oberfläche von Brush 2 "projizieren" (sprich kürzeste Distanz finden), diesen Punkt wieder auf Brush 1 projizieren usw. mehrfach hin- und herwerfen.
Ja, genau!
joeydee hat geschrieben:Mit Boxen geht das jedenfalls, und die PingPong-Strecke nähert sich der kürzesten Entfernung zwischen den Oberflächen (was automatisch die Sliding-Normale ergibt). Bilder dazu hatte ich kürzlich im Vorstellungsthread. Für Boxen gibts allerdings eine einfache explizite Abstandsfunktion (min/max der Halbachsen vergleichen, ohne Vertex- oder Polygon-Set).
Naja, es geht auch für Körper, die nicht Boxen sind. Nur bekommst du dann nach drei/vier/fünf mal hin- und herwerfen (gerade in deinen Szenario-Bild mit der sehr spitzen Ecke) eben nur einen Punkt ein bisschen darüber. Reicht mir aber.
joeydee hat geschrieben:
Ich werde mir das sicher nochmal ansehen - davon abgesehen, dass iterative Näherungsverfahren wahrscheinlich nicht der beste Weg für Culling-Aufgaben sind. Und sicher auch nicht der schnellste für Kollisionen.
So teuer ist das garnicht bzw. es ist nicht unakzeptabel langsam .. zumindest für das gesamte Collision Handling gesehen.
Die Iterationen hier sind ja auch nicht soo teuer .. Projektion "Punkt auf Ebene" sind ja nur "Vektorprodukte" und keine Atomphysik. Relativ preiswert noch.
Im Video oben mache ich es bereits so. Die untere Zahl oben rechts im Bild ist die Laufzeit einer Gesamt-Welt-Physik/Dynamik-Iteration" in Millisekunden (ich mache Multithreading - Dynamik-Modul ist streng entkoppelt vom Rest: für "alles" inder Szene also etwas <0.3ms auf einem Ryzen Kern @3,7Ghz; ca. bei 1,2 ms auf einem alten Core i5 Mobile [dual core] @2,5Ghz).
Zugegeben, die Szene ist nicht allzu komplex,was Dynamik angeht: Nebem dem Avatar, mit dem ich da im BSP-Model rumlaufe, stehen unter dem Berg noch 10 Goblins rum (sieht man im Video nicht), die zumindest auf das Terrain drücken/"fallen" und in der Stadt noch eine Person, die auch ständig "fällt" ... also berechnet wird. Aber sicher könnte man da noch optimieren und es ist ja noch Luft nach oben.
Ich hatte vor der Brush-Implementierung übrigens eine Vertex-basierte Boxen/Mesh-Implementierung (oriented Meshes .. das, was jetzt die Brushes sind) und die war ungefähr/gefühlt gleich schnell ... also zumindest keine Dimensionen langsamer jetzt und die Brushes sind von der Implementierung her deutlich eleganter ... finde ich.
Und ich muss bedenken: Die ganze Dynamik/Physik/Kollision Handling ist bei mir insgesamt ja auch Iterativ. Ich behandle die Kollision mit dem ersten Objekt, was ich finde, und resolve sie gleich. Ich suche nicht erst das "nächste Objekt". Dann suche ich den nächsten Kollider mit der neu resolvten Position. Bis es keine Kollision mehr gibt. Aber es gibt harte Limits: Das mach ich dann maximal X-Mal (~30 glaub ich) und dann würde ich die Bewegung einfach "hart abwürgen" bzw. je nach Konfiguration auch einfach "zulassen" (stehenbleiben bzw. durchlaufen). Ist mir aber schon ewig nicht mehr passiert, dass ich durch den Boden falle oder gegen die Wand stosse. Die Implemetierung ist inzwischen recht zuverlässig/robust. Obwohl sich das mit "Iteration" (mit Maximal-Limit) immer recht schwammig anhört, funktioniert es erstaunlich stabil. Bisher schafft er das Ganze immer in ca <6 Gesamtiterationen (pro Objekt) .. vielleicht so 2 oder 3 ..
Selbst bei recht gemeinen Kollisionsszenarion wie "seltsamen Ecken mit Schrägen darüber" ist alles noch im Limit. Sind ja auch .. Achtung .. der kommt flach .. Edge Cases.
joeydee hat geschrieben:
Für deinen Fall: wenn ich sowieso schon alles als separate Objekte splitte und verwalte, würde ich hier wahrscheinlich je Brush einmalig ein Vertex-Set berechnen und alles über Separating-Axis erledigen.
Ja, das Culling (das Frustum-Objekt) mache ich tatsächlich inzwischen wieder über Vertices, wobei man sich da vor Augen führen muss, dass man zur Projektion der Vertices auf die Achsen ja auch mehrmals ein Skalarprodukt macht (wenn nicht teilweise - z.B. für die Projektion der eignen Vertices auf die eignenen Achsen - precalculated). Das kostet in Summe auch, wenn auch nicht die Welt.
Ist aber gerade scheinbar der beste Kompromis und bis ich was besseres finde, mache ich das mal weiter...