Is there a way to have framerate independent, deterministic computations?
With other words, is it possible to access the game world from a different thread, or, which would be ideal, having a function update on each physics substep?
The goal is to have an object update in reliable intervals, as opposed to having larger intervals when the framerate degrades. (See the comment to one of the answers.)
Why not use time based computations? Generally that is why delta-time is used for animation rather than each call of the tick. The same is applied to computations that need to be over time or over a set interval of time. Each call of the tick function supplies a parameter of “deltaTime” which is the number of milliseconds since the last tick. You can also get the delta time from the World Object.
GetWorld()->GetDeltaTime()
(above code should work for most actors if you are not within a tick function.)
You should be able to use this for your interval based computations where 1000 milliseconds equating to 1 second.
This won’t work well to react to the environment. Adjusting an object in velocity, position, and rotation to the ground it’s hovering above requires a constant interval to remain deterministic.
You could make your own sub-stepping simulation scheme using the DeltaTime.
This would do double-steps to keep your simulation intervals constant.
Not really. I believe you are over thinking the problem here. If you have an object hovering above the ground and needs to stay a consistent distance between the ground, use a collision object. All you will need is a forward vector to determine where the object will be between the previous time interval and the new time interval. You can use the the collision object’s hit normal to determine where the ground is and at what angle your hovering object should be at.
If you need to test for the object to collide with other objects during that time, perform a trace to determine if that object needs to adjust it’s course during the current tick. Nav Mesh should help with navigating around complex terrain using AI. If this is a PC actor they it’s their own fault if they hit that tree or rock.
Finally frame rates should be extremely fast, we are talking about 30-60 per second if not more on better machines, which honestly is faster than most conscious thought.
However I do not have the exact details on your problem and honestly cannot think for the life of me why, unless you are not using a capsule, sphere. or cylinder collier for automatic adjustments and ground collision tests, switching on a few settings within the Movement controller, or a decently implemented Nav Mesh, why you would need a set interval update not based on time.
Further more NOT using time based updates will result in different behavior faster or slower on other computers. This is why in game development as a whole we use time, and not computer ticks.
This would be theoretically the same as hooking to a Timer, wouldn’t it? That wouldn’t change that the time between some updates gets larger when the framerate drops. This could work if the objects transform is manipulated manually, but when accessing its physics (UE4 physics system) it’s impractical.
Yes I was assuming you were doing your own simulation.
If that’s not the case, I have to agree ArcainOne - you should try to use the physics system as it’s intended. You can always turn on CCD in your bodies.
Also you can tune the PhysX fidelity with substepping options:
Ah well. I may indeed overthink the problem. But let me say I have already created multiple prototypes, some updating each tick employing the delta time, one hooked to a timer with a fixed number of updates each second. The timer though only catches up on missed updates each frame so it comes down to the same result.
However, the issue is always the same. If, for example, moving towards a slope, and the update time is too long at high velocity, instead of rotating with the slope it crashes against it. I hope this illustration clears it up (pardon the quality, as I currently have no access to my drawing tablet):
As hopefully visible, it’s important that the updates happen with just little time between them. My favorite solution would be having an iteration on each physics substep, instead of each game tick.
Another problem arises when calculating the force required to push the object away from the ground. If the update time is too long, it gets pushed further out than intended. Although if indeed there is no option to have a framerate independent calculation, I’ll have to switch from functions of the likes of SetLinearVelocity to such as AddForce I reckon.
Have you tried the UPhysicsThruster component? I imagine you could make a pretty cool hovercraft with that and the proper collider.
unless you are not using a capsule,
sphere. or cylinder collier
I missed this line. Indeed I am not, I am adjusting via manual LineTrace distance checks.
I can’t help but wonder if a possible solution lies within the Vehicle template. In fact I’d put a lot of money on it. You’ll most likely have to do some major overhaul to the system but considering how vehicles work I bet that is where you’ll find your solution.
And when you do please post it, I am curious myself.
