I’m trying to reduce all the ticks I can in a project, however there are a few places where I’m not sure what would be the best way.
Dynamic cursor that shrinks/grows depending on movement. I used ticks at first, however I replaced that with a custom event that gets triggered on “even begin play” and then calls itself to “refresh” the cursor size every 0.1 sec. I tried using larger delays, but the size changing became choppy.
A physics object being picked up by a player. The location of the object is updated with a tick. I’ve tried with a self-calling custom event, but I’ve usually had to end up with a very low delay between the loops which I thought were perhaps just as inefficient as ticks.
Are there some better ways than custom event loops to update something constantly like that?
Dynamic sun position. I’m using ticks currently, and since I want it to be very smooth and slow I haven’t really changed that yet.
My InputAxis events seem to constantly be firing off, similar to a tick. Maybe that won’t matter.
Are self-triggering custom event loops with a minor delay (~0.05ms) more efficient than ticks?
It isn’t so much the tick that causes slowdowns as it is what you are doing with the tick.
In many cases, it sounds like you just need less executions out of your tick. So if you are getting say 30 FPS you probably don’t need 30+ executions a second to get your desired result. Try gating it so that it only lets an execution through say one tenth of the time or even less.
In my scenarios, calling the Blueprint tick event for my thousands of actors was causing tremendous frame rate loss, but because I wanted smooth positioning and scaling per frame, I needed the tick.
My solution was to manage the ‘tick enabled’ where possible through an external manager (eg. if the solar system is too far to draw, disable the tick on the planets and asteroids within it), and where it wasn’t possible to manage in a package like that, I monitor the screen size of the actor (like LODs do) and the last draw time of the actor in the C++ tick and skip the rest of the tick if it’s too small or not drawn.
Doesn’t a tick update exactly once per each frame? Some things, like the sun, I want to move smoothly no matter what the fps would be. Currently I move it slightly per each tick.
Could you explain a bit better what you mean by gating? Is that basically like connecting a tick to a branch with a on/off bool?
Some things should always be on. For example, the sun movement. For those things, does it matter if they’re run by a self-activating custom event like in the following screenshot?
Is this terribly inefficient or stupid for things that should always be on/constantly updating as long as the game is running? (I know the transform isn’t being updated per tick in the screenshot, it’s just an example)
Wow, I’m nowhere near that level in complexity. I’ve got at most 10 ticks running together (with half of them being my input events which I can’t seem to get to not tick constantly)
And they’re mostly just doing “simple” things like changing the rotation of the directional light sun a little bit each tick or changing the transform location xyz on items that the players hold.
I guess I could take “snap shots” like every 0,1 sec of the item position and then just interp between them, but that might look weird if the player moves the physics objects very fast, or that might not be any more efficient than just doing it with ticks.
If you’re not seeing a performance issue, and you don’t anticipate having many more actors doing the same thing, I recommend sticking with the Tick event for smooth transitions - especially since you have so few and they are simple.
Yes, but most people aren’t going to notice if something updates 10 times a second instead of 30-90. This is something you would want to play with, and for best results set it up so that it scales with FPS. For instance if FPS drops you might want it to update more often so that the drop in framerate doesn’t make it noticeable to the player.
Yeah, you could use a branch, gate, or whatever works best for your setup. The idea would be to count executions coming from the event tick node, and only let say every tenth execution through.
This setup would probably be ok, though you will probably want to insert something to let you turn it off completely.
Really though you only need 1 custom event. Just put the delay after your transform update and then put the execution from the delay back into the transform update. I do something similar in a few of my systems, though they are intended to eventually branch out of the loop once the work is complete.
You should be fine, especially if your setup runs without issue on all your target platforms/machines. Even with ticks. I see a lot of people have this kneejerk reaction that screams against ticks, but honestly it is up to you to keep the performance in line with your budget. If it works with your most performance intensive case, on your lowest end machine, go nuts.
Best alternative is firing timers from C++ which calls custom Implementable Events; from there you do your Blueprint stuff. Easier alternative is simply to use Timeline blueprint node.
Ticks were added as a ‘quick-n-dirty’ way of having stuff done quick when you don’t have to care about performance.
