Download

Splitting tasks so your fps wont drop as much

Hi.

since I can’t seem to find answers on google I might have a very wrong understanding on how tasks are processed…
Right or wrong: all connected code is executed in one frame, when done the frame gets updated

If thats true I wonder how I could split a heavy task into several frames? What kind of flow control do I have to use for this?

For example, I spawn 3 chunks of cubes. Spawning those 3 chunks dropps my framerate for a short period of time. How can I create one after the other without it trying to complete all in one frame?

Please excuse me If Im on a very wrong path here…

TY for your input

Simplest may be a delay node. You could also set a timeline to run every tick and do something each tick, and I’m sure there is also an expert way to do it with some code that I don’t know of.

See if this helps: Asset Manager for Data Assets & Async Loading - Tom Looman

1 Like

You kind of are in a very wrong path.
But you also aren’t.

Why?
Normally. You perform tasks in a separate thread.
Be that a dedicated cpu core or the gfx or whatever.
It’s not the game thread.
Therefore the fame FPS is unaffected.

However.
Spawn actions require you to act on the game thread.
As such, even setting up a multi threading system wouldn’t really help.

Now.
Adding a delay node won’t do anything at all except wait for execution to be allowed.
This is bad coding.
Since the engine is full of it (bad code that is), we sometimes resort to it. Whatever works.
Doesn’t mean this is the correct way to do things.

Adding a timeline
Every tick, is just going to mean increasing the execution stack without any real benefit.

async manager
Is a completely different and viable pipeline. But I doubt it’s blueprint.
It is a much more proper way to do things.
It is kind of similar to setting up multithreading but it would actually work - you need cpp for both.

The only other option is for you to set up a blueprint Spawn manager. You set the manager to handle a Pool.

Pools are a fairly common concept.
You keep count and manage how many instances the engine can safely batch at one time.
As well as their removal.

The extent of a management pool is whatever you code it to be.

It can go as far as tick aggregation if needed (the manager runs the tick function for all the actors it manages so that the function cost is much lighter instead of having many tick functions).

For your specific case- spawning cubes.

You can set the manager to Spawn a variable number of cubes based on delta time.

The lower the frame count the less it spawns.
A maximum value needs to prevent people with high fps from getting swarmed by cubes.

Obviously there’s much more to this, such as how you Spawn things, and what their position is defined by/calculated.

The calculations - for instance - could be done in parallel via multithreading if needed. Or they could probably be simplified and done “on begin play” as part of the loading.
Storing the calculations and using the stored values is essentially “costless” when it comes to runtime eval. But their cost has to take place somwhere in the pipeline.
USERS are generally OK with paying a loading cost up front. So that’s what we all generally set up.

Running a custom manager “spawn” function per tick, you should be able to limit the number of spawns per tick natively.
The function (or event) will only run once and Spawn whatever you told it to Spawn.

Note that this isn’t the best solution. But it is easily achievable in blueprint only.

If you want to be fancy you can set up an interface for it too.
You will still hit the game thread when you use “spawn”.
As such. Using the game time to limit the number of spawns could throw off iterations.

You manager and pool have to be coded to account for all dynamic variations possible. Including game pause. Probably.

2 Likes

Hi there!

So after I read through your post and tried to soak up your information I sat down and re-worked my whole approach on this.
At this stage I am mentally not ready to dive into cpp so I tried focusing on the idea of a “spawn manager” and on “precalculate and storage”
It made me learn how to cut tasks in smaller pieces, rethink my whole code writing approach since now it has to work on tick/timelines, and especially gave me much more insight about how powerful the hardware is by squeezing more and more loops into a single “tick”, to see whats possible, how its affects the calculation time but also the different fps.

Probably far away from your idea of the spawn manager but for me, comming from "oh i can only have 120 loops before the infinite loop error crashes on me, so thats my limit :frowning: " to "wooow its so fast and I now can calculate hundreds of thousands more things now, infinite possibilities :hugs: "

Bottom line, much appreciated your spend time answering me, lead to me learning a lot.

2 Likes