Wipeout/F-Zero ähnliche Fahrzeug-Physik

[Andre]

Hi ZFX-Comunity!

Dieses Problem gibt es bei uns schon seit längerer Zeit und hindert uns wirklich am vorankommen. Ich habe nun schon so viel probiert und getestet, doch geklappt hat es nie. Jetzt weiß ich nicht mehr weiter.
Es geht um die Physik unseres Spiels Pulsedrive. Hier erstmal ein Bild des Schiffes und der Strecke, damit jeder versteht worum es eigentlich geht:

Im Moment ist das Schiff als Raycast-Vehicle umgesetzt. Dh. es gibt einige unsichtbare Federn unten drunter, die es oben halten. Das funktioniert soweit auch gar nicht schlecht, es gibt eben nur diese Probleme, wenn man etwas schneller fahren möchte. Dann fällt man durch den Boden, steckt in den Wänden bzw. fliegt durch, oder wird sonstwo hin geschleudert.
Auch bekommt man Probleme, wenn man über eine Bergkuppe fährt, da sich das Schiff nicht an der Strecke halten kann.
Ich habe zwar mit Magneten herumprobiert, aber entweder waren die zu stark (Schiff wird in den Boden geschmettert) oder zu schwach.

Dass vielleicht Tunneling auftritt denke ich nicht. Auf dem Bild sieht man ja, dass die Physik mit 0.06ms pro Frame läuft. Ich denke das sollte reichen.

Hat irgendjemand eine Idee, wie man so eine Art Schiff besser umsetzen könnte?
(Wir benutzen BulletPhysics)

[Chromanoid]

Vielleicht ein oder zwei gleitende Kugeln als Körper für das Schiff (ähnlich wie ein Fahrrad). Ihr solltet auf jeden Fall noch kontinuierliche Kollisionserkennung einstellen (oder mit den Parametern dazu herumspielen), dann sollte das mit dem durch den Boden fallen eigentlich nicht mehr auftreten. Ich könnte mir gut vorstellen, dass bei FZero evt. gar keine echte Physikberechnung eingesetzt wurde...

Ich hab neulich ein interessantes Tutorial gesehen, das zeigt wie der Vogel aus Tiny Wings mit Box2D über die Hügel gleitet. Sowas könnte vielleicht auch inspirieren.

[Andre]

Vielleicht ein oder zwei gleitende Kugeln als Körper für das Schiff (ähnlich wie ein Fahrrad).

Das habe ich auch ganz am Anfang versucht. Leider hüpft man dann über die stellen Zwischen den Streckensegmenten. Und an der Strecke kleben tut man so auch noch nicht. Dafür braucht man wieder eine Force, die einen auf den Boden drückt.

Ihr solltet auf jeden Fall noch kontinuierliche Kollisionserkennung einstellen

Ich meine schon öfters gelesen zu haben, dass Bullet das noch nicht richtig unterstützt, stimmt das?

Ich könnte mir gut vorstellen, dass bei FZero evt. gar keine echte Physikberechnung eingesetzt wurde...

Ja, ich auch. Von Wipeout weiß ich allerdings, dass, zumindest in der PSP-Version, auch ein Raycast Vehicle benutzt wurde.
Wie würde so eine "unechte" Physikberechnung denn aussehen? Ein Kinematic-Object, welches durch Raycasts Abstand hält?

[Chromanoid]

Vielleicht ein oder zwei gleitende Kugeln als Körper für das Schiff (ähnlich wie ein Fahrrad).

Das habe ich auch ganz am Anfang versucht. Leider hüpft man dann über die stellen Zwischen den Streckensegmenten. Und an der Strecke kleben tut man so auch noch nicht. Dafür braucht man wieder eine Force, die einen auf den Boden drückt.

Vielleicht einfach die Stellen zwischen den Segmenten mit unsichtbaren Elementen zu kitten? Ansonsten könntest du dir vielleicht mal den CharacterController anschauen und Bullet vor allem für Kollisionserkennung einsetzen und das Alignment an die Strecke selbst übernehmen. Aber so ähnlich machst du das ja wahrscheinlich jetzt schon mit dem VehicleController.

Ihr solltet auf jeden Fall noch kontinuierliche Kollisionserkennung einstellen

Ich meine schon öfters gelesen zu haben, dass Bullet das noch nicht richtig unterstützt, stimmt das?

Ich hab bisher nur JBullet angeschaut und da auch ein bisschen im Code rumgewühlt. Dort war es AFAIR so, dass ein delta-Wert angegeben werden konnte um die kontinuierliche Erkennung objektweise zu triggern. Ist diese aktiviert wird dann für das Objekt pro Step ein möglicher Zwischenstopp ermittelt (einfach ein Zeitewert bei dem die nächste Kollision wohl auftritt), der dafür sorgt, dass das Objekt nur vor das nächste Hindernis gesetzt wird und nicht durch fliegt. Ich würde es einfach mal ausprobieren...

Ich könnte mir gut vorstellen, dass bei FZero evt. gar keine echte Physikberechnung eingesetzt wurde...

Ja, ich auch. Von Wipeout weiß ich allerdings, dass, zumindest in der PSP-Version, auch ein Raycast Vehicle benutzt wurde.
Wie würde so eine "unechte" Physikberechnung denn aussehen? Ein Kinematic-Object, welches durch Raycasts Abstand hält?

Ja so vielleicht, ich glaube der CharacterController funktioniert auch so in der Art. Bei Kollisionen zwischen den einzelnen Fahrzeugen kann man dann ja normale Response oder so einstellen. Ich würde so eine Art Mischsteuerung versuchen. Also mit Rays oder GhostObjects testen ob als befahrbar markierte Flächen in der Nähe sind und dann das Fahrzeug irgendwie an die Bodennormale (mit einem bestimmten Abstand und entsprechender Federung/Verzögerung) angleichen. Vielleicht ohne Kinematic Objekte sondern einfach nur durch Kontrolle der Kräfte, dann kann man vielleicht leichter zwischen freiem Fall und Straßenmodus umschalten...

Das hier sieht auch ganz hilfreich aus: http://answers.unity3d.com/questions/10 ... -zero.html

[Andre]

Vielleicht einfach die Stellen zwischen den Segmenten mit unsichtbaren Elementen zu kitten?

Wenn ich es mit den 2 Kugeln machen sollte, werde ich das wohl in Betracht ziehen. Allerdings wird das schwierig. Mal sehen was unser Artist dazu sagt. Alles in allem würde ich diese Methode auch nur sehr ungern benutzen.

Ansonsten könntest du dir vielleicht mal den CharacterController anschauen und Bullet vor allem für Kollisionserkennung einsetzen und das Alignment an die Strecke selbst übernehmen. Aber so ähnlich machst du das ja wahrscheinlich jetzt schon mit dem VehicleController.

Ich benutze dafür nicht Bullet's VehicleController, sondern habe soetwas in der Art selbst geschrieben. Allerdings in der Scriptsprache von [w]tech, was mir vielleicht nicht den größten Freiraum gibt. Allerdings soll es später möglich sein soetwas damit zu machen.

Ich hab bisher nur JBullet angeschaut und da auch ein bisschen im Code rumgewühlt. Dort war es AFAIR so, dass ein delta-Wert angegeben werden konnte um die kontinuierliche Erkennung objektweise zu triggern. Ist diese aktiviert wird dann für das Objekt pro Step ein möglicher Zwischenstopp ermittelt (einfach ein Zeitewert bei dem die nächste Kollision wohl auftritt), der dafür sorgt, dass das Objekt nur vor das nächste Hindernis gesetzt wird und nicht durch fliegt. Ich würde es einfach mal ausprobieren...

Auch wenn ich setCcdMotionThreshold() mit einem sehr niedrigen Wert füttere werde ich bei einer hohen Gravitation durch den Boden gedrückt. Wäre es vielleicht möglich, dass das einfach an der Triangle-Mesh-Collision liegt, die die Streckenteile benutzen? (btScaledBvhTriangleMeshShape)

Ja so vielleicht, ich glaube der CharacterController funktioniert auch so in der Art. Bei Kollisionen zwischen den einzelnen Fahrzeugen kann man dann ja normale Response oder so einstellen. Ich würde so eine Art Mischsteuerung versuchen. Also mit Rays oder GhostObjects testen ob als befahrbar markierte Flächen in der Nähe sind und dann das Fahrzeug irgendwie an die Bodennormale (mit einem bestimmten Abstand und entsprechender Federung/Verzögerung) angleichen. Vielleicht ohne Kinematic Objekte sondern einfach nur durch Kontrolle der Kräfte, dann kann man vielleicht leichter zwischen freiem Fall und Straßenmodus umschalten...

Den CharacterController hab ich noch nie benutzt. Meine aber gelesen zu haben, dass es im Grunde auch nur ein Kinematic-Object ist. Genausowenig habe ich GhostObjects schon benutzt. Aber wenn sie das sind was ich denke könnten die in der Tat nützlich sein. Werde mich da mal einlesen.

[Chromanoid]

Ich hab bisher nur JBullet angeschaut und da auch ein bisschen im Code rumgewühlt. Dort war es AFAIR so, dass ein delta-Wert angegeben werden konnte um die kontinuierliche Erkennung objektweise zu triggern. Ist diese aktiviert wird dann für das Objekt pro Step ein möglicher Zwischenstopp ermittelt (einfach ein Zeitewert bei dem die nächste Kollision wohl auftritt), der dafür sorgt, dass das Objekt nur vor das nächste Hindernis gesetzt wird und nicht durch fliegt. Ich würde es einfach mal ausprobieren...

Auch wenn ich setCcdMotionThreshold() mit einem sehr niedrigen Wert füttere werde ich bei einer hohen Gravitation durch den Boden gedrückt. Wäre es vielleicht möglich, dass das einfach an der Triangle-Mesh-Collision liegt, die die Streckenteile benutzen? (btScaledBvhTriangleMeshShape)

Ehrlich gesagt hab ich leider keine Ahnung. Ich hab JBullet bisher nur für eine Murmelbahn benutzt und ein bisschen an den Innereien rumgebastelt um das ganze auf mehrere Rechner zu verteilen (siehe http://zfx.info/viewtopic.php?f=10&t=112&p=27266#p27266). Ich hab dazu auch das BvhTriangleMeshShape eingesetzt. Mir sind die Kugeln ab und zu bei höheren Fall-Geschwindigkeiten durch den Boden geballert, allerdings habe ich auch CCD ausgelassen usw. weil ich das nicht auch noch verteilen wollte...
GhostObjects funktionieren eigentlich sehr gut um zu "detektieren" ohne zu beeinflussen. Damit könntest du dir vielleicht das raycasten in alle möglichen Ecken sparen. An deiner Stelle würde ich erst mal eine kleine zusammenhängende Bahn aus möglichst wenig Dreiecken basteln und dann nach und nach mehr Hindernisse und komplexere Gebilde einbauen. Auf diese Weise sollte man doch eigentlich ermitteln können woran es hapert und was der beste Weg ist.

[Andre]

Kleines Update: Ich bin wohl irgendwie auf die blöde Idee gekommen, dass man nur eine der beiden CCD-Properties setzen muss.

So klappt es nun:

Code: Alles auswählen

RigidBody->setCcdMotionThreshold(0.00001f);
RigidBody->setCcdSweptSphereRadius(0.2f);

Natürlich bleiben die Werte nicht so. Das kann man sicher irgendwie ausrechnen. Ich weiß nur leider gar nicht genau was der 2. Wert bedeutet.
Kannst du mir das vielleicht noch erklären?

(Also, es funktioniert nun, ich falle nicht mehr durch die Strecke, auch bei 30 facher Gravitation :D )

[Chromanoid]

Eher Halbwissen, da nur überflogen: Der erste Wert triggert CCD für das jew. Objekt, wenn die quadrierte Länge der Bewegung innerhalb eines (Sub)Ticks diesen Wert überschreitet. Der zweite Wert ist der Radius einer Sphäre der bei der "4D"/CCD Analyse benutzt wird um auf Kollisionen mit einem anderen Objekt zu testen. Schau dir sonst lieber mal btConvexConvexAlgorithm::calculateTimeOfImpact an :). Ich hätte gedacht, dass zumindest CcdSweptSphereRadius automatisch gesetzt wird.

[Andre]

Werde mir das Morgen mal anschauen. Im Moment haben wir aber auch schon ein neues Problem gefunden:

Wie man unschwer erkennen kann, steckt das Schiff in der Wand. Das passiert auch nur wenn man wenigstens etwas an Geschwindigkeit drauf hat.

Ein wenig gegoogelt hab ich natürlich, was mich dazu führte mit der setMargin()-Methode des btBvhTriangleMeshShapes den Margin etwas höher zu stellen. (+0.1f)
Leider passiert das immer noch, wenn auch nicht immer. Manchmal kann man sonst wie schnell gegen die Wand rammen und es passiert nicht.

Muss ich für die Strecke vielleicht doch auf ConvexHulls umsteigen? Oder habe ich damit die selben Probleme?

[Chromanoid]

Eigentlich sollte es keine Probleme geben :D Sicher dass deine Kräfte, die durch die "Räder" entstehen, nicht irgendwie seltsam sind? Ich würde es noch mal mit "Magneten" versuchen, aber unrealisitische, die das Schiff einfach nur mit einer gewissen Toleranz auf einen bestimmten Abstand und eine bestimmte Orientierung gegenüber einer Fläche bringen.

[Andre]

Das passiert leider auch wenn ich die "Räder" komplett abschalte...

[Chromanoid]

nutzt du für das schiff auch das drahtgittermodell für die kollisionserkennung?

[Andre]

Nein, in meinem ersten Posting sieht man die Collisionhulls. Es ist ein einfacher Kasten ;)

[Chromanoid]

höchst seltsam. ich bin mit meinen ideen am ende, ich kann mir nur vorstellen, dass es an irgendwelchen einstellungen liegt. ich kann nur empfehlen erst mal einen ganz einfachen track zusammenzubasteln (vielleicht nur aus boxshapes o.Ä.) und dann nach und nach die komplexität zu steigern. ich hab bei mir höchstens mal das überspringen von geometrie bei hohen geschwindigkeiten erlebt, aber ansonsten sind meine kugeln immer schön von der murmelbahn und von sich gegenseitig abgelenkt worden.

[Andre]

Anscheinend ist das Problem des Steckenbleibens nun behoben. Es ist jedenfalls nicht mehr aufgetreten, bis jetzt. Der CcdSweptSphereRadius wird nun immer auf den kleinsten Wert der BoundingBox-0.1f gesetzt. Scheint so zu funktionieren.
Gibt leider noch mehr Probleme, die ich in den Griff bekommen muss bis das alles so klappt wie ich möchte.

Vielen Dank für deine Hilfe! :)