Jump to content
Unity Insider Forum

Boxcollider2D und Rays


MichaelH

Recommended Posts

@MichaelH Ich würde darauf tippen, dass dein Transform.localScale (also der "Scale"-Wert, den man im Inspektor einstellen kann) nicht gleich 1,1,1 ist.

@chrische5 Ich habe einige Zeit in den letzten Jahren damit verbracht, 2D Character Controller richtig unter die Füße zu bekommen... und am Ende habe ich auch Raycasts benutzt. Corgi Engine macht das auch so. Ich kann dir oft nicht einmal richtig sagen, wo mit allen anderen Varianten das Problem ist, aber irgendwie läuft das schon darauf hinaus.

Link zu diesem Kommentar
Auf anderen Seiten teilen

@Sacha Stimmt, er steht auf 0.27,0.27,1.0. Einfach damit malnehmen ?

Ich probiers mal.

@chrische5 Die Rays sind dazu da um einen Zustand zu testen -> isOnGround.

Damit weiss ich ob ich springen oder andere Aktionen  ausführen kann !

Das Gleiche gillt auch für andere Rays. zB. -> isHeadBlocked.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 18 Minuten schrieb MichaelH:

Stimmt, er steht auf 0.27,0.27,1.0. Einfach damit malnehmen ?

Ich würde eher dazu raten, zu vermeiden, Objekte zu skalieren, die das nicht unbedingt brauchen. Je mehr 1,1,1 du hast, desto weniger potentielle Kopfschmerzen gibt's.

vor 8 Minuten schrieb MichaelH:

Wie editier ich eigentlich einen Beitrag ? Hab auf die Schnelle nichts gefunden.

Seit dem frischen Forenupdate geht das mit einem Klick auf die drei Punkte oben rechts in deinem Beitrag.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb Sascha:

@chrische5 Ich habe einige Zeit in den letzten Jahren damit verbracht, 2D Character Controller richtig unter die Füße zu bekommen... und am Ende habe ich auch Raycasts benutzt. Corgi Engine macht das auch so. Ich kann dir oft nicht einmal richtig sagen, wo mit allen anderen Varianten das Problem ist, aber irgendwie läuft das schon darauf hinaus.

 

Hallo

 

Wie muss ich mir das konkret vorstellen? In jedem Update() gibt es einen raycast und der ermittelt, ob man grounded ist? 

 

Christoph

Link zu diesem Kommentar
Auf anderen Seiten teilen

das kann man machen, aber auf lange Sicht will man - so lange es bei mir auch gedauert hat, das einzusehen - einfach vom Rigidbody weg. Ich hab mir inzwischen einen 2D-Character Controller geschrieben, der komplett die Kollionsabfrage mit der Umgebung über Raycasts macht. Also z.B. 5 nach oben, 5 nach unten, 7 jeweils links und rechts. Natürlich alles einstellbar. Und wie gesagt, Corgi macht das genauso. Bin zwar kein großer Corgi-Fan weil das Paket will, dass man sonst nichts anderes mehr verwendet... ich mag eher Lightweight-Pakete, die man dann beliebig mit anderen Lightweight-Paketen kombinieren kann statt Komplettlösungen... aber was soll ich sagen, Plattforming läuft echt gut auf die Art.

Link zu diesem Kommentar
Auf anderen Seiten teilen

@Sascha Da ich vor Jahren mal SpriterPro gekauft habe stehen mir für das Projekt Sprites und Animationen frei zur Verfügung.

Die Platformprites und auch andere sind für Tilemaps auf 256*256 Pixel vorgesehen. Die Animationen sind halt größer und ich hab sie deshalb skaliert.

Mit Spriter selbst fehlt mir die Erfahrung um die Animationen entsprechend zu verändern. Es sind ja keine Spritesheets.

Aber danke für den Rat, das ganze dient ja mich in unity einzuarbeiten.

Rays2.png.1a3d3394fc1ef005688dc0c36fe15c91.png

Nochwas, wie man hoffentlich sehen kann sind die Rays leich linksverschoben.

Da muss ich wohl die transform der Childobjekte für die Collider mitverbraten !?!?

Na mal sehen.

@crische5 Ja genau, in der FixedUpdate.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Es gibt Situationen, wo es sehr nervig wird, nicht mit skalierten GameObejcts zu arbeiten. Animationen können da schon drunterfallen. Aber in dem Fall ist die Empfehlung, das Objekt in mehrere Objekte aufzuteilen:

  • Parent: Hat Collider, Physik, Bewegungsscript usw. Ist nicht skaliert.
    • Child: Hat Renderer, Animator usw. Ist bei Bedarf skaliert.

Dann kann die Physik und dein Code gemütlich ohne Skalierung arbeiten, und den sichtbaren Teil der ganzen Sache kannst du dann skalieren wie du möchtest :) Diese Aufteilung würde ich auch Empfehlen, wenn du nichts skalieren musst. Da sind Physik und Bewegungslogik schön von Rendering und Animation getrennt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

"Gehe vorsichtig mit X um, da Performance" ist immer eine... kritische Aussage. Wenn es etwas besseres gibt, das dasselbe macht, sollte man X gar nicht benutzen. Wenn es nichts besseres gibt, sondern höchstens Sachen, die nicht genau dasselbe machen, dann muss man den Preis halt bezahlen, damit das Ergebnis stimmt.

Raycasts kann man ganz schön viele machen, bevor man sich damit in den Fuß schießt. Die Engine hat nicht umsonst eine dicke Beschleunigungsstruktur laufen. Und wie immer gilt: Erst probieren, modular bauen und sich dann erst um Performance Sorgen machen, wenn's Probleme gibt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 14 Minuten schrieb Sascha:

Es gibt Situationen, wo es sehr nervig wird, nicht mit skalierten GameObejcts zu arbeiten. Animationen können da schon drunterfallen. Aber in dem Fall ist die Empfehlung, das Objekt in mehrere Objekte aufzuteilen:

  • Parent: Hat Collider, Physik, Bewegungsscript usw. Ist nicht skaliert.
    • Child: Hat Renderer, Animator usw. Ist bei Bedarf skaliert.

Dann kann die Physik und dein Code gemütlich ohne Skalierung arbeiten, und den sichtbaren Teil der ganzen Sache kannst du dann skalieren wie du möchtest :) Diese Aufteilung würde ich auch Empfehlen, wenn du nichts skalieren musst. Da sind Physik und Bewegungslogik schön von Rendering und Animation getrennt.

Das muss ich erstmal in Ruhe verarbeiten. Ich will mein altes Hirn heute auch nicht mehr überbelasten.😩🙂

Link zu diesem Kommentar
Auf anderen Seiten teilen

Nachtrag:

Mein Ansatz funktioniert so leider nicht.

Da meine Rays nach wie vor nicht 100% richtig positioniert waren, und ich Rechenfehler ausgeschlossen hab, bin ich nochmal in Ruhe rangegangen.

Tja, der Offset im Boxcollider2D giebt den Abstand vom  Pivotpoint zur rechten oberen Ecke an und funktioniert nur wenn der Collider zentriert ist.

Ich hab das mal im Bild dargestellt:

Rays3.png.14bf67486800efffc21cb75f3a5d5550.png

Von den Rays stimmt dann nur noch der obere Rechte.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich hab ja leider keinen Code zum Drüberschauen (;)), aber generell findest du die Ecken etwa so:

var halfSize = boxCollider2D.size / 2f;
var center = transform.position + boxCollider2D.offset;

var topLeft = center + new Vector2(-halfSize.x, halfSize.y);
var topRight = center + new Vector2(halfSize.x, halfSize.y);
var bottomLeft = center + new Vector2(-halfSize.x, -halfSize.y);
var bottomRight = center + new Vector2(halfSize.x, -halfSize.y);

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

        standCollider = transform.GetChild(4).GetComponent<BoxCollider2D>();
        rayOffsetStand = (standCollider.size / 2 + standCollider.offset) * transform.localScale;
          
        RaycastHit2D leftCheck = Raycast(new Vector2(-rayOffset.x, 0), Vector2.down, footOffset);
        RaycastHit2D rightCheck = Raycast(new Vector2(rayOffset.x, 0), Vector2.down, footOffset);

        RaycastHit2D headCheckLeft = Raycast(new Vector2(-rayOffset.x,rayOffset.y), Vector2.up, HeadClearance);
        RaycastHit2D headCheckRight = Raycast(rayOffset, Vector2.up, HeadClearance);

So siehts bei mir aus. Ich probier deins mal morgen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

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

×
×
  • Neu erstellen...