Hey zusammen
Zu diesem Thema gibt ganze Bücher. Zur Ergänzung wieso überhaupt Multithreading nötig ist bezogen mit einem Beispiel der Unreal Engine. Nehmen wir einmal an, du hast einen rechenintensiven Task, das kann zum Beispiel AI sein, Animation, oder kürzlich habe ich Positionsberechnungen für eine Formation durchführen müssen. Als Beispiel stellvertretend sagen wir mal, wir müssen alle Primzahlen bis zu 1'000'000 ausgeben.
Los geht's, einfach in Blueprint ein Loop bis zu einer Mio:
Wenn ich das jetzt ausführe freezed das ganze Spiel für ein paar Sekunden und bricht den Loop dann ab. Es wirkt also so als ob das hängen geblieben ist. Das ist also absolut keine Option. Das sieht man auch sonst häufig zum Beispiel bei Ladeanimationen, wenn der Mainthread blockiert ist, bleibt einfach die Animation stehen. Wieso passiert das? Der Mainthread bearbeitet das Sequenziell, also alles andere muss warten bis diese Rechenintensive Operation abgeschlossen ist. Entsprechend friert das Bild ein, keine Inputs mehr möglich etc.
Wie löst man das jetzt? Mann kann das an den Tick hängen und pro Tick nur eine oder ein paar dieser Zahlen berechnen, sodass der Mainthread nicht blockiert.
Und siehe da - das Spiel friert nicht mehr ein. Aber nun dauert das ewig. Was vorher eine Minute gedauert hat, dauert nun über eine Stunde. Was nun? Multithreading!
Dazu der erstelle ich die Klasse PrimeNumberWorker und implementiere Runnable.
class DEMO_API FPrimeNumberWorker : public FRunnable
{
public:
FPrimeNumberWorker(const int Iterations);
~FPrimeNumberWorker();
virtual bool Init() override;
virtual uint32 Run() override;
virtual void Stop() override;
private:
int IterationsCount;
FRunnableThread* Thread;
bool bShouldRun;
};FPrimeNumberWorker::FPrimeNumberWorker(const int Iterations)
{
IterationsCount = Iterations;
Thread = FRunnableThread::Create(this, TEXT("PrimeNumberWorker"));
}
FPrimeNumberWorker::~FPrimeNumberWorker()
{
if (Thread)
{
Thread->Kill();
delete Thread;
}
}
bool FPrimeNumberWorker::Init()
{
return FRunnable::Init();
}
uint32 FPrimeNumberWorker::Run()
{
for (int i = 2; i < IterationsCount; i++)
{
if (UMathLibrary::CheckPrimeNumber(i))
{
GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Red,
FString::Printf(TEXT("%d"), i));
}
}
return 0;
}
void FPrimeNumberWorker::Stop()
{
FRunnable::Stop();
bShouldRun = false;
}Was immer jetzt in Run ausgeführt wird passiert auf einem eigenen Thread.
Erstellen und gleich starten kann ich den mit:
Und wieder löschen:
Okay. Wenn ich den jetzt ausführe, keine Einfrieren und die Berechnung dauert wieder etwa eine Minute - Cool 
Wie du siehst, hat das Potential für wirklich(!) erhebliche Performanceoptimierung. Kommt aber auch mit starker Limitierungen, so kannst du nicht einfach Daten auf deinem Mainthread lesen oder Schreiben. Ein Teil dieser Problematik hat schon Tomarr erklärt.
Das war jetzt etwas unnötig ausschweifend. Zurück zum Punkt. Der BP den du gepostet hast funktioniert bei mir. Natürlich siehts nicht gut aus, weil jetzt wechselt der Animation mehrfach pro Sekunden, also jedes Update gibts unter Umständen ein Wechsel.
Für deinen Zweck gibts den RandomSequencePlayer. Der ist Threadsafe und macht genau was du willst. Er wechselt die Animation random. Du kannst sagen wie oft er dieselbe Animation spielen soll, welche Wahrscheinlichkeit etc. So funktioniert's:
Auf der rechten Seite kannst du alle die Animation hinzufügen die du möchtest.
Gruss
