Joint-Idee

[JirkaDellOro]

Es wäre schön, wenn man auch die Joints im Editor bearbeiten kann. Das wird recht kompliziert fürchte ich, auch wenn ich noch nicht wirklich reingeschaut habe. Allein die Tatsache, dass eine Komponente eines Knotens zwei Komponenten anderer Knoten miteinander verbindet, die Beziehung der Knoten untereinander dabei aber irrelevant ist, macht das Ganze schon recht unintuitiv. Die De-/Serialisierung wird komplex, da die Verknüpfungen über IDs im Nachhinein rekreiert werden müssen, dies aber mit dem aktuellen System nicht automatisch passiert, denn hierfür müsste jede Instanz einer Komponente als eigene Ressource registriert werden. Es müsste also noch ein Parallelsystem aufgezogen werden. Weiterhin wird es haarig sinnvolle UserInterfaces dafür zu schaffen, da die Nutzer per Maus irgendwie die Komponenten zusammenziehen müssen.

Daher folgende Überlegung:

• Eine Joint-Komponente verknüpft jeweils zwei Kindknoten eines Elternknoten (bzw. deren Rigidbody-Komponenten)
• Das bedeutet, die Kinder haben die Rigidbodies, der Elternknoten den Joint.
• Der Joint ist kein Singleton, der Elternknoten kann also mehrere Kinder miteinander verknüpfen (ist jetzt schon so)
• Die Verknüpfung wird über die Namen der Kindknoten hergestellt
• Es liegt also in der Verantwortung der Nutzer, hier sinnvolle Namen zu vergeben, sie ersetzen in dem Kontext zusätzliche IDs. Da es nur über eine Hierarchieebene geht, müssen lediglich die Namen unter den Kindern eindeutig sein.
• So kann man ein solches Eltern-Joint-Kind-Konstrukt leicht als Graph-Ressource registrieren und davon beliebig viele Instanzen schaffen (analog Prefab)
• Weitere IDs müssen nicht exponiert werden
• Im UserInterface
  • kann die Joiint-Komponente leicht per Select-Box die Liste von Kindern zur Auswahl für die Verbindung präsentieren
  • kann man direkt aus dem Hierarchy-View per Drag&Drop die Kindknoten auf die Komponente des Elternknoten ziehen

@Dev-MarkoF : Liest sich für mich attraktiv, spricht etwas dagegen? Ich werde mal auf devJirka mit der Refaktorierung beginnen, wenn mich niemand aufhält...

[JirkaDellOro]

@Dev-MarkoF ich glaube mich zu erinnern, irgendwo in deinem Code deinen Vorschlag gelesen zu haben, dass eines der Teile des Joints parent, das andere dessen child sein soll. Tatsächlich finde ich das auch besser als oben vorgeschlagen, da der Parent schon dadurch identifiziert ist, dass die Joint-Componente dranhängt und dann nur noch das Child ausgewählt werden muss. Somit muss also nur ein Knoten per Name identifiziert werden. Das ist simpler und noch intuitiver.

[JirkaDellOro]

Ist jetzt so implementiert in devJirka. Welding und Universal müssen noch angepasst werden auf den Editor.

[Dev-MarkoF]

War im Urlaub, daher habe ich niemanden aufhalten können.

Ich denke du bist im Refaktorieren so drin, dass ich mich da eher raushalte und nur drüber schaue.

Intuitiv ist es genau, wenn ein Objekt Parent und das andere Child ist, den Vorschlag davor mit Parent (Joint) -> Child + Child, hätte ich definitiv abgelehnt, da so unnötig 3 Körper beteiligt sind.

Ich halte mich da weitestgehend an reale Vorgänge, da schweiße ich auch Körper A an B, meist ist ein Objekt davon klar als Parent erkennbar, z.B. freischwingendes Seil (Child) -> Decke (Haken Joint -> Parent)

So war es auch vorher umgesetzt, ich habe nur die theoretische Wahl gelassen, den Joint an irgendwas anderes anzuhängen, falls gewünscht, aber die Beispiele haben den Standard Fall, Joint verbindet A + B, Joint-Komponente angehangen an A, schon abgebildet.

Die Verknüpfung wird über die Namen der Kindknoten hergestellt Es liegt also in der Verantwortung der Nutzer, hier sinnvolle Namen zu vergeben, sie ersetzen in dem Kontext zusätzliche IDs. Da es nur über eine Hierarchieebene geht, müssen lediglich die Namen unter den Kindern eindeutig sein. So kann man ein solches Eltern-Joint-Kind-Konstrukt leicht als Graph-Ressource registrieren und davon beliebig viele Instanzen schaffen (analog Prefab) Weitere IDs müssen nicht exponiert werden

Mit Benennungen anstatt ID's zu arbeiten halte ich für absolut fahrlässig und wieder ein theoretisches Konstrukt, was nicht in die Realität der Physik passt und aus gutem Grund nirgends so verwendet wird. In der Realität kann ich zwei Baugleiche Objekte haben, benenne sie zwar beide "Kiste" aber aus gutem Grund schreibt man dann "1" oder etwas dazu. Wenn ich dem Nutzer die Freiheit gebe, das selbst zu tun anstatt die Kiste automatisch zu markieren, wird das immer wieder zu Fehlern führen beim Öffnen von Projekten etc. bei denen ein Objekt doppelt benannt ist und schon gibt es Probleme, die der Nutzer vlt. nicht zu lösen weiß. Namen > ID's nur im absoluten Notfall, die meisten Systeme verwenden schließlich ID's und verhindern gleichzeitig noch identische Benennungen. Im Editor kann man die Benennungen natürlich verhindern, oder automatisch mit "(1)" etc. ergänzen, aber FUDGE sollte auch über Code funktionieren, ganz ohne Editor und ID's wurden bisher schon gut automatisch gehandhabt.

[JirkaDellOro]

Intern arbeitet alles wie zuvor mit den OIMO-Ids. Es geht nur um die Bedienung des Editors und die Speicherung des Graphen.

Die Id-Vergabe von OIMO ist nur eine fortlaufende Nummer und es kann nicht garantiert werden, das ein Rigidbody bei jedem Programmlauf die gleiche Id erhält. Daher ist es nicht sinnvoll, die Id abzuspeichern. Die aktuelle Implementation warnt, wenn der Child-Name bei der Verknüpfung nicht eindeutig ist.

[Dev-MarkoF]

Ja Oimo macht seinen eigenen Vorgang, ich habe der ComponentRigidbody daher feste ID's vergeben, die bei Speicherung/Laden für die Joint Verbindung genutzt werden, davon ist Oimo nicht betroffen, aber garantiert eine einzigartige Verbindung von korrekten ComponentRigidbody.

Mit einer Warnung bei Namen im Editor, ist es wenn ohne Editor gecoded wird hinfällig, oder erst zur Laufzeit. Eine automatische ID Vergabe in Fudge verringert die Points of Failure, versteckt aber natürlich Vorgänge, bzw. vereinfacht sie im Hintergrund.

Mit Namen wird dem Nutzer natürlich besser klar gemacht, wie die Vorgänge sind. Das ist das typische Abwägen von Standards, Sicherheit versus Lesbarkeit und Sichtbarkeit.

[JirkaDellOro]

Ich glaube, dass hatte ich vor Längerem so implementiert und es kann geschlossen werden.