No announcement yet.

CPU Usage and gameplay logic

  • Filter
  • Time
  • Show
Clear All
new posts

    CPU Usage and gameplay logic

    Hi all,

    I've been reading through the UE4 source the past few days trying to get a feel of the engines architecture. I am a bit confused about how gameplay related code is handled in an efficient manner. From what I understand there are several aspects of UE4 that is multi-threaded namely the renderer, animation, and some in-editor tools. I noticed there are a few worker threads available as well for some tasks.

    In general however, it seems that UE4 designates an entire thread to specific subsystems rather than dynamically running jobs on any thread like some newer modern engines do. Is this assessment correct? It seems to me that if you want to parallelize your code you need to create a copy of your game state in something like a USTRUCT, run the necessary computations on a worker thread manually, then copy the result back into the main thread which can then update your game states (UObjects etc). Does this sound correct?

    I did notice an oddity though, I forget which file exactly, but it seems the engine dynamically parallelizes ticks? From what I understand ticks are generally recommended to not be used because for most game code event driven logic is far more optimal (and probably easier to multi-thread?)

    Is there any extra work on the part of the dev to utilize this feature or is this done by simply using included classes like Actors n such? Basically what I'm asking is too what extent does the engine automatically multi-thread for you? What classes, and systems are multi-threaded by default?

    Thanks. Hopefully I don't sound too dumb.

    Depends on what you are trying to do...there are many different ways to leverage multi-threading.

    As far as dynamically running jobs, the taskgraph is probably one thing you might want to look into.
    I cover that in the middle of a post I wrote a while ago:

    Another useful way to leverage multiple threads is parallel for:


      This may not prove the most useful but you may find something in these slides helpful. I wonder how the chaos engine really compares to our bullet3d.


        The engine won't automatically multi-thread things for you (beyond systems that are built with that in mind, like animation or Chaos). The reason being is it isn't safe to do so. You only want to multi-thread things where A.) it makes sense performance wise and the initial cost of creating/distributing tasks is easily paid for, and B.) You know exactly how the data is used and can be 100% sure all the objects you'll be using are thread safe.

        UE4 has a bunch of built in Async Tasks options in C++ which are perfect for discrete computation tasks and such. IMO the best way to handle efficient gameplay is to just cull down what absolutely has to be updated per frame, and what can update at a slower rate / only when it needs to / etc.

        However, I think you may be putting the cart before the horse and I would just get to a point where you have profiling data definitely saying your gameplay systems are slow before you worry about how to handle that.
        Able Ability System - A high performance, robust ability system for UE4. Now Available!