FVector NewLocation = GetActorLocation();
    float DeltaHeight = (FMath::Sin(RunningTime + DeltaTime) - FMath::Sin(RunningTime));
    NewLocation.Z += DeltaHeight * 20.0f;   
    RunningTime += DeltaTime;
    SetActorLocation(NewLocation);

Durch die Zeile eins wird wohl die aktuelle Positions einer Spielfigur in NewLocation gespeichert. Die Frage stellt sich dann bei Zeile zwei. Was wird hier gemacht? Ich weiß, dass DeltaTime die Zeit berechnet, die gebraucht wird, um ein Frame zu berechnen, oder so in etwa. Vielleicht kann hier jemand Klarheit schaffen.

Btw, oder es bewegt sich vor und zurück (Z-Richtung).

Sieht für mich so aus, als soll die Höhe des Objekts periodisch Schwanken (zwei sich überlagernde Sinuswellen). Ist das ein Vogel oder ein anderes Fliegetier bzw. UFO?

Btw, oder es bewegt sich vor und zurück (Z-Richtung).

Das letztere trifft zu. Es bewegt sich vor/zurück (Z-Richtung). Kannst du mir die ganzen Zeilen mal erläutern?

Warum wird das gemacht?

float DeltaHeight = (FMath::Sin(RunningTime + DeltaTime) - FMath::Sin(RunningTime));

Warum wird RunningTime wieder um DeltaTime erhöht?

RunningTime += DeltaTime;

http://www.wolframalpha.com/input/?i=f(x)+%3D+sin(x+%2B+0.01)+-+sin(x)
Spiel mal ein wenig damit rum. Desto geringer delta, desto flacher ist die Kurve. Viel Sinn macht das für mich aber auch nicht.

DeltaTime ist, wie der Name schon andeutet, ein Zeitschritt. Es wird hier also eine Positionsänderung für diesen Zeitschritt berechnet, so dass das Objekt einer Sinuskurve folgt. Und zwar so, dass diese Bewegung unabhängig von der Größe des Zeitschritts ist. Die nachfolgende Zeile setzt dann die sich daraus ergebende neue Position; die Zeile darauf berechnet die insgesamt "vergangene" Zeit (wird sicherlich noch irgendwo anders benötigt); und die letzte Zeile gibt die Änderungen an die Programmlogik weiter.

Edit: Ah, das wird dann auf die höhe gerechnet... Gut, dann:
Das Objekt bewegt sich irgendwie in einer "Schlangenbewegung" (langsamer und schneller). Mit sin(...)*delta solltest du "fast" das selbe Ergebnis bekommen, keine Ahnung warum es so gemacht wurde.

Die Programmlogik ist mir schon klar, programmiere auch Spiele nebenher, allerdings ergibt es für mich keinen sinn, die Kurvenhöhe vom delta abhängig zu machen. Bei einem langsameren PC würde das objekt so viel weiter ausschlagen als bei einem schnelleren PC.

Edit: Ah, das wird dann auf die höhe gerechnet... Gut, dann:
Das Objekt bewegt sich irgendwie in einer "Schlangenbewegung" (langsamer und schneller). Mit sin(...)*delta solltest du "fast" das selbe Ergebnis bekommen, keine Ahnung warum es so gemacht wurde.

Hat vielleicht SeppJ eine Idee, warum es so gemacht wurde?

tkausl schrieb:

Die Programmlogik ist mir schon klar, programmiere auch Spiele nebenher, allerdings ergibt es für mich keinen sinn, die Kurvenhöhe vom delta abhängig zu machen. Bei einem langsameren PC würde das objekt so viel weiter ausschlagen als bei einem schnelleren PC.

Edit: Ah, das wird dann auf die höhe gerechnet... Gut, dann:
Das Objekt bewegt sich irgendwie in einer "Schlangenbewegung" (langsamer und schneller). Mit sin(...)*delta solltest du "fast" das selbe Ergebnis bekommen, keine Ahnung warum es so gemacht wurde.

Hat vielleicht SeppJ eine Idee, warum es so gemacht wurde?

Es sollen wohl 2 Sinusse gemischt werden.

CrispyTurtleAlligator schrieb:

Hat vielleicht SeppJ eine Idee, warum es so gemacht wurde?

Es sollen wohl 2 Sinusse gemischt werden.

Ich sehe da ehrlich gesagt kein "mischen", sondern lediglich die Berechnung der Veränderung der Z-Position, während sich ein Objekt entlang einer Sinuskurve bewegt:
Die aktuelle Position wird von der Position in der "Vergangenheit" subtrahiert, damit erhalt man die (negative) Veränderung über den Zeitraum deltaTime .

Ein Grund, das über diese Differenz zu machen, könnte allerdings tatsächlich ein mischen/überlagern sein: Und zwar mit anderen Transformationen die schon in den
Koordinaten des Objekts stecken (durch andere, ähnliche Funktionen). z.B. könnte sich das Objekt in Weltkoordinaten kontinuierlich entang der Z-Achse bewegen,
während es gleichzeitig in Z-Richtung um seinen lokalen Ursprung schwingt (Durch die Differenz kann man den Schwingunsganteil in Zeile 3 einfach aufaddieren,
egal was in der "Location" sonst noch an Bewegung drinsteckt).

Ich würde so etwas zwar selbst eher mithilfe mehrerer Transformationsmatrizen beschreiben, aus denen sich die neue Position direkt berechnen lässt,
aber mit aufaddieren wie hier kann man es natürlich auch machen (sofern man mit den Rundungsfehlern leben kann, die sich auf diese Weise wahrscheinlich immer weiter aufsummieren).

Finnegan

Es sollen wohl 2 Sinusse gemischt werden.

Nein.