Multithreading Saga Continued...

     This week I grappled with Unreal Engine multithreading some more. I'm trying to make the terrain generation as efficient as possible for the planets, and that has consisted of lots of trial and error, and several rewrites, which means learning!


    I came across this great Unreal Fest Gold Cost talk from 2024 which explains UE multithreading and how to use it. I'm surprised I hadn't come across this before because it has lots of great info. The biggest revelation I had was that I was using the wrong method of multithreading for what I wanted to do. Before this week I was using an FRunnable to calculate the terrain. In the talk however, Alex explains that these FRunnables are meant for larger lifecycle tasks and are intended to be kept running. For my use-case though I want more fire and forget type functionality. Give a thread some info, let it run its calculations, and give the resulting data back to the game thread whenever it's done. 

    For this job I looked into several of the options outlined in the talk: the thread pool, async tasks, and atomics. Though I ended up settling with the Task System for a couple of reasons:

  • Very robust compared to other methods while still having minimal overhead.
  • Claimed to be fantastic at going wide with tasks which is what I want.
  • Improvement of the Task Graph which has been in the engine for a while.
  • Better debugging capabilities.
  • And I got the sense that the Unreal Engine team it putting more effort into expanding and supporting the Task System.

    This whole saga of finding the solution that I would go forward with involved many rewrites and changes where I got turned around and frustrated at times. Taking a step back and keeping notes on what was working and what wasn't helped me through this part. At time of writing, it's still a work in progress though.

    I intended to end this week with a fully functional and optimized version of the terrain generation with stat traces to show the improvement, but alas, going down too many rabbit holes means that I will be continuing this work into next week. Though I am hopeful that taking it slow here will lead to better results.

Comments

Post a Comment

Popular Posts

Mini Solar System Postmortem

     On September 6, 2021 at 5:05pm MT, Mini Solar System version 1.0 was released. I had initially planned to launch at noon but a last minute bug with volume control of all things, delayed the release until the end of my day. This progress update will not focus on the work I did for the upcoming 1.1 release, but instead will be a post-mortem; recounting the entire development of the game. Overview      Mini Solar System started with the working title "Space Game" and development officially started on May 10, 2020 exactly 16 months ago to the day of me writing this. Development really began to speed up in mid February 2021 when I went full time on the project after deciding to defer university for a year; due mainly to complications related to COVID-19.      There was no real design goal at the start and was initially meant to be a way to display my technical skill and also learn more about the Unreal Engine while I was at it. At the...
Read more

A New Chapter

Image
     This week has presented the biggest change probably since the release of Mini Solar System; I was offered a full-time position as a junior programmer at Studio 369 which I was happy to accept. I start on Monday and I couldn't be more excited to work with the team there! However, this did mean though that my priorities shifted quite instantaneously. I went from working full-time on "RPG_Game" to preparing for this new job. This mainly meant getting up to speed on networking as that is the one area of Unreal Engine I feel I have a lack of knowledge in (I'm already proficient in UI, AI, gameplay, materials, and general backend work), and since 369's specialty is networking I figured I would come prepared. I did do a little work on "RPG_Game" but it was minimal just to tie up some loose ends. Unreal's Multiplayer Framework      As explained by the Unreal Engine documentation, "multiplayer programming [is] inherently more complex than programmin...
Read more

Polishing the Foundation

Image
     This sprint was relatively uneventful; mainly cleaning up the existing foundational elements of the game (the first person character and spell component) and continuing to improve the necessary elements of the game like the pause screen. Player Character & Spells      The improvements to the player character come in two parts; the ability to have, use, and change spells, as well as interaction via an interface. Both of theses are as simple as I could make them. Utilizing inheritance from USpellBase using the spells is only really a single line, and changing out the spells we can use the NewObject factory to make a new spell very simply. FirstPersonCharacter.h FirstPersonCharacter.cpp      As for the interaction interface, it only consists of two functions right now, one to fire an interaction event and one to check if the object can be interacted with. This second function is used mainly to show UI on the player's screen like...
Read more