What is the difference between integrate forces and fixed process?

Question

If I am going to write code for platformer which function should I use?

Answer 1

Integrate forces exist only for nodes extending rigid physic bodies. And its purpose is only for adding forces to the body.
process and _fixedprocess are all-purposes methods existing in all nodes and that are called regularly. Since fixedprocess is always called exactly every x seconds, that allows you to do very precise calculations (but I never encountered such need until now).

Which one should you use is really up to your preference. But if you're using a rigid body, it is usually better to use the integrate forces. You can even use both on the same node, but that would be unnecessary since both are called very frequently.

Answer 2

If you're not using RigidBodies, or you're not interested in doing very specific spatial queries with the physics state objects, or don't plan on overriding the built in integration, then you would generally just stick with fixed_processing. It's a method that occurs in the fixed time step and alongside the physics.

Comments

Thanks for both answers but if I understand correctly. It is recommended to use integrate forces when my character is rigid body because it lets me to more modify physics. On the other hand If I want some kind of simulation I should use fixed process right?

---

The benefit of integrate forces is that is passes you a PhysicsDirectBodyState object in it's parameter.

Which gives you access to this: http://docs.godotengine.org/en/stable/classes/class_physicsdirectbodystate.html#class-physicsdirectbodystate

If it's not a character and you're happy with the default behavior of the RigidBody, you'll be fine with fixed_process. However, if you need very particular motion, you'll want to override integration and specify the forces yourself. One of the platformer demos uses a RigidBody character, it's worth studying the code and the node properties.

---

I have a prototype of a little excavator, but the arms and the big thing in the fron go through the floor (because I'm rotating them by code).

if I use integrate_forces will that still happen? Or will I have the rotation and the collisions at the same time?

---

@rredesigns

It's not an option you just turn on that does things. It is a place for you to access the physic's state of a RigidBody and write your own integration based on that information. So you can get the collision results, but then you will write how it should handle that.

Without any working knowledge of your problem, I suspect it could be based on the speed of the rotation and the collision detection method being used. Maybe try setting it to continuous collision detection. I haven't looked very far into the physics code, so I don't know what they're using, maybe it will switch to some form of conservative advancement. That's purely speculative on my part though.

I've only done a small amount of reading into this area, but it doesn't appear as if there are any perfect solutions, at least nothing optimal for games. Every method has some sort of trade off or constraints (performance vs. accuracy), and you as the developer must know them and decide what best fits your game, or how you can design around them. (IE - Sometimes thicker walls, or extra colliders that give hints are what is needed for a particular problem.)

---

Well, the scenario is quite simple. When the arms or the shovel at the end reaches the ground, then in theory they would collide and push the whole vehicle back, but in my case the moving parts go through the floor.

So the actual question is, suppossing that is due to my code overriding the physics simulation, if I use integrate_forces will that still remain? adding the rotation there would make no difference and still override physics? In any case, is there a way to simulate the real behavior I need through the physics engine or do I have to code all the action-reaction system?