Separate vertical friction/damp from horizontal friction/damp

[viniciuscsg]

Version 3.1.rc3official

For RigidBody2D and RigidBody, it would be much better to have separated properties for friction and damp on a per axis basis, instead of global values. Most typical platformer games require very different friction values for vertical movement when pressing on a wall collider (normally lower or none), compared to horizontal friction regarding running and deceleration (usually much higher).

Of the five most common views for physics games (top down, 3/4, side view, isometric, and perspective 3d) only strictly top-down games wouldn't typically use different friction or damp values for horizontal and vertical movement and collisions, so it would be a good idea to expose the axial components of friction and damp. Gravity does not suffer from that, since it is already vector based, and you can change it on the default settings.

Work arounds obviously exist, either by code or on the IDE (using different one-way collision nodes for wall friction and floor friction occupying the same space, which makes it harder to model levels and consumes more resources). Both are less practical than simply exposing the x and y components of the friction and the damp (or the x, y and z components in 3d) and unnecessarily convoluted, as the intended use of the physics engines is precisely to make the development process faster.

[lawnjelly]

Broadly agree with this, however I suspect that what is exposed in Godot is probably pretty tightly coupled with what features are available in Bullet. I had a quick look but couldn't really work out whether Bullet supports this.

As an alternative to changing parameters of wall / floor models you can probably tweak this kind of thing by writing your own _integrate_forces, e.g. multiply your linear_velocity by e.g. (0.97, 0.99, 0.97) on each physics tick, depending on whether you detect your character as being in air or on ground etc.

[ghost]

The concept of a "rigid body" is universal and primarily used for simulating Newtonian (i.e. realistic) physics, so modifying it to benefit a specific genre of game (platformers with wall jumps) is a terrible idea.

[viniciuscsg]

I hope the physics engine wont forbid this. I respectfully disagree on the Newtonian physics argument. The concept of a rigid body within a game engine like Godot is to simulate physics only in respect to purpose of the engine, which is to make games :). Not only platforms would benefit form this. As mentioned, basically any game with physics which is not using a strictly from above view could benefit for this extra level of control, and implementing it (if possible) wouldn't hurt realistic simulations, so it is not really a trade-off relationship to favor a genre in detriment of others.

I would even say that enabling useful jumping behavior or gamey-ish vertical pushes is probably among the most important use-cases for even having a physics system within a game engine in the first place, and should have precedence than, say, making astronomy simulation and the sort, but indeed, separating the axial components of this forces, if possible, wouldn't change or detract anything from a standard realistic simulation if you ever wanted to make one with Godot.

If I understand it correctly, removing this limitation would make it easier to have Rigid Bodies character controllers quickly working as expected for most games (in 2d and 3d), and would circumvent a lot of the workarounds taken in the RigidBody Character controller demo, like disabling the integrator, factoring in your own friction etc, just so a character wont be stuck on nearby walls while jumping because the wall/floor friction is omni-directional. If possible, I think it would be best to have axis based friction, damp and bounce (gravity is already vector based).

[ghost]

Well, consider these scenarios:

• Damping: best case scenario is you'll be able to control maximum fall speed separately from maximum lateral movement speed. Even then, the maximum speed will correlate to something unrelated to the damping value given (which is a value between 0 and 1...)
• Friction: if vertical friction was low and lateral friction was high, what would happen if you decided you wanted sloped surfaces? Movement speed would be increased—the amount determined by how steep the slope was—even when moving up a slope.
• Bounce: ??? i don't know what this would be used for

Not only would this not give someone a consistent and reliable character controller, but it would cause issues and inconsistencies that would have to be addressed by code anyway.

Also, about the whole "gravity is a vector" thing you mentioned: I don't really know how that sets a precedent for what you're proposing. It's completely unrelated (and would complicate things if it was).

Getting custom movement logic right is deceptively difficult, and having to code stuff yourself is an unavoidable reality when dealing with it. The resulting code can wildly vary depending on what you're trying to do, so there isn't much room for "one-size-fits-all" solutions (though move_and_slide_with_snap() gets pretty close). Instead of ignoring this reality and asking for these near-sighted workarounds, it's best you see this for what it is, grit your teeth, and learn what you need to deal with it. This is directed to you and anyone else you're supposedly trying to help.

[viniciuscsg]

Good point on the friction on slopes, that one eluded me, I can imagine even more unforeseen quirks that were not apparent for me at first, thanks. I am well aware that any refined movement logic entails complexity that can only me nailed down by coding, and in the projects that this aspect of physics has posed a problem I have already solved it, either with code or by using jointed nodes with different physics materials. Perhaps that last one is the proper lazy way to do it on the editor.

However, I am indeed very favorable towards having quality of life stuff such as move_and_slide whenever possible, and figured this could lead to easily modeling a similar experience with Rigidbody nodes, getting the free physics as a bonus. My proposal was solely on the intuitive assumption that dividing these properties by axis could allow many creative ways to tackle varied needed behaviors by just setting things up in the editor or just changing a few properties by code (unidirectional dampers, vertical-only or horizontal-only trampolines, multi-use wall/floor cubes, etc), without really getting in the way of anything else. Godot already has a lot of such smart tricks available, such as simply making conveyor belts with Staticbodies by setting a linear force to affect other nodes, so I thought this would be on line with that sandbox and quick setting ethos.

[KoBeWi]

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!