Physic-Collider adjust to mesh

[JirkaDellOro]

@Dev-MarkoF
Bei Physics.start werden ja die Collider angepasst entsprechend der Knotentransformationen. Spricht etwas dagegen, auch eine Möglichkeit anzubieten, die Collider auch auf die Mesh-Transformationen anzupassen? Die Mesh-Komponente bringt eine Pivot-Matrix mit, welche das Mesh gegenüber dem Knoten transformiert und speichert auch beim Rendern die Welt-Matrix des Meshes mit.

PS: ich fange an, ein paar Namen und Kommentare in Physics zu ändern und werde versuchen, deine Tutorials entsprechend zu aktualisieren.

[Dev-MarkoF]

Ich denke, dass eigentlich nichts dagegen spricht, außer das allgemeine Verständnis.
Oder verstehe ich das falsch? Du möchtest eine Korrelation zwischen Mesh und Physik, das erscheint mir ungünstig.

Für Automatismen muss sich immer an einem Basiswert orientiert werden, sonst muss das manuell gemacht werden.
Der Basiswert ist konsistent über alle Game Engines die mir bekannt sind und logischen Modelle, die Transform Komponente.
Auf die beziehen sich alle, normalerweise auch das Mesh und sämtliche andere Komponenten z.B. Audiokomponente für Radius/Abfall.

Pivots sind dann nur für manuelle Verschiebungen gedacht, wenn man das unbedingt möchte.
Deshalb hat ja auch der Rigidbody einen Pivot, wenn man den von Hand anders schieben möchte, als die Transform es vorgibt.

Realistisch gesehen ist das aber murks. An sich sollten Transform, RB und Mesh so identisch wie möglich sein und mein Automatismus gleicht halt Transform und RB an. Und wenn ich nichts übersehen hab gleicht ja das Mesh sich auch an die Transform an.
Somit ist doch schon das gewollte Ergebnis erreicht?
Pivots von Mesh und Physics sind nur um Gegebenheiten anzupassen, die sich nicht automatisch übereinbringen lassen.

PS: Ändere alles ruhig wie du möchtest, ich hab da keine Stakes drin und halte einiges für nicht optimal, aber optimal ist es eh nie.

[JirkaDellOro]

Deshalb hat ja auch der Rigidbody einen Pivot

Kann man also einen Pivotpunkt außerhalb des Colliders definieren? Würde sich der Collider dann bei Stoß um diesen exzentrischen Punkt drehen?

[Dev-MarkoF]

Iirc, ja.
Wenn TransformScale(1,1,1) und Rb.mtxPivot.Scale (2,2,2), wird der Collider verschoben erstellt. Ob die Berechnungen dahinter in Oimo korrekt sind und korrekt zurückgegeben werden, bei Translationen, kann ich gerade nicht sagen. Aber das dürfte bei einem einzigen Collider nicht relevant sein.

Physik überschreibt ja die Transform, also müsste die Pivot Verschiebung keinen Einfluss auf das Mesh haben, wenn das Mesh sich am Transform orientiert.

Also alle Physik Berechnungen werden dann mit (2,2,2) ausgeführt und das Mesh bleibt aber bei (1,1,1). Müsste für Translation/Rotation ebenso sein.

[JirkaDellOro]

Sehe ich das richtig, dass die Pivot-Matrix der ComponentRigidbody nur für die Erzeugung des OIMO-Bodys herangezogen wird, aber beim überschreiben der Knotentransformation nicht berücksichtigt wird? Dass also man zwar einen gegenüber dem Knoten transformierten Collider erzeugen kann, der Knoten dann aber im nächsten Moment von der Physik die Collidertransformation erhält und damit die Transformation zwischen beiden aufgehoben wird?

[Dev-MarkoF]

Bin ich gerade unsicher, muss ich nachschauen, aber ich vermute nicht.
Ein Rigidbody hat keine Transformation für sich selbst. Wenn der Collider mit dem Pivot initialisiert wird und die Physik auf diesen Collider reagiert, dann dürfte der Pivot des Colliders automatisch der Pivot des RB sein. Und der RB überschreibt mit seinen Ergebnissen die Transformation.
In einem System bei dem ein RB nur einen Collider hat.

[JirkaDellOro]

Hängt auch mit Issue #258 zusammen

Ich denke, ich habe das System nun soweit verstanden, dass ich einen sinnvollen und etwas größeren Verbesserungsvorschlag machen kann. Gerne möchte ich der Pivotmatrix der ComponentRigidbody mehr Bedeutung geben, sodass Rigidbodies auch exzentrisch zu ihrem Node liegen können und das System flexibler gestalten, auch in Hinblick auf die Editor-Einbindung. Ich habe da etwas skizziert:

RigidBodies.pdf

Knackpunkt ist dabei, wann ein Rigidbody erzeugt wird, derzeit ja immer automatisch, wenn die ComponentRigidbody erzeugt wird. Plausibel erscheint mir aber, dass er erst erzeugt wird, wenn er zum ersten Mal gebraucht wird, dann sollte auch alles andere drumherum bekannt sein. Also in Render. Oder man hat wieder eine Physics.start-Funktion, die den angegebenen Ast durchläuft und die Rigidbodies entsprechend ihrer Pivots und weiterer Flags anpasst.

@Dev-MarkoF schau mal kurz drüber bitte und teile mir mit, ob es Bedenkliches gibt.

[Dev-MarkoF]

👍 Das ist in etwa das System, was ich auch für Joints benutze und angedacht habe.
Für RB's hätte ich mir das im Nachhinein auch angedacht, dass die FudgeComponent nur eine Fassade ist und die Kreation erst zu Beginn stattfindet. Das wäre speziell dann nötig geworden, wenn RB und Collider in zwei Komponenten aufgespalten werden sollten, was für Konkave Collider nötig wäre.

Probleme sehe ich da keine es gibt nur 2 Dinge zu beachten, zur Laufzeit kann eine neue RBCmp hinzugefügt werden, man kann nicht direkt im 1. Frame Bodies generieren, sondern muss theoretisch jedes Frame durchgehen, ob es "leere" RBCmp gibt, die keinen Oimo RB haben und entsprechend einen generieren.

Hat der Editor bereits eine GameLoop? Das muss für richtige Tests von Physik gegeben sein, dass es eine start-/pausierbare Loop gibt.

[JirkaDellOro]

Danke für die gehaltvolle Antwort. Dam entnehme ich, dass man bei OIMO jederzeit Rigidbodies hinzufügen und wegnehmen kann. Ist das korrekt? Nächste Frage: kann man bei OIMO Rigidbodies "deaktivieren", oder müsste man dies über herausnehmen/hinzufügen machen?

Physiktest im Editor: eigentlich will ich gar nicht, dass die Physik im Editor läuft und würde nach Wegen suchen, sie abzustellen, wenn es so wäre. Lediglich die Bodies und Hinges müssen dargestellt werden, das Testing findet dann außerhalb des Editors statt. Derzeit arbeiten wir in Prima schon mit dem Editor und ich verfahre so, dass Editor und Browser parallel laufen, ich im Editor also etwas ändere und im Browser gleich den Test sehe. Das klappt gut.

[Dev-MarkoF]

Richtig, zur Laufzeit hinzufügen ist möglich, ist bei jeder Physik Engine möglich.
Veränderungen des Colliders in allen Formen ist nur teilweise fehlerhaft -> Realität nicht möglich, da Festkörper keine Veränderung haben Bsp. Stein, verändert seine Form nicht, entweder er existiert, oder er bricht, aber dadurch entstehen ja dann z.B. 2 eigenständige Festkörper.
Also Collideranpassung zur Laufzeit ist schon umgesetzt und funktioniert auch ganz gut, aber es kann zu Berechnungsfehlern kommen, bzw. kurzen visuellen Fehlern, wenn z.B. eine Sphäre zur Laufzeit "wächst".
Aber neue Bodies, problemlos.

Nein, deaktivierbar sind sie nicht, vermutlich auch weil zu sehr an Realphysik gedacht wurde, sie müssen aus dem System World entfernt und wieder hinzugefügt werden.
Müsste in z.B. Unity getestet werden, ich vermute, aber dass die Deaktivierung dort auch zur Folge hat, dass der Body in der "Simulation" gelöscht wird und bei erneuter Aktivierung, z.B. Kräfte wieder 0 sind, außer die Werte werden natürlich zwischengespeichert und dem Body bei Reaktivierung wieder zugeschrieben.

Interessante Herangehensweise, hatte gedacht, dass Fudge eher klassisch wie eine Game Engine einen inEditor Loop hat.
Wenn das nicht so ist, dann wird die Physik auch nicht simuliert, der DebugDraw sollte trotzdem angezeigt werden, da das Rendering vorhanden ist, nur es gibt halt kein Update durch Simulate(). Du hast Simulate() und DebugDraw() von einander getrennt, sofern also DebugDraw() irgendwo aufgerufen wird, dürfte das vorhanden sein.

Wenn so viel Browseranteil angedacht ist, wäre es nicht denkbar, den Editor bevor er zu komplex wird, was er vlt. schon ist, direkt als volle Webanwendung anzubieten/aufzubauen?
Dann sind keine Anpassungen pro Plattform nötig, e.g. Mac/Linux und beim Aufruf der Website ist die neueste Version automatisch vorhanden. Was sind die Vorteile einer Desktopanwendung, wenn das Ergebnis wieder im Browser angewendet wird?

[JirkaDellOro]

Direkter Systemzugriff und Lauffähigkeit auch ohne Internetverbindung