Entity transformation innerhalb einer hierarchie

Einstiegsfragen, Mathematik, Physik, künstliche Intelligenz, Engine Design
Antworten
Andy90
Beiträge: 67
Registriert: 08.10.2023, 13:02

Entity transformation innerhalb einer hierarchie

Beitrag von 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.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2257
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4889
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4263
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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
Establishment
Beiträge: 370
Registriert: 03.10.2003, 12:47

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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
Beiträge: 67
Registriert: 08.10.2023, 13:02

Re: Entity transformation innerhalb einer hierarchie

Beitrag von Andy90 »

Schrompf hat geschrieben: 03.11.2023, 09:42 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.
Chromanoid hat geschrieben: 03.11.2023, 10:01 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
Zudomon hat geschrieben: 02.11.2023, 20:15 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

NytroX hat geschrieben: 03.11.2023, 11:18 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.
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 586
Registriert: 05.07.2003, 11:17

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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?
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Andy90
Beiträge: 67
Registriert: 08.10.2023, 13:02

Re: Entity transformation innerhalb einer hierarchie

Beitrag von Andy90 »

Lord Delvin hat geschrieben: 03.11.2023, 17:28 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.
Krishty hat geschrieben: 03.11.2023, 17:33 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.
Benutzeravatar
TomasRiker
Beiträge: 49
Registriert: 18.07.2011, 11:45
Echter Name: David Scherfgen
Wohnort: Hildesheim

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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 ...
Benutzeravatar
Jonathan
Establishment
Beiträge: 2405
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Entity transformation innerhalb einer hierarchie

Beitrag von 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.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Antworten