-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reorganize physics body nodes #2184
Comments
See also #1384. |
@Calinou This proposal supersedes #1384 because the aim is to keep the good usability of having separate nodes. Many Godot users who make 2D games (if not most) don't need to deal with the extra complexity of RigidBody, which would make things a lot more confusing. Still, having move_and_collide in PhysicsBody gets you halfway to where that proposal wants to be (the rest you can reach with some script, and we can provide this script if needs to be as mentioned in my proposal). |
How does "you can do everything with a RigidBody" solve "because some functionality overlaps"? If Can you give some examples of games and how they would make use of these nodes better than the existing ones? Remember, this is the purpose of the "Describe the project you are working on" section. |
StaticBodies have a very specific meaning in every physics tutorial. In that, they are static. They don't move, at all. They are environment pieces that are never supposed to move. If you start making StaticBodies that aren't always static and sometimes kinematic... you're forcing a layer of confusion you're trying to, somehow, avoid. Godot is currently using a pretty standard and basic convention that almost all engines follow, and that can be found in generalized physics tutorials. |
I'm also kinda confused, as a simple user what I get from this proposal is this:
I'm sure I'm getting a lot of things wrong, but this is the best I can do with the info in the proposal. |
@aaronfranke, @Janders1800, @LillyByte I think the misunderstanding comes from the fact of what simulate_motion (or infer_velocity, as I would like to rename) does. A body is static when it can't be moved by other physics bodies. It doesn't mean you can't move it yourself from code, you sure can and you always could (set the position manually and it will move). It works like this in any physics engine. So imagine you have a moving platform. A RigidBody or a CharacterBody won't do because they move by themselves. You need something that can't be affected by other nodes but that you can position yourself and that is exactly what a StaticBody is. Now, there is a problem here which is that when you move this static body left and right, all you do is change location. Objects over it will not be moved and stay in place. At much they won't fall. For a moving platform to work, you need this static body to kind of infer what the linear and angular velocity is based on the movement you did from your script. This would allow it to carry characters and rigid bodies with it. To do this, the ability to "infer" the velocity is required. It checks where the object was the previous frame, where it is now and the time elapsed. Based on this it computes linear and angular velocity and any body colliding against it will receive it and move along. This solves the problem. The issue here is that doing this is kinda expensive and you don't need it for most cases of static bodies, so it needs to be switched on when you need it. This is why it is an option. So, in Godot 3.x, KinematicBody was literally the same as StaticBody unless you turned this option on. Turning it on also did some extra magic like actually moving the node one frame later, this way it solved the sync problems (when the objects being carried were one frame delayed due to physics being processed after you moved it). With move_and_slide out of KinematicBody, then there is not really any reason to have KinematicBody any longer. It does the same as StaticBody, so the most logical step is to just add the motion inferring option to StaticBody. |
In general physics engines do KinematicBody as variation of RigidBody with zero mass. I'd be pro this change if multimode RigidBody could actually merge properties of all movable bodies as modes and support all the APIs to be moved nicely as character, because that allows for nice character controllers like Uncharted one. |
Also would be nice if VehicleBody inherited that behavior. |
@slapin thats kind of what will happen, RigidBody can do everything all the other nodes can do with the excpetion of CharacterBody (which is kept separate to avoid making it too confusing to users, as RigidBody has lots of options and properties), but you can write your own character code using move_and_collide and RigidBody rather easily if you need. |
KinematicBody doesn't move by itself either. Are you saying that CharacterBody will, for example, have gravity by itself? Or it would be pushable by RigidBodies and other CharacterBodies out of the box? |
Yes, one of the ideas in CharacterBody is either make it move by itself, or have a single function move() that you are up to call anytime in either process or physics process, and most of the arguments to move_and_slide will become properties. |
Would be nice to have interface to RootMotion for CharacterBody too. And ability to receive momentum. |
This is my current understanding of this proposal.
|
@aaronfranke That is right |
To me I think it would be less confusing to have:
|
Instead of having special nodes for StaticBody, why not use RigidBody's modes for everything, except characters? Also, I would name the new node just Character, it will of course extend one of the PhysicsBody, but I wouldn't call it a "body" in case it gets highly specific character properties (like mouse looking, for example). |
@reduz Where does this leave concave collision shapes? Currently, they only work on |
@aaronfranke That doesn't work (it should e documented at least). You have to convex decompose that. |
@reduz What do you mean it doesn't work? There's a resource just for it: https://docs.godotengine.org/en/stable/classes/class_concavepolygonshape.html and no decomposing is necessary to use it. |
Why not leave two nodes: RigidBody for everything (fixing all current bugs) and CharacterBody (the same as current KinematicBody, but with corrected interaction with RigidBody) |
I have no objection to simplification. However, for moves using CharacterBody, I would like to see the following Strict on_floor
Strict stop_on_slope
These are all things that are needed to make a character move naturally in a typical 3D platformer game, but as of Godot 3.x, it is impossible to implement all of them. |
@TokageItLab I think most of them are implemented in my 3D platformer demo: |
@Janders1800 I played your project but the player character is slipping on the slope when I put the slope in the scene. All of the things on my list must be done at the same time. We are not all going to make a game without slopes. Also, the games with low-height steps or without the cliff catching feature, the fuzzy judgment of on_floor can be a problem. It would be silly to take a custom on_floor judgment with timer processing or judging by amount of velocity change, but in 3.x, that's the only way to do it. If it will be simplification, we should avoid implementations that require such custom on_floor judgment to be written in GDScript. |
I have to say I am pretty confused with 'simulate_motion' and 'StaticSimulated'. So kinematic types are pretty much removed? And the solver will now solve static types with velocity constraints when moved? I feel like there's benefit to separating static & kinematic. I have to say that eventually i just gave up and am just using https://github.com/briansemrau/godot_box2d for 2D which is brutally clear about what body types do what. Has saved me a lot of hair. |
So if PhysicsBody is the new KinematicBody and RigidBody derives from it. if so I support this |
Hi, is this supposed to be in the 4.0 version? Or in 4.1, etc? |
@AttackButton This is planned for 4.0. |
Not too certain on naming, but having used KinematicBody as well as VehicleBody (which inherits from Rigidbody) I would love to have a way to combine the ease of use that kinematic offers with the ability to add impulses/forces that rigidbody has. |
The proposed node organization makes sense to me. There are still the same distinct modes for the physics simulation, and it will allow new use cases and features. I'm just adding some comments on naming I had posted only in the chat before:
|
I am at least as confused by this proposal as much as I'm confused about the current implementation. Possibly more. So far I've used KinematicBodies for moving platforms. Why? Because they are moving. Why rename KinematicBody to StaticBody and not the other way round if the resulting node is supposed to move at least some times and check for collisions while moving? If a node named "CharacterBody" is supposed to fill the gap the removal of "KinematicBody" leaves behind, I already see myself having to use a CharacterBody on countless game entities that are not a character at all, all the time ... why? Why not just keep the Kinematic body? Sure the KinematicBody could use some improvement and there are a fair share of bugs. But all this time (almost 3 years) I've been using Godot, the biggest single one issue which does not seem to be included here: A seamless transition from KinematicBody like user control, to RigidBody behavior. #1384 Seems to go into this direction, but is not a solution either as it proposes the removal of KinematicBody all together. @Bropocalypse is absolutely correct about asking users to first disable a whole range of functionality and not touch others, is anything but user friendly and extremely counter productive if the goal is to simplify. |
No functionality has been removed. Here's how nodes work with this proposal implemented: Also, all nodes can now use
It's hard to find names that are clear for everybody and match standard conventions, but if needed, things can be refined before 4.0 is out. The new naming convention follows this pattern consistently:
I agree the name |
Most people will assume static bodies cannot be moved, regardless of whether it's actually the case... so I would look for some synonym... Non-dynamic? |
Now I'm thinking maybe |
I think StaticBody is well established term, why invent a new one? Most
engines allow limited movement of StaticBodies in non-dynamic way,
so that won't surprise anyone.
…On Sat, Jun 12, 2021 at 9:22 PM Camille Mohr-Daurat < ***@***.***> wrote:
Now I'm thinking maybe ObstacleBody instead of StaticBody could be more
descriptive since it's used for walls, floor and (moving) platforms.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2184 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABPU6QTCHW4UWKQBWTBILTSOQXZANCNFSM4WSEWWKQ>
.
|
Thank you for taking the time and trying to explain!
Why can't we have these as nodes? With exactly these names and descriptions? This would clear up any confusion I can think of. |
@slapin It may be an established term, but it may be dated and not the best way to describe what the node does. Currently, users are confused that a @golddotasksquestions |
But by changing the term you will confuse much more people.
…On Sat, Jun 12, 2021 at 10:07 PM Camille Mohr-Daurat < ***@***.***> wrote:
@slapin <https://github.com/slapin> It may be an established term, but it
may be dated and not the best way to describe what the node does.
Currently, users are confused that a StaticBody can be used for a something
that's moving, so if that can be improved it will be for the best.
@golddotasksquestions <https://github.com/golddotasksquestions> Static,
Kinematic, Dynamic describe the modes of functioning within the physics
engine. Nodes are functionality-based and don't necessarily match these
modes one-to-one. RigidBody is meant to switch between any mode, and
StaticBody can be used for both Static and Kinematic behavior.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2184 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABPU2VRF4Q3HXKATRY35LTSOV5PANCNFSM4WSEWWKQ>
.
|
Honestly I don't see a problem with these names. They seem to me a lot more clear than what is proposed and the fact that they represent the functioning within the physics engine can only be a plus. I still don't see the use for making the StaticBody something you should move. If it would be up to me we had: StaticBody KinematicBody
|
@slapin Existing users will have a better description of the behavior of the nodes. New users / beginners will benefit from less confusion due to intuitive naming. This change would have to come with proper documentation and a simple migration guide. @golddotasksquestions In your scenario, For clarity, here's a breakdown of the different use cases: - - - |
@ pouleyKetchoupp I've crossed it out and swapped the names, even though I would think the reverse would make a lot more sense to a bigger group of people who come in touch with Godot. |
Forgot to close before, implemented in godotengine/godot#48908. |
Describe the project you are working on
Godot
Describe the problem or limitation you are having in your project
Physics nodes can be confusing in Godot, because some functionality overlaps and intentions are not clear. Additionally, kinematic body serves several goals at the same time, which makes it difficult to hack around for specific higher level character behaviors
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The goal is to reorganize these nodes to make it easier to use and easier to hack them for specific situations.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The new nodes will be as follows:
KinematicBody: Removed.Additionally, as I believe there are too many corner use cases for characters we can't cover, we should provide versions of CharacterBody in script form, so users can tweak everything they want if they need, or even make it inherit RigidBody.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, this is core.
The text was updated successfully, but these errors were encountered: