Feature request -> After- physics_update call

[RepairUnit3k6]

Hi everyone. As you probably know, physics_update call is triggered before node get updated by physics engine. However, sometimes you want to execute code after physics engine updates node. Unfortunately, something like late_physics_update or post_physics_update does not exist yet. I'd love to add it myself but I don't know c++. I think it will be better than messy workarounds. Thanks.

[uzimonkey]

What would be the use case for this? The idle time occurs right after the physics engine is iterated, so whatever you need could be put in _process. The only thing this doesn't cover is frames where more than one physics frame occurs.

[Beliar83]

One use case for this would be for a data driven game.

Before a physics udpate you would update the objects from the stored data, and afterwards you would update the data to the the values that were calculated by the pysics.

[KoBeWi]

func _physics_process(delta):
    stuff_before_physics
    yield(get_tree(), "idle_frame")
    stuff_after_physics

^ Wouldn't this work?

[Beliar83]

I have not worked with yield, but reading about it, I am not quite sure if that would do what I want. If the data was changed the game state needs to be updated to it before any physics processing is being done. After the physics is done processing the data needs to be updated to the new state to keep them in sync.

[KoBeWi]

So my code should work (assuming "idle_frame" is emitted after physics_process).

[Beliar83]

Yeah, after thinking about it a bit more it might actually work.

[huhund]

A late physics update method would be super awesome.

Having made several commercial games I have seen many use cases where this is beneficial. E.g. this is what you commonly want

1. pre - apply force/velocity to bodies
2. step - step physics simulation
3. late - get new transforms for objects, react to collisions 4.1. render - interpolate between old and current position 4.2. render - interpolate between old and current position 4.3. render - interpolate between old and current position

---

If you don't support "late" update it will look like this.

1. pre - based on old transforms, react to collisions, apply force/velocity to bodies
2. step - step physics simulation 3.3. render - unknown position - no interpolation 3.3. render - unknown position - no interpolation 3.3. render - unknown position - no interpolation

Is you can see, there is not chance to react to the result from the simulation before rendering. Maybe your character entered a death-zone and should be killed. You also have one frame extra delay in your rendering - you don't know how to interpolate your render frames.

---

Or like this? Stepping happens before physics update

1. step - step physics simulation
2. pre - get last transforms for objects, react to collisions, apply force/velocity to bodies 3.1. render - old position - velocity not applied yet 3.2. render - old position - velocity not applied yet 3.3. render - old position - velocity not applied yet

Hence, your rendering will always be one frame extra late. Interpolation also not possible.

The common way of implementation action games is processing your logic at a fixed frame rate "_physics_process" and process your graphics at variable frame rate "_process". Therefore a defined order of execution helps. Order of apply attributes, stepping simulation and reacting to collisions is important.

---

Does Godot have a specification for when stepping, collision response and rendering should happen?

I have noted that e.g. GodotPhysics vs Bullet physics work differently. GodotPhysics uses _physics_process as a "late" call. While Bullet uses it as a "early" call. However Bullet has a bug where velocity is applied only next update. So in practice the stepping is 1.99 frames late - I assume this is a bug.

---

Any last question, how does this Patron thing work - can I vote on this with money? I could spend a few bucks on this great project.

[sean256]

Something like this could help a lot for a project I'm working on. I need a way to calculate all forces that were applied to an object and this just might make that work.

[ghost]

This would be nice in gameservers situation when you need to update all of the entity positions first before sending the updated states to all clients.

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!