Let’s assume that we have one function that is relatively fast to execute.
If the function was called frequently enough within one tick time frame, to cause a heavy cost on execution time. Then what are the rules of thumb of UE4 to deal with the situation, and how’d that differ whether ‘Smooth Frame Rate’ and ‘Use Fixed Frame Rate’ were chosen or not.
I am concern about all aforementioned scenarios, but more particularly in the case where neither frame smoothing nor fixing were active! Will UE4 default behavior just make the tick go slow inattentively, or will it just reduce the number of that particular function calls, because I saw some strange behaviors that would suggest that the engine indeed decided to neglect some calls, but I am not at all certain.
Feel free to share opinion even if you’re not certainly sure about it, because from where I stand, I know close to nothing about what’s going on inside the engine and its defaults.
Unreal will not call a function less frequently. The code says “call it this often” (presumably through a loop, or whatever) and thus the engine calls it that number of times.
Unreal will increase “DeltaTime” up to a configurable limit. If your tick function takes longer than the max DeltaTime to run, then time will essentially slow down, and the game will lose network sync if it’s networked.
It is up to you to write code, and specify suitable minimum-spec target hardware, to make your game work well enough to be playable. on the minimum-spec.
Note that there’s a feature to set a “tick interval” for actors – “only tick every half second.” Unfortunately, while this will save CPU and increase frame rate on “middle end” and high end systems, this ends up actually making the “cliff” at the low end harder. Once your frame rate gets low, more entities will tick per frame, and thus make frame rate even lower, in a quick death spiral.
Thanks for your response. That makes total sense, and I’d have expected that to be the case if I didn’t have a weird bug that’s best explained if the engine ended up ignoring some of the rest of tick calls to overcome lengthy frames.
That’s interesting you mentioned network sync and not rendering, isn’t that because rendering a frame will always wait for the entire tick to finish no matter how long that takes? or does the rendering thread will potentially be not fully synced with the main thread? Because that seems relevant to the issue at hand. In my case, I render mid tick would give the implication of omitting several calls.
I’d very inclined to state that rendering and main loop are fully consecutive, but I don’t know the ins and outs of the timing of updating the status and positions of meshes to be rendered, that could go murkily enough still.
To clarify the situation, I have a mesh that get erased fully at the beginning of the player pawn tick, to be fully rebuilt at the very end of said tick function. Any data updating to the rendering RAM area within that period will lead the mesh to fully disappear.
Tick will update both renderable state and simulation state, so it’s not really optional unless you mark it so, from what I know. (There are settings for “how frequently to tick” that would allow you to change this.)
But, because Tick ends up scaling poorly, this is why the general advice is to make everything event driven, and only change/update things on notification, rather than “every tick.”
That being said, now I wonder: In UE5, they are said to change “physics delta time is same as frame time” to “support a fixed physics update rate,” which means physics might tick 0, 1, or more times per render frame. I wonder if they will break “render tick” out from “simulation tick” then? I haven’t looked into the UE5 code to check that out; that’d be interesting. (But probably not very related to your case )
As far as I know, UE4 depends on PhysX of NVIDIA for physics simulation, and it runs at fixed rate 60 (or may be 50 I don’t remember).
I don’t know if UE5 will still use the same software (was PhysX 4 I think). For my project, which is basically a physics simulation project, I actually don’t use UE4 physics engine altogether, so I think I can smoothly move to UE5 in the near future, for Meta human and other candies Epic will provide us with along the way.
UE4 depends on PhysX, but uses a variable time step. That’s the whole reason of DeltaTime not being fixed. That’s also the reason why different frame rates lead to different physics outcomes in a variety of situations.
UE4 does this to be able to render each object at “exactly” the right position. If you simulate at 60 Hz, but render the screen at 45 Hz, you will have to delay the simulation output by some fraction of one simulation frame, to show the “right” position, depending on how far along you got in the step time.
UE5 has already announced that they’re using Chaos physics, which is a physics engine developed internally by EPIC.
)