Jump to content
Unity Insider Forum

3D Models in einem 2D Spiel


Droidspirit

Recommended Posts

Hallo,

 

ich hänge im Augenblick ein wenig fest und hoffe, ihr könnt mir einen Tipp geben.

 

Ich habe ein 2D Spiel erstellt mit Animationen und allem drum und dran. Jetzt habe ich ein nettes 3D Model gefunden, welches man frei verwenden kann und habe dies in mein Spiel eingebaut. Dieses 3D Model rotiert nun um seine 3 Achsen.

 

Ich habe hier nun aber ein Problem mit den Collidern. Wenn ich 2D Collider nutze, dann funktioniert das auf der 0 Position der Achsen prima. Wenn sich das Objekt dann dreht, drehen sich natürlich auch die Collider und so fehlen mir diese Collider an anderer Stelle (wenn sich das Model in gedrehter Form befindet).

 

Folgende Ideen hatte ich dazu:

 

1. Das Model bekommt Child-GameObjects, welche ich in die entsprechende Position drehe und diese bekommen dann 2D-Collider.

 

2. Ich könnte die Drehung programmatisch abfragen und die Collider der 0-Position entsprechend der Rotation verkleinern bzw. vergrößern. Aber das ist denke ich nicht wirklich im Sinne des Erfinders.

 

3. Man könnte 3D Collider nehmen. Diese funktionieren allerdings nicht in Verbindung mit anderen 2D-Collidern und 2D Rigidbodies.

 

 

Die 1. Idee kommt mir da am plausibelsten vor. Allerdings hat das nicht wirklich funktioniert. Weshalb nicht muß ich heute Abend erst nochmal rausfinden.

 

Wäre super, wenn ihr mir weiterhelfen und einen Tipp könntet, wie das funktionieren kann.

 

Danke und viele Grüße

 

Andre

Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke für Deine Antwort. Die Idee kam mir auch schon. Aber das wäre der letzte Ausweg. Denn das Model soll sich zufällig um 360° über jede Achse drehen. Und bei einer Animation wäre ich da wieder eingeschränkt. Anstatt der Animation könnte ich dann auch einfach eine Achse abklemmen, aber das wäre unschön. Als letzte Möglichkeit würde ich das auch so machen, wenn ich keine Lösung finde.

Link zu diesem Kommentar
Auf anderen Seiten teilen

1. Das Model bekommt Child-GameObjects, welche ich in die entsprechende Position drehe und diese bekommen dann 2D-Collider.

 

Fast so würde ich es machen - aber anders herum: Ich würde die 2D-Repräsentation einschließlich 2D-Collidern, die das 3D-Objekt so ungefähr "umfassen" als "Wurzel" nehmen, und dann darunter das 3D-Objekt quasi als "View" darauf hängen. So kannst du es dann beliebig rotieren, wie du es brauchst. 2D-Rotationen könntest du direkt an der Wurzel vornehmen - das 3D Objekt müsste dann automatisch korrekt mitrotieren. Aber Rotationen um die 3D-Achsen (also Rotationen, die nicht um die Z-Achse herum laufen) würde ich nur auf das 3D-Objekt anwenden, nicht auf die 2D-Repräsentation (weil's sonst unnötig kompliziert wird).

 

Dieses "Pattern" würde ich übrigens generell empfehlen: Ein "Wurzel-GO" mit allen wichtigen Komponenten, ggf. Collidern, aber ohne "sonstiges Zeugs", und darunter dann die "View", also Sprites oder 3D-Modelle. Gerade in 2D-Spielen ist das vielleicht manchmal etwas Overkill, weil man Sprites relativ leicht austauschen kann. Aber speziell in 3D-Spielen ist es super-nervig, wenn du beispielsweise den Char austauschen möchtest, und dann hast du auf der Wurzel vom Modell die ganzen Komponenten, die du dann erst umständlich auf ein anderes Modell übertragen musst.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke für Deine Tipps. Ich konnte das Problem gestern Abend auch schon lösen.

 

Ich habe ein Parent-GameObject, dass das 3D Model darstellt sowie das alle Skripte beinhaltet, die dieses Object ausmachen. Darunter habe ich als Children nun mehrere GO´s, die ich an dem 3D Model über die Achsen ausrichte und die jeweils einen Collider haben. Alle Children haben ein ColliderSkript, welches beim OnTriggerEnter eine Funktion vom Parent aufruft.

 

Mein Fehler war gestern, dass ich diesen Children-GO´s keinen Rigidbody mitgegeben habe. Da konnte dann auch nichts kollidieren.

 

Hier habe ich ja ein Model genommen, was nicht von mir ist. Wenn ich die Grafiken für eine Spielfigur selber mache, dann unterteile ich das auch in unterschiedliche GO´s, z.B. bei einem Vogel würde es das ParentGO geben, welches den Körper darstellt. Hier würde die komplette Logik des Vogels drin stecken mit sämtlichen Skripten, usw. Als Children-GO´s gibt es dann die Flügel, (evtl) den Kopf bzw. Schnabel, die Beine ...und natürlich die Waffen ;-)

Jedes GO hätte dann seinen eigenen Collider und würde die Skripte vom Parent aufrufen.

 

Hast Du das so ungefähr gemeint?

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hast Du das so ungefähr gemeint?

 

Fast ;-) ... ich würde bei deinem Beispiel auch den "Körper" des Vogels als Kind des Hauptobjektes haben.

 

Also generell: Am "Wurzelobjekt" nur Sachen, die ich niemals austauschen würde. Theoretisch könntest du bei einem Mesh natürlich einfach nur im Mesh Filter ein anderes Mesh reinziehen, d.h. das wäre durchaus auch eine Möglichkeit. Aber ich finde es halt aufgeräumter, wenn die Komponenten für die Spiellogik (also auch Collider) am Objekt selbst sind, und das Modell (welches ja auch aus mehreren Objekten bestehen kann) dann eine Ebene tiefer, so dass ich das leicht austauschen kann.

 

Wenn's dann eines Tages endlich mal Nested Prefabs gibt, kann man das dann noch deutlich eleganter lösen als jetzt ... aber mit der Struktur ist man darauf zumindest schonmal gut vorbereitet (und ich find's auch ohne Nested Prefabs so am praktischsten).

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...