Physics engine: Raise the priority on blocking issues/add a goal for the next major release

[fabriceci]

Describe the project you are working on:

I mainly work on a 2D platformer and also do tests on a 3D one.

Describe the problem or limitation you are having in your project:

I saw no focus/plan for the next major release about the physics. We (will) have some advanced features, but there are still very basic issues pending with physics.

For example, it's currently impossible to make a clean moving platform in 3D, in 2D the situation is better, not with all setups.

Another example is the common problem when you want constant speed on a slope, even if it's not physically accurate, it's the default behaviour in many games. The solution proposed with the Raycast Shapes is not a good one, because that leads to problematic behaviour (pass through walls/unwanted collisions because the ray doesn’t collide with environments). I was able to workarounds this in 2D with move_and_collide, but you lose the moving platform support and the snapping. In 3D, I saw in this Gonkee's video, he faced similar issues and was forced to abandon a project.

(FYI: I checked the 2D platformer example, and the code leads me to think that the developer who wrote the code, was aware of those problems. He bypassed those issues by implementing behaviour "not acceptable" in real situations (no acceleration & stop immediately if there is no direction), but even with the behaviour is still not perfect, there is a bit of sliding when the player land in a slope)

I also feel that move_and_slide should be a bit reworked: move_and_slide_with_snap seems redundant and some parameters like stop_on_slope is strange. If you check the 2D platformer example, you need to change the stop_on_slope value when you are in/out a moving platform without slopes… that is confusing.

As the physic engine is one of the areas where users are very depending (of course all game not rely on the same way), I think put extra energy to stabilise the api should be a good move for Godot's future. It will also help to increase the quality of games that rely heavily on it.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

This is an open discussion because I have no ideas how the physics is coded and so, not the best placed to provided solutions. I also not check all pending issues, I just give some examples of blocking ones I encountered.I only have suggestions:

• Raise the priority on all major (blocking) physical issues (where no workaround is available).

• Set a goal for the next major release (and take that chance to stabilise the api)

• Maybe move_and_slide and move_and_slide_with_snap should be merged in one function. (If many parameters seems to be annoying, in the future, with named parameters, this will no more be an issue)

• Offer the ability to have constant speed in slopes in move_and_slide, it’s a very common behaviour on games.

Hope this thread can help, to the devs, thanks for all your good works.

[bemyak]

I'll add my two cents here. I'm also developing a 2D platformer game and continue to face bugs, limitations and finding some areas begging for improvement, polishing and better UX. I have to spend a lot of time fixing it, looking for workarounds, write tooling and fixing engine itself. That is not very fun and sometimes feels like procrastination (but quiet educational one) :)

But also I realize that Godot is being developed by 3 full-time employees and around maybe 10 regular contributors, who are donating their personal time. They even don't have enough money to support the third employee, according to Patreon. And they have 5500+ issues, 600+ open pull requests and 400+ proposals they have to deal with. This is just an insane amount of work, but they are handling it somehow (kudos to @akien-mga and others, awesome work).

If I'm understanding it correctly, the priority of things to work on is the following:

1. Things that just needs to be done to support current technologies and to stay a competitive engine (Vulkan support, because OpenGL is dying and so on)
2. Things that patrons on Patreon voted for
3. Gihub issues
4. Everything else

So, the easiest way to escalate your issues is to support developers :)

I agree that with growing user base it might become vital for Godot to improve quality, but I don't think this will happen until 4.1 at best (sadly). 3.2 was aiming to become a stable and polished release, but it still has several issue which were not addressed yet. Hope they'll be fixed in 3.2.X.

[fabriceci]

English is not my native language, maybe the purpose of this thread is a bit fuzzy.

First, again a big thanks @bemyak, your PR fix one of the biggest issues with vertical platforms. I'm aware of the situation, they do an unbelievable work, my intent was not to push them or try to fix my issues first. Sorry if this is the feeling the post gives.

I support the project on Patreon and helped in translations, unfortunately I have currently no skills in C++. The amount of time to learn the language + enter in the physics part of the project (knowing that I'm not sure I have the skill/math), means for me, no more time to continue my project currently. I not against a bug bounty, I'm aware that many thinks that their issues are "high priority". If the problem is widespread, the bounty can be quickly growing.

Like you said they are currently overwhelmed by the issues despite their awesome job, my purpose was:

1. To show that there is still common stuffs that are considered as solved/workaroundable like the constant speed for the slope that is not.
2. It might be good, given the number of issues, to further prioritize the issues.
3. If adding the constant speed support is a breaking change or the API should be merged/clean like I suggested, the next big release is maybe the good time (because they are one of the main functions)

[Xrayez]

I don't see a problem discussing things which bother you the most. If you do talk about it, there has to be a good reason (and there are).

Another issue which I personally think deserves attention is godotengine/godot#12353. Dealing with this for 3 years now, but gladly there are workarounds (and even a PR which can be manually merged to existing projects, unfortunately merge conflicts pop up quickly enough). 😅

There are quite a bunch of existing PR's to fix the issues out there. Unfortunately, there are little to no people who could volunteer to test those, otherwise maintainers risk breaking existing projects (people may as well implemented their own workarounds around those bugs already). Gladly we're in 4.0 territory now so please don't be afraid to break stuff, it can't go worse with existing bugs. 😝

[KoBeWi]

I was able to workarounds this in 2D with move_and_collide, but you lose the moving platform support and the snapping.

It is possible to have move_and_collide both with moving platforms and snapping, but you need to implement them yourself. For moving platforms, you have to introduce "external velocity", which can be retrieved by using collision information (basically, you collide with platform, so you have access to the object, so you can manually get its velocity), and using final velocity being the sum of your normal velocity and external one. For snapping, you have to call move_and_collide multiple times per tick, checking movement in various directions and "teleporting back" the character if it shouldn't move. It's hard to get right and requires numerous "hacks", but it's possible.

I did this in 2D, but I bet in 3D it's possible too. (not saying this shouldn't be fixed ofc)

[fabriceci]

@KoBeWi

Thank you for your answer, I not wrote that in the topics but it's what I did first by « syncing » physics's update for my player and the platforms and this is working very well.

For snapping, you have to call move_and_collide multiple times per tick

I had a strange behaviour, this quote seems let me think that is normal, can you confirm? Indeed each time you call move_and_collide when you are against a slope (even a hard one), instead of stopping the player (because he collides), it will move a little bit, and so will allow to climb a slope, seems weird.

To those interested, I ended up by using move_and_slide, to control the slope speed, I convert the velocity according the slope, and I handle the snapping by applying a force at the inverse of the collision normal. That's enough for my need but that's not a solution for all cases.

(But this not solve the points of the topic)

[Calinou]

This particular proposal can be considered resolved now that Camille was hired to work on the physics engine.

Please open separate proposals for features asked in OP (after searching for duplicates). Small, focused proposals are easier to track than proposals lumping many things together.