Make it clear when to use _process and _physics_process

[miv391]

At least I am not very sure what things I should do in _process and _physics_process functions. I have read the Godot documentation, watched YouTube tutorials and read reddit threads but it seems that everybody seems to be somewhat confused.

I know the basics, _process is called for every frame and _physics_process is called 60 times per second. I also know that if I want an object (player for example) to move smoothly, the object's position must be updated in every frame. That means that _process should be used for calculating the new position. But for some reason, I have seen many cases where movement is calculated in _physics_process. So are there some reasons why to use _physics_process even if it makes the movement jittery?

Godot documentation should clearly tell

• When to move object in _process / _physics_process
• What else to do / not to do in _process / _physics_process
• How to handle situations where framerate is something other than very stable 60 fps (basically every game should take this into consideration). What vsync is and how it affects the game should also be explained, I don't think it's clear for all beginner game programmers.

[theraot]

I have written about _process vs _physics_process elswwhere. I'll expand on that.

_process is called on every graphics frame (which can be as fast as possible if there is no vsync, if there is vsync then it is limit to the video
display refresh rate), and _physics_process is called on every physics frame (which has a frequency is configured on project settings, with 60 frames per second as the default). In particular, _physics_process will run as part of Godot physics routine. Thus, if you want any physics feedback you would use it.

Now, If your display is quicker than the physics frequency, and you only move your objects on _physics_process then they are NOT going to move smoothly (there will be graphic frames where it does not move). Similarly, if the physics frequency is quicker than the display, and you only move your objects on _physics_process you might be wasting effort (there will be physics frames that are not displayed).

We want to have physics work on a rate that is not depended on the hardware, because physics is a feedback system, and errors accumulate. Thus, unless you design your physics code very carefully, you would see different behavior when you run it at faster rate. So we want to control the rate instead of leaving it to the hardware.

Thus, if you are going to use _process for graphics and _physics_process how do we reconcile this? One idea is to continue the motion in _process, the problem with that is that objects might visually collide and overlap between physics frames because they are being moved without physics. The other idea is to use _process to interpolate the prior position with the new one, computed by physics, which is correct and smooth, but adds a small delay.

Now, the good news: a built-in step interpolation solution is about to be released Godot 3.5 has a solution for Physics Interpolation for 3D and there will a new one for Godot 4 (see #671 #2753). Aside from that there are some addons that do it. Or you can roll your own (which does not make for good introductory tutorial, so you don't see many explanation of how to go about it). I suggest to use an addon (such as this one: https://github.com/lawnjelly/smoothing-addon) instead.

---

• When to move object in _process / _physics_process

If you are going to interact with physics use _physics_process. If you interacted with physics in _process and it is quicker, you may have some stale physics results, as physics would only react to what you are doing on the physics frame… And if you interacted with physics in _process and it is slower, you could be ignoring physics interactions.

A similar argument can be done for making graphical updates in _process. If you used _physics_process for graphical updates and it is quicker you are wasting effort in updates that are not shown, and if it is slower you would fail to have smooth updates.

Thus: Use _process for graphical changes and use _physics_process for physics.

This suggest to move graphical objects in _process, and physics objects in _physics_process. Thus: consider moving your KinematicBody in _physics_process, but your MeshInstance in _process… And that is the starting point if you wanted to make your own step interpolation. I hope you see that just parenting the MeshInstance to the KinematicBody is much more practical, but if you only do that it means the motion would not appear smooth. if only Godot did the step interpolation for us… Ah, right: #671 #2753.

By the way, you can call move_and_slide and move_and_slide_with_snap multiple times in the same physics frame. Which is probably what you are doing if you are using it in _process. But as I said before, physics would not have reacted to what you are doing in _process until the physics frame.

---

• What else to do / not to do in _process / _physics_process

I want to point out that Input is designed to be used from either of these (it is aware on where it is being called). So just_pressed and just_released means "since last frame". What kind of frame? That depends on where you are calling it. I tend to use it on _physics_process because I want to check both input and physics together. However, others prefer to do it on _process. Either way, if you need to be more precise over the timing of input (and also to work with pointing devices) consider using _input instead.

I would use _process for purely - or at least mostly - graphical changes, such as changing animations or sprites. However, if it is a change that can only happen as result of physics, you aren't gaining much by doing it in _process. Although, I find it a good separation of concerns: If I always do graphics updates on _process I don't need cognitive load to know where each graphics update is… Unless I decide it is not worth it and do it all in _physics_process.

---

• How to handle situations where framerate is something other than very stable 60 fps (basically every game should take this into consideration). What vsync is and how it affects the game should also be explained, I don't think it's clear for all beginner game programmers.

What is vsync

From the point of view of the code vsync synchronizes _process with the refresh of the display hardware. However, what it actually does is ensures that the display buffer is not being updated while it is being drawn, which prevent screen tearing. I should mention that Vulkan has multiple "presentation modes" so the situation is no longer if there is vsync or not. But I don't feel qualified to talk about it.

Time variability

The timing between frames is variable. A frame might take longer because your code is slow, or because the operating system preempts the process to do something else, or because energy saving mode, etc… And you get the time as a parameter called delta, which is the time elapsed between frames. The engine is telling you "hey, this much time passed, move things around accordingly", so it is how much time we must simulate. With everything else taken into account, this variability alone may make the motion not look smooth.

So we know the frame rates are variable. But with _physics_process at least you have an idea of what it would be. Using _process with vsync is probably as stable as _physics_process, but you don't know around what frame rate it will be. People would say that _physics_process will keep its rate even if the refresh rate is low (this is true baring variability), and it is better because it is stable (don't be confused: both have variability, and thus they both need a delta parameter). But the point is that even if the physics frame rate is not exactly what we configured, we know it will approximately be that, and not something widely different - baring really bad hardware for the frame rate we picked. On the other hand the graphics frame rate can be something unexpected.

Motion in unstable framerate

We usually use speeds to define the motion, and I remind you speed is distance divided by elapsed time. So you multiply that speed by the delta time, and time cancels out and you get how much distance it moved. Except, most of the time you don't have to do that because move_and_slide and move_and_slide_with_snap do it internally… Notice they take velocities (i.e. speed vectors).

Now, look, what we are doing is approximating an integration: we are adding small deltas to make up the motion (see Euler integration). If we want to make our computations work regardless of the framerate (e.g. to work on _process), we should use math that would converge on the same result regardless of the size of the deltas. If there is no acceleration (which also means no gravity), there is no problem with Euler integration. Otherwise we would have to move to Velocity Verlet, and for a jerk use Runge–Kutta… Yeah, beginners would not be familiar with that. Thankfully you can use _physics_process and don't worry about an unexpected frame rate. Instead test on the physics frame rate you have, and you know it would be similar on other machines - unless they have too poor performance.

[miv391]

A similar argument can be done for making graphical updates in _process. If you used _physics_process for graphical updates and it is quicker you are wasting effort in updates that are not shown, and if it is slower you would fail to have smooth updates.

If _physics_process is called more often than _process, that will also cause movement not to be smooth. For example if the physics frame rate is 90 and graphics frame rate is 60, in every other frame object moves with double speed.

I don't see how smooth movement is achievable by moving objects in _physics_process unless physics frame rate is set to exactly same as graphics frame rate and the graphics frame rate stays stable.

At least for me it is not clear what is considered "physics" that could go wrong if only _process is used. Is moving the player character "physics"? Does it matter whether the player is e.g. KinematicBody2 or Area2D? Is using collision detection "physics"? If moving KinematicBody in _process will cause problems, I think Godot should at least display warnings in those situations.

[theraot]

Physic basically does three things:

• Moves things around (e.g. RigidBody)
• Query constraints (including collisions, joints, raycasts and so on)
• Reacts to those constraints (e.g. bouncing)

These happen in the physics frame. Hopefully that can give you some idea of the issues that my arise from doing everything in _process.

---

Did I say that if the physics frame rate is faster than graphic frame rate it is automatically smooth? I don't see where. But if I said it I need to fix it. What I see I said is that there would be updates that would not be visible, so it wastes effort.

---

If the frame rates match that would be ideal, yes. I suppose you could change the physics frame rate to match the actual graphics frame rate. See Engine.iterations_per_second. Then again, you would need to make sure your physics code can work for any frame rate, since you don't know beforehand what the graphics frame rate will be. Perhaps it is better to use Engine.target_fps to try to make the graphic frame rate match the physics frame rate, since graphics codes does not get into the same troubles as physics. Edit: I should say; I have not attempted this.

[Calinou]

Changing physics FPS during gameplay isn't recommended, as it can lead to visible stuttering, especially when physics interpolation is enabled.

Note that different physics FPS will also lead to slightly different outcomes in physics simulations, even if you consistently use delta everywhere you should. This is due to the limitations of floating-point precision. This could give certain players an advantage over others depending on the physics FPS the game runs at.

[azur-wolve]

This could give certain players an advantage over others depending on the physics FPS the game runs at.

In which sense?
for that advantage you mean if the physics frame-rate is too low? or too high?

[Mickeon]

for that advantage you mean if the physics frame-rate is too low? or too high?

Depends. Consider this: Your number needs to be greater than 0.5, starting from 0, and adding delta every frame.
If delta is 1 / 5, the sequence in a second will be [0.2, 0.4, 0.6, 0.8, 1.0].
If delta is 1 / 8, the sequence in a second will be [0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1.0].
Because physics frames are evenly spread across a second, the 1 / 5 delta would actually reach the goal before the 1 / 8 one, executing whatever action was tied to this goal a frame or more sooner than expected, as well.

[SamuelLanders]

in reply to Mickeon's answer, It seems that your example is exactly backwards. Anyone that can clarify, please correct me. From my analysis it appears: in your example the variable that triggers something must reach .5 for it to happen. This is only calculated however when the function enters and performs the adjustment according to the delta. These calculations are done once upon entering the function (not continuously) and that indicates that per your diagram the trip point to enter the function is the leading edge of the color changes (dark green to light green, and dark blue to light blue, as well as the vice versa). This indicates that the delta of 1/8 would trip first as the leading edge that is equal to or after the point that reached the .5 is on the 1/8 side. It also makes sense in that something that is checked more frequently can be ascertained earlier.

[Calinou]

The physics interpolation tutorials in 3.5 cover this.

The gist is that you should always use physics interpolation if you want the game to remain smooth with varying render framerates (and render framerates that aren't a multiple of the physics FPS in general).

[miv391]

The 3.5 physics interpolation tutorial is very good.

I would suggest changing the default script template so that it guides to use _physics_process() instead of _process(). I tried v3.5.rc7 and its script template seems to be the same as in 3.4 and it contains commented out _process(), Maybe the template should have _physics_process() instead. Maybe even include the Quick start guide in the template or at least link to the guide.

[Calinou]

Physics interpolation isn't available in 2D yet, so this can't be done until it's implemented and enabled by default in 2D.

Even then, it's not always a good idea to use _physics_process for things that have nothing to do with game logic.

[miv391]

Even then, it's not always a good idea to use _physics_process for things that have nothing to do with game logic.

Excatly that's why every Godot user should read the Quick start guide and I think the script template would be easiest way to make users to read the guide. Documentation is usually read only after nothing else works.

[wareya]

Which function you use for which kinds of logic depends very strongly on the needs of the genre your game belongs to and what your players will specifically demand in practice.

Using _physics_process would be inappropriate for a precision platformer, for example, because it adds input latency; the "best" thing for a precision platformer is to, paradoxically, ignore all common sense and run the game at a fixed framerate with logic in _process and ignoring delta time, living with the slowdown that will occur in expensive scenes (bullet hell shmups are in a similar boat, but there's more you can do to avoid the dilemma because the physics are simple).

Similarly, if a game has expensive game logic and slowdown is not acceptable for the genre (like an FPS), putting that game logic in _physics_process is inappropriate because it will encourage slowdown (_physics_process does not fall back to doing true delta time when it can't keep up with its target tickrate; it falls back to slowing down), even if that game logic looks like physics (like bullet motions).

Godot's documentation should not be in the business of telling developers which things they should use, because it varies so much from game to game, and it's impossible/impractical/not its job for it to enumerate every permutation of game genres and end-user concerns. It should be in the business of telling developers what each thing does, what upsides and downsides it has, and giving some critical examples. You should probably use _physics_process for your combat logic if you're making a third-person action game that doesn't have demanding performance concerns, for example, or a casual platformer where an extra frame of input lag isn't a problem.

Importantly, using _physics_process doesn't get rid of the need for game code to handle delta time correctly (e.g. you might need to lower the physics framerate when publishing on weaker hardware), so it should not be listed as an upside to using it.

[azur-wolve]

_process() → code on it runs at the max frame-rate your GPU can draw (unless limited by vsync or a specified frame-rate limit in project settings).

_physics_process() → code on it runs on a fixed time-step (approx.) Here should put logic code that has not much to do directly with graphics: physics, custom logic, expensive processing, etc.

Personally as rule of thumb try to run all my code on _physics_process(), unless there's something that must be run on _process() like camera smoothing and graphics stuff that otherwise would cause visual jitter if run from _physics_process().
(Many of those problems will be fixed by the new 3.5 physics interpolation though.)

Before Godot 3, _physics_process() was called _fixed_process().
The name were more descriptive, but probably it was problematic because people didn't know where to run physics-related code, ending up mixing it across both, leading to chaotic results.

Another aspect to take in account while developing games, is to keep in mind multiple monitor frame-rates.
For monitors with greater refresh-rate than 60hz, screen tearing and other stuff can become a thing.
You won't notice it if you develop in a 60hz monitor (industry standard), until a player with a 144hz monitor plays your game.
Can't say much about though.

[bsureshkrishna]

Is there a way for _process() to know the time at which it finished its run - i.e. to get an estimate of frame-onset time (in case a frame was skipped to handle other stuff on the cpu) ? but perhaps this is not so simple because _process() runs as fast as possible between frames and then if there are two buffers, the flip of the back buffer happens during the vbi, but _process() may have finished well before that ?

[JojOatXGME]

First, as a disclaimer, some time has passed since I worked with Godot the last time. I also don't have that much experience with it. Anyway, here is my take.

I think the delta available within _process is the time between two calls of _process. Similarly, the delta provided to _physics_process should be the time between two calls of _physics_process. So, both methods get a different delta. Besides, _process is called exactly once per frame, so it doesn't really make a difference whether the delta represents the time between calls of the method, or between the frames.

Also note that Godot doesn't know how long it takes to get the new frame. I am not sure about Godot, but I think the delta available in _process is probably the time between the last frame and the frame before the last frame. This should work as an approximation for the frame currently generated. It also ensures that the time is not shifting over multiple frames. Note that this is different to _physics_process, which should get a constant value as it should be called at a fixed rate.

[bsureshkrishna]

_Besides, process is called exactly once per frame, so it doesn't really make a difference whether the delta represents the time between calls of the method, or between the frames.

This gets to the main point of what I was asking. So there are two ways in which the interval between successive calls to _process would vary from the inter-frame interval (on the monitor)... one is a lag between the call to _process and the succeeding frame display (because, say, Windows decided to steal some cycles) or because _process is called at different times within the inter-frame interval, since I am guessing that, within a frame, the call to _process is not tied to the Vsync or vertical blanking interval in any way.

Put differently, what can we know about the time logged about when _process is called, and the actual buffer flip and display at the openGL/monitor level ? I know that in some software, it is possible to have a blocking function that waits until the flip is completed and then returns that time.. so in principle, it is possible to get that information, but I guess as a game engine, Godot would much rather be doing other things during that time and this is not that important ?

Thank you !

[JojOatXGME]

When I talk about a frame, I don't care whether the frame is actually visualized on the screen/monitor. You may have 200 FPS, but the monitor may only have 60 Hz, skipping about 2,3 frames between each frame which gets visualized. The buffers are swapped when Godot has finished the frame. The timing of the swap is therefore tied to the frame generation, not to the display times of the monitor.

I know that in some software, it is possible to have a blocking function that waits until the flip is completed and then returns that time.. so in principle, it is possible to get that information, but I guess as a game engine, Godot would much rather be doing other things during that time and this is not that important ?

I don't know how it works in Godot, but usually this is called VSync. I would expect that Godot also has an option to enable VSync, as most games have. If VSync is enabled, _process should also be synchronized with the monitor.

Anyway, would be interesting why you need this. Usually, games just render the frames, and the monitor picks up the last generated frame whenever it comes to it. And the user may also enable VSync to avoid screen tearing and archive a more consistent frame times. But with VSync, you have fewer frames per second and therefore higher latency. This is a tradeoff which games usually leave to the user. The benefits may change depending on the performance of the machine. If the game requires quick reflexes and your system has enough performance to get more FPS than the monitor can display, then VSync usually gets disabled for lower latency. Not sure if that helps, as I don't know what you want to do.

PS: Also note that VSync may not work well if you have more than one monitor mirroring each other. These monitors may not be synchronized, and VSync will just synchronize with one of them.

[bsureshkrishna]

thank you again.. it is because I am not really interested in making a game :) I am interested in using Godot for visual experimental research, so being able to control exactly what is on the monitor at a given frame. So the reason for asking about when the Vsync happens, and how _process is linked to the Vsync at a sub-frame level is to get estimates of when things happened on the screen.

For example, Psychopy which uses Pyglet as its back-end says

"As of version 1.62 PsychoPy® ‘blocks’ on the vertical blank interval meaning that, once Window.flip() has been called, no code will be executed until that flip actually takes place. The timestamp for the above frame interval measurements is taken immediately after the flip occurs. Run the timeByFrames demo in Coder to see the precision of these measurements on your system. They should be within 1ms of your mean frame interval.

Note that Intel integrated graphics chips (e.g. GMA 945) under win32 do not sync to the screen at all and so blocking on those machines is not possible."

I hope this makes my questions above a bit clearer ? :)

[bsureshkrishna]

1. To add to this, in openGL, this is what glFinish() does in comparison to glFlush(). It waits until the graphics card is done and is ready to accept commands again, and so (with many caveats), gets the time at which the display happened (when vsync is on). Now I am wondering if this particular option is exposed or available in Godot. In Pyglet, these exact calls are available and this is how Psychopy finds out when the stimulus might have been displayed.

https://stackoverflow.com/questions/2143240/opengl-glflush-vs-glfinish

2. Searching for glFlush yields nothing in the Github for GodotEngine, searching for glFinish gives this -

,

but I have no idea what this means for my use-case.

3. the issue of whether glFinish to "stall" execution is a good idea, was being discussed in 2007 (!) -
   https://community.khronos.org/t/glflush-glfinish/24451/10