spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo zusammen!

Ich suche derzeit nach einem guten Konzept, mit welchem ich Haftreibung mit meiner Physik-Engine realisieren kann. Hab ich erst mal Haftreibung, kann ich leicht auch Klebstoffe und ähnliches für Modelle verwenden (erhöhte einmalige Haftreibung!).

Mein bisheriger Ansatz ist folgender. Es wird grundsätzlich unterschieden zwischen Objekte im Ruhezustand und aktiven Objekten. In Ruhe werden all jene Objekte versetzt, welche die selbe Position wie im vorherigen Frame haben (natürlich auch Rotation) und auf welche keine externen Kräfte (außer die Gravitation) wirken. Gleichzeitig werden für alle Objekte welche dieses ruhende Objekt berühren, Positions-Constraints eingeführt, welche den Abstand der Objekte und deren Ausrichtung zueinander "konstant" machen. All diese Constraints haben ein "Kraftlimit". Wirkt eine auseinandertreibende Kraft auf diese Constraint, welche größer ist, als das Limit, löst sich das Constraint auf, und beide Objekte verhalten sich unabhängig von einander (Die auseinandertreibende Komponente einer Kraft ist die Projektion selbiger auf den Verbindungsconstraint). Haftreibung könnte mit diesem Prinzip relativ einfach realisiert werden, indem man das Kraftlimit abhängig von der Art der Kollision mit dem Nachbarobjekt (Vertex-Face, Edge-Face oder Face-Face, ua) verschieden hoch setzt. "Klebstoff" wäre da dann einfach nur ein hohes Kraftlimit, welches bei der Initialisierung gesetzt wird, und danach nicht mehr (sind die Teile mal nicht mehr zusammengeklebt!).

Nun habe ich einige Fragen:
1) Glaubt ihr, diese System funktioniert?
2) Wenn ja, schnell genug? Hab ich was übersehen?
3) Ich hab mal so einen Artikel über Constraints gelesen, welche die Freiheitsgrade eines Objektes beeinträchtigen. Nun war ich da leider zu dumm, um diesen Artikel zu speichern und ich find das Teil nicht mehr. (auch nichts ähnliches) Weiß zufällig jemand wo man da soetwas findet? (hab 2h gegoogelt...)
4) Habt ihr einen besseren Ansatz?

Danke inzwischen!

Zitat von »"rewb0rn"«

Zitat von »"Black-Panther"«

In Ruhe werden all jene Objekte versetzt, welche die selbe Position wie im vorherigen Frame haben (natürlich auch Rotation) und auf welche keine externen Kräfte (außer die Gravitation) wirken.

Gibt es denn in deiner Engine wirklich Objekte, die in den Ruhezustand kommen? Ich habe bei ode die Beobachtung gemacht, dass die Objekte sich immer minimal bewegen.

Minimale Bewegung gilt als Ruhe

Zitat von »"rewb0rn"«

2) Ich kann mir vorstellen, dass es bei vielen sich berührenden Objekten zu Problemen kommt:

Zitat

Gleichzeitig werden für alle Objekte welche dieses ruhende Objekt berühren, Positions-Constraints eingeführt, welche den Abstand der Objekte und deren Ausrichtung zueinander "konstant" machen.

Klingt für mich nach exponentiellen Aufwand.

Kommt drauf an, wie groß die verwendeten Objekte sind. Wenn es nicht allzugroße Größenunterschiede gibt, dürfte der Aufwand sich in Grenzen halten. Das ganze ist natürlich noch ausgibig zu testen. Nur will ich nicht etwas implementieren, was bei näherer Betrachtung sowieso nur zum Scheitern verurteilt wäre. Also, wenn man die Levels so gestaltet, dass sie der Physikengine entgegenkommen, dann müsste das ganze relativ überschaubar bleiben. (Außerdem kann man auch große Systeme von Constraints mit guten Algos relativ schnell lösen!)

Zitat von »"rewb0rn"«

Mal was anderes: Alles was du bis jetzt über deine Physik-Engine erzählt hast, klingt sehr vielversprechend. Gäbe es die Möglichkeit, die für unser Projekt einzusetzen? (ohne das jetzt fix machen zu wollen, ist nat. abhängig vom Aufwand, der durch den Umstieg entsteht, Netzwerkfähigkeit, etc.)

Vorweg: Die Engine ist noch nicht einsatzfähig Es wird alles erst. Ich implementier gerade das Gesamtkonzept (also alle Klassendefinitionen und deklarationen).
Zur Frage: Die Physikengine (OmegaPhysics) arbeitet mit der Hauptengine (OmegaEngine) zusammen. Bedeutet, dass eine Abhängigkeit besteht (wobei jene sich ziemlich in Grenzen hält.) Es ist nur so, dass ich zB nicht alle Mathe-Klassen (Vektor, Quaternion, Matrix, usw) neu schreiben bzw. kopieren wollte, außerdem kann ich so bei der Engine selbst Methoden implementieren, die alles enorm erleichtern (zB beim Model eine Methode typo: RegisterAllObjects(), womit alle Objekte die zum Modell gehören, bei der Physikengine registriert werden). Also denk ich mal, dass man mit vertretbarem Aufwand, das ganze unabhängig machen könnte...
Zur Netzwerkfähigkeit. Ich arbeite auch an OmegaNetwork, welche sich um die Übertragung selbst kümmern wird. OmegaPhysics wird zwar unabhängig von jenem Layer konzipiert, soll aber auf jeden Fall netzwerkfähig sein (Diesbezüglich muss ich mich aber noch einlesen, oder weißt du bereits, was da alles notwendig ist, und welche Ansätze gut funktionierten? --> Gespräch?)
Bezüglich Lizens: Das wäre kein Problem, mir ist eine eventuelle namentliche Erwähnung genug

Edit: Wo man sich gut in Constraints einlesen kann, weiß keiner?