Entity transformation innerhalb einer hierarchie

[Andy90]

Hallo, ich bin gerade dabei für meine Entitys eine hierarchie zu entwickeln. Soweit so gut, es funktioniert auch alles. Nun ist aber meine frage, welche Transformationen übernehme ich von dem parent entity ?

Aktuell ist es so, dass ich sowohl Transformation, als auch Rotation als auch Scale relativ vom Parent Entity anpasse. Wobei ich mir bei der Rotation nicht sicher bin, ob ich diese auch übernehmen soll.

Derzeit ist es so, dass die Location relativ zu der Rotation und der Location vom Parent Element angepasst wird. Da würde es sich ja anbieten, die eigentlich Rotation im Modelspace zu belassen, also nicht relativ zu berechnen.

[Zudomon]

Ich würde sagen, dass alles übernommen wird und du aber die Möglichkeit bietest, bei einem Entity Flags zu setzen, was dann nicht übernommen wird.

[Schrompf]

Was brauchst Du denn? Ich bin lange Jahre ohne jede Skalierung ausgekommen, die macht hintenraus dann auch bissl Ärger beim Shaden oder wenn Du erweiterte Techniken wie Global Illumination anwenden willst. Aber wenn Du diese Parent-Child-Relations benutzt, um komplexe Objekte zusammen zu stecken, würde ich alles mitnehmen, damit irgendein aufgeflanschtes Moos auf nem Stein mit dem Stein auch mitskaliert wird.

[Chromanoid]

Wie steckst Du denn die Entities zusammen? Hast Du einen Third-Party-Editor dafür? Vielleicht kannst Du Dich an dem orientieren? Ich habe mir früher immer Export-Plugins für 3D-Modellierungs-Software gebaut, um das nicht in irgendeiner XML-Datei oder im Code per try and error hinfummeln zu müssen.

[NytroX]

Normalerweise nimmt man alles mit - man gibt ja die Positionierung und Rotation normalerweise basierend auf dem Parent an.
Also ein Auto mit angeflanschtem Maschinengewehr - da dreht sich die MG ja mit der Fahrtrichtung des Autos mit.

Ausnahmen sollten aber vielleicht möglich sein.
Beispiel wäre hier ein Panzer, dessen Fahrtrichtung sich zwar dreht, aber der Turm bleibt immer in Blickrichtung ausgerichtet.
Dann müsste man die Orientierung des Turms einzeln berechnen, aber die Position und Skalierung hängt am Parent (also dem Panzer).

[Andy90]

Was brauchst Du denn? Ich bin lange Jahre ohne jede Skalierung ausgekommen, die macht hintenraus dann auch bissl Ärger beim Shaden oder wenn Du erweiterte Techniken wie Global Illumination anwenden willst. Aber wenn Du diese Parent-Child-Relations benutzt, um komplexe Objekte zusammen zu stecken, würde ich alles mitnehmen, damit irgendein aufgeflanschtes Moos auf nem Stein mit dem Stein auch mitskaliert wird.

Ja, aktuell nutze ich alles, was auch gut funktioniert soweit.

Wie steckst Du denn die Entities zusammen? Hast Du einen Third-Party-Editor dafür?

Nein, aktuell wird noch alles im Code selbst zusammen gesteckt. Also man kann ein Entity entweder in einen Layer der Szene selbst hinzufügen oder eben als Child einem anderen Adden

Ich würde sagen, dass alles übernommen wird und du aber die Möglichkeit bietest, bei einem Entity Flags zu setzen, was dann nicht übernommen wird.

Diese idee finde ich auch gut, ein sehr interessanter Ansatz

Normalerweise nimmt man alles mit - man gibt ja die Positionierung und Rotation normalerweise basierend auf dem Parent an.
Also ein Auto mit angeflanschtem Maschinengewehr - da dreht sich die MG ja mit der Fahrtrichtung des Autos mit.

Ja genau, aktuell wird alles übernommen aber zusätzlich wird für die Position noch die rotation des parent Entity mit einbezogen.

[Lord Delvin]

Ich glaube nicht, dass es eine gute Idee ist, alles mit einer Relation zu erschlagen. Wenn man sich die Diskusison anschaut würde ich sagen Konsens ist alles zu erben. Der Panzerturm würde aber über eine zweite Relation an den Panzer gebunden werden. Hast du für deine Entities eine Vererbungshierarchie oder machst du alles mit flachen structs?

[Krishty]

Sprites sind übrigens auch eine häufige Ausnahme. Die schmeißen die Rotation des Parents weg, um sich zur Kamera zu drehen; behalten aber üblicherweise die Position und Skalierung ihres Elters bei.

[Andy90]

Ich glaube nicht, dass es eine gute Idee ist, alles mit einer Relation zu erschlagen. Wenn man sich die Diskusison anschaut würde ich sagen Konsens ist alles zu erben. Der Panzerturm würde aber über eine zweite Relation an den Panzer gebunden werden. Hast du für deine Entities eine Vererbungshierarchie oder machst du alles mit flachen structs?

Es ist aktuell so, dass du praktisch unendlich vererben kannst. Also jedes Entity kann eine Collection von Entitys aufnehmen.

Sprites sind übrigens auch eine häufige Ausnahme. Die schmeißen die Rotation des Parents weg, um sich zur Kamera zu drehen; behalten aber üblicherweise die Position und Skalierung ihres Elters bei.

Ich denke das mit der flag ist eine gute idee, so kann man die rotation beibehalten, oder sie verwerfen. Das macht das ganze etwas flexibler.

[TomasRiker]

Wobei das Beispiel mit dem Panzer und dem Turm ein bisschen kurz greift: Wenn sich der Panzer neigt (weil er auf eine Steigung fährt), dann neigt sich auch der Turm mit. In der Praxis würde man da (und in vielen ähnlichen Fällen) eher keine Transformationshierarchie einsetzen, sondern einen physikalischen Joint, der nur die Rotation um eine Achse erlaubt ...

[Jonathan]

Klingt mir ehrlich gesagt alles irgendwie etwas überentwickelt. Wann und wofür genau brauchst du das?

Also als Beispiel: Ich hab Entities, die genau ein Modell haben und dafür eine Transformation haben. Im Landvogt brauchte ich mal Icons die als 3D Modell über den Häusern schweben - da gab es dann ein Component Objekt das explizit ein zweites Modell Objekt hatte und explizit die Transformation vom Parent kopiert hat. Da dann aber noch direkt eine nette prozedurale Animation draufgepackt hat, damit es ein bisschen animiert war. Sowas hätte man als nette Entity-Transformations-Hierarchie bauen können, dieser kleine Hack ging aber viel schneller.

Wenn du noch nicht weißt, wie Transformationen übernommen werden sollen, dann hast du glaube ich noch gar kein Problem was du damit lösen musst, du willst einfach nur mal coolen Code schreiben, weil cooler Code eben cool ist. Aber du kommst vermutlich schneller ans Ziel, wenn du einfach die Probleme löst, die du hast. Ich habe mir folgendes angewöhnt: Wenn ich ein Problem mit einem einfachen "Hack" lösen kann und mir spontan keine Situation einfällt, wo eine allgemeinere Lösung mehrfach verwendet würde (und die Schwelle ist hier echt "2 mal oder mehr"), dann wird der Hack eingebaut. Wenn ich 3 mal oder so den selben Hack brauche, baue ich alles um so dass ich eine allgemeine Lösung hab, die "sauber" ist.

Die Realität ist wohl einfach, dass Software sich immer verändert und man am Anfang niemals weiß, welcher Abstraktionsgrad der richtige ist. Aber das ganze Geplapper, dass OOP ja so toll ist, weil man alles damit mehrfach verwenden kann und dass man denkt, jede Engine müsste so allgemein wie Unity sein fürht IMO dazu, dass viel Zeit in eine Codebasis gesteckt wird, die dann mit Glück für 1 oder 2 echte Spiele verwendet wird und das war es dann.