physic/collision

[jack79]

hallo!

ich hab noch folgendes 'physik-engine' problem:

um meinen gleiter korrekt über einer strecke schweben bzw fahren zu lassen, verwenden wir ein collision model. dieses hat eine bestimmte position und einen geschwindigkeitsvektor.
vor jeder 'weiterfahrt' wird abgefragt, ob auf dem derzeitigen weg eine collision stattfindet. wenn nicht, kein problem. aber findet eine statt, bekomm ich von der collision detection die position der collision, und die art der kollision (face-vertex, edge-vertex, vertex-vertex) und den normalvektor des vertex, der face bzw bei edge den der kante anschließenden flächen (mittle ich dann einfach).
nun setz ich den gleiter auf diese stelle, und berechne mir für die 'weiterfahrt' einen neuen geschwindigkeitsvektor (einfach anhand ausfallswinkel = einfallswinkel), teste wieder auf collision und so weiter. bei einigen teilen der strecke funktioniert das ja auch sehr gut, allerdings bei anderen verhält es sich so, als ob sie zum teil nicht vorhanden wären.
normalvektoren sollten korrekt transformiert sein.
vielleicht kann mir ja jemand sagen, wieso das so nicht (immer) funktioniert

danke,
florian

[tivolo]

hmm, um welches spiel handelt es sich denn?
frage deshalb, weils bei collision detection ziemlich darauf ankommt, WAS man WIE erreichen möchte.

vielleicht kann ich dann weiterhelfen.

mfg,
tivolo

[MarianSchedenig]

Immer noch Skydoo. ;) Du hast uns ja schon beim letzten Repetitorium ein paar Tips gegeben, aber offensichtlich geht's immer noch nicht. (Ich kenn mich mit unserer Physik wenig aus, bin mehr für Effekte & Spielprinzip zuständig :)).

[jack79]

prinzipiell wäre auf die zur zeit umgestellte methode, die im repetitorium diskutierte...
probleme könnten ev. das mitteln der face normals bei einer edge collision sein. bin mir da aber nicht sicher.

florian

[ChrisChiu]

Eventuell Präzisionsprobleme beim Triangle-Line-Intersection Test (Oder sonstirgendeinem Test)?

Das kann leider recht oft vorkommen, deswegen könnte man z.B. bei Vergleichen nicht den exakten Wert vergleichen sondern eine "Epsilonumgebung".

[tivolo]

das mit den präzisionsproblemen ist ein gutes argument.
meine characters sind am anfang auch des öfteren so richtig schön in den boden eingesunken... irgendwann hab ich beim debuggen dann gemerkt, dass ein float statt 5.00 genau 4.9999 hatte.
ein epsilon, delta oder sonstwas miteinzubeziehen kann also nicht schaden ;)

verwendest du immer noch das system mit den 3 bounding-spheres?

wenn ja, dann erklär mir mal ein bisserl genauer, wie du das ganze angehst. würd gerne helfen - irgendwie muss das problem ja bewältigbar sein.


mfg,
tivolo

[jack79]

ja, probleme mit der genauigkeit hatte ich vor allem bei winkelberechnungen :) ...aber die sind soweit ich denke alle behoben.

die drei bounding spheres verwende ich nur, um bei einer aktuellen position des raumgleiters seine aktuelle ausrichtung zu bestimmen.
beim fahren 'an sich' gibt es ein collision model. dieses besitzt eine genaue position und einen velocity vector.
und genau mit diesem modell teste ich bei der fortbewegung, ob es mit der strecke in berührung kommt oder nicht. wenn nicht fährt es halt dorthin, wo immer es auch hinfahren will.
a) kommt eine kollision zustande, dann unterteile ich sozusagen meinen geschwindigkeitsvektor -> skydoo fährt einmal soweit, als es kollisionsfrei möglich ist. dann bekomm ich von der collision einen normalvektor der strecke. anhand von diesen bestimm ich mir dann einen ausfallsvektor (zur zeit einfach der tatsächliche ausfallswinkel.. kann man dann später ev. noch dämpfen, je nach bedarf).
b) dann fahr ich in richtung ausfallsvektor weiter, teste aber wieder, ob sich eine collision ergibt. ist dies der fall, weiter mit a)
c) am endpunkt angelangt bestimm ich mir mittels der drei boundings spheres die ausrichtung des skydoos an der strecke. dies geschieht indem ich einfach den abstand zur strecke bestimme, und diesen gegebenenfalls korrigiere (drei bounding spheres, weil skydoo im prinzip dreiecksförmig ist und man mit drei "düsen" die ausrichtung bestimmen kann)

soweit man das beim testen erkennen kann, glaube ich, dass die meisten probleme genau da entstehen, wo ich eine vertex-edge collision habe, und daher die normalvektoren der beiden anliegenden faces mittle - sollte aber bei der struktur der strecke 'eigentlich' kein problem sein
damit die steuerung an sich kein probleme erzeugt, ist diese im fall einer kollision deaktiviert... d.h. durch einen äusseren einfluss kann das problem nicht entstehen

florian

[tivolo]

ich weiß nicht, obs an deiner terminologie liegt, aber an vertex-edge-collision kommt mir irgendetwas komisch vor. ich mein, eine collision hast du doch im prinzip IMMER mit einem face, nie mit vertices oder edges?

entweder reden wir aneinander vorbei, oder ich bin mir nicht ganz sicher wie ihr das bewerkstelligen wollt.

grundsätzlich find ich den ansatz ja richtig.

eine frage: bei der collision, was "kollidiert" mit was? die bounding box/sphere von eurem skydoo mit der strecke? oder machts ihr dann im endeffekt triangle-triangle-intersection?

ich glaub vor einem PC + debugger + sourcecode würd ich mir 10x leichter tun den fehler zu finden :)

mfg,
tivolo

[Chuck]

hmm klingt so, als ob sie ein low detail model gegen die strecke kollidieren lassen...
wobei vertex-edge kollsions können eigentlich nicht vorkommen... die möglichkeiten sind: edge-edge oder face-vertex... (wobei eigentlich face-vertex die sind, auf die ich mich konzentrieren würde... edge-edge dürften eigentlich nur bei sehr kantigen modellen auftreten...)

[MarianSchedenig]

hmm klingt so, als ob sie ein low detail model gegen die strecke kollidieren lassen...

Korrekt. Bounding Spheres/Boxes/usw. als genaueste Abfrage reichen nicht, wenn zwei Skydoos nahe beeinander/nahe an Hindernissen navigieren können sollen.

Zu den Details zur Kollisionabfrage weiß ich leider selber wenig. :)

edge-edge dürften eigentlich nur bei sehr kantigen modellen auftreten...)

Naja, recht kantig sind unsere Collision Models schon. Laut unserem Collision Detection-Programmierer wird die Detection sonst zu langsam.

[tivolo]

zu bounding boxes/spheres:

man kann ja immer a bisserl "schwindeln" :).

CD skydoo-skydoo mit bounding spheres (müsste eigentlich reichen, oder?) wenn 2 skydoos hintereinander fahren und kollidieren dann ist die distanz zwischen beiden sowieso schwierig zu erkennen.
CD skydoo-strecke mit bounding boxes, vielleicht anschließend mit genaueren tests. vielleicht könnts ihr ein hierarchisches system aus OOBB oder AABB beim laden der models generieren und diese anschließend bei jeder bewegung einfach mitrotieren. (AABB empfehlenswert, weil leichter)

triangle-triangle CD möcht ich der armen rapunzel nicht zumuten :p , auch wenn das model sehr kantig ist und nur 100 polys hat. und irgendwie halt ich's bei so einem spiel auch für a bisserl übertrieben.

mfg,
tivolo

[MarianSchedenig]

CD skydoo-skydoo mit bounding spheres (müsste eigentlich reichen, oder?) wenn 2 skydoos hintereinander fahren und kollidieren dann ist die distanz zwischen beiden sowieso schwierig zu erkennen.

Es geht vor allem darum, daß man "rempeln" können soll, da fallen größere Abstände schon auf. Und vor allem wird's problematisch, wenn man langsam fährt. Ich hasse nichts mehr als ein Spiel, bei dem ich einen halben Meter vor einem Pfosten abpralle, nur weil man "eh nicht so langsam fahren soll". :)

CD skydoo-strecke mit bounding boxes, vielleicht anschließend mit genaueren tests. vielleicht könnts ihr ein hierarchisches system aus OOBB oder AABB beim laden der models generieren und diese anschließend bei jeder bewegung einfach mitrotieren. (AABB empfehlenswert, weil leichter)

Hierarchische Ansätze hat unser CD-Programmierer eh schon im Kopf...wird er aber vorm Sommer nicht hinkriegen, meint er.

triangle-triangle CD möcht ich der armen rapunzel nicht zumuten :p , auch wenn das model sehr kantig ist und nur 100 polys hat. und irgendwie halt ich's bei so einem spiel auch für a bisserl übertrieben.

Naja, gerade bei dieser Art von Spiel finde ich das wichtig und nicht übertrieben. Bei FPS-artigen Spielen kann der Spieler durch einen Zylinder recht gut approximiert werden, aber wenn mehrere Gefährte auf einer Rennstrecke eng nebeneinander fahren und sich gegenseitig anrempeln, sollten sie nicht unbedingt abprallen, wenn sichtlich noch viel Freiraum dazwischen ist.

[raflegan]

Hallo,

also edge-vertex collision detection gibt es wirklich nicht, es gibt nur edge-edge und vertex-face.
Wichtig sind allerdings nur die Teile auf der Strecke mit denen der skydoo kollidiert (also ob man mit face, vertex oder edge der strecke kollidiert), weil nach den normalvektoren dieser faces, vertices oder edges wird der skydoo bei einer kollision ausgerichtet.
Und wir benutzen ein kollisionsmesh für den skydoo, weil andere kollisionsprimitive zu ungenau wären, z.B. eine Sphere ist an den Seiten vom Skydoo (das Skydoo ist dünn) sehr ungenau, und weil sich das skydoo nach allen seiten drehen kann (es kann also auch diagonal im Raum stehen) ist eine AABB auch ziemlich ungenau. Man könnte auch OBB verwenden, aber bei denen ist der aufwand auch nicht viel kleiner als bei einer Mesh kollision. Oder man könnte das skydoo kollisionsmodell mit mehreren kleinen primitiven machen, aber dann müsste man sehr viele primitive verwenden um auch alle "Lücken" zu füllen, oder sie sehr gross machen, was dann wieder ungenauer wäre.
Und unser kollisionsmodell ist wirklich sehr kantig (20 triangles), aber es ist immerhin noch besser als eine OBB.
Ein hierarchisches system haben wir eigentlich schon (einen quadtree), nämlich das gleiche das für die Sichtbarkeit verwendet wird, allerdings ist es halt nicht für kollisionsabfragen optimiert und eine eigene Hierarchie für die kollisionsabfrage wäre besser, aber dafür wird es bis zu Abgabe wohl nicht genug Zeit geben.

Paul

[tivolo]

@skydoo-gruppe:

kommt ihr heute in die CG2-VO? könnten uns dort unterhalten.
brauch mal wieder schlaf in der zwischenzeit...

mfg,
tivolo

[MarianSchedenig]

Danke für's Angebot....leider erst jetzt gelesen, und so wie's aussieht, haben wir's diesmal alle nicht bis zum Ende der VO ausgehalten. ;)

[tivolo]

bin wegen MM2-abgabe kurz verschwunden und als ich wieder gekommen bin, seid ihr nimma da gewesen.

mfg,
tivolo