-
-
Notifications
You must be signed in to change notification settings - Fork 21k
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
Physics 4.0 #43073
Physics 4.0 #43073
Conversation
508f6a7
to
0a2da83
Compare
I'm all for starting a discussion about refactoring, but this PR and the proposal need to be clarified, especially since they are meant to discuss major changes in the API. The original proposal doesn't have a consensus as for now, and from what I can see this PR doesn't really implement things the way they are described in the proposal. You need to take the proper steps before starting to discuss the implementation:
|
Well, i found the idea of making all rigid bodies is a really, really bad idea. as the other said, there are totally different things and need different approaches. Instead i think the point should be improve the usability of kinematic bodies first. Controlling kinematic bodies is one of the core elements of most games, but in Godot is a really painful task. |
@yosoyfreeman Currently, a godot/scene/2d/physics_body_2d.cpp Lines 1262 to 1263 in 6328f7a
godot/scene/2d/physics_body_2d.cpp Lines 856 to 857 in 6328f7a
The commit "Collapse PhysicsBody API: Make everything a RigidBody" simply removes this obfuscation, and makes the KinematicBody specific functions available to RigidBodies in Kinematic mode.
|
Then calling the node a "Rigid body" (even as a class name) would be misleading -- especially if a setting causes it to no longer act as anything of a Rigid body. I would also argue that this would become more confusing for beginners if the documentation had to list functions that could only be used under certain modes. (P.S. I have to agree with yosoyfreeman, this PR title isn't the greatest. The PR is not so much "The next generation of physics in Godot!" as it is a refactoring of the physics nodes. Perhaps you could update the PR title to reflect that?) |
In my opinion, one of the points of godot is the Node system, that allows you to have small pieces that perform a specific function. Kinematic bodies are mainly used for characters, and currently move_and_slide provide slide, floor detection, snapping etc (not in the current broken state). I think it would be a great idea to expose the floor vector, snap vector etc to the kinematic body (leaving only one function to slide the bodies) in terms of unify things, i think this kind of things could be exposed on the rigidbodies too. Covering the necesity of some functions, making it more clear to the end user and still avoiding character controllers ( as i understand that the team does not like character controllers). I hope my opinion is clear. i apologize for my poor english. Also if i did something wrong. Im so new to open source/github and stuff. have a nice day. |
As noted in #30311 and #42368, the current And... I'm skeptical about the need for |
I think there is no necessity for a characterbody. If you create a characterbody node, you will need another 4 nodes, kinematic and rigidbody character body 2d and the equivalents for 3D. Also, the current problem is no confusion or lack or organization. Indeed, merge kinematic body into rigidbodies and add 4 new node will only make the whole problem bigger. Also, there is no logic reason to start changing or adding this kind of things when the current problem is that there are not solid ways to deal with slopes and snapping. Part of that problems seems to be the physics implementation itself at reduzio says, the other part of the problem is that the moving algorithm does not work. I think instead of that, the focus should be on fixing the physics regressions and work on the movement function itsealf for kinematic bodies. And if its possible to provide a similar approach for rigidbodies. That should keep things clear and intuitive and extend the use of the physics bodies (dynamic or kinematic) for using that functions not only for character, but for all kind of moving objects (like projectiles that snap to the ground, etc). if not, you should use a characterbody to create that kind of super generic moving objects. And i find that messy. Nice day. |
There are currently several
We have to choose one between these two. @madmiraal explained that the current implementation of |
Firmly agree with this one. The idea of merging everything into one node really doesn't sound like in the spirit of Godot. |
Can I change a RigidBody2D's linear_velocity very often? I mean is it will performed very well like KinematicBody2D? For now, this is not recommend, guess there may be performance issues. But I really need this cause a KinematicBody2D does not collide with each other(not just interact with it like with StaticBody2D) Maybe only solution is custom_integrator? |
If you want behavior that's closer to KinematicBody (no automatically applied gravity), you need to enable |
So, as far we discussed here i think we agree with a few things: -Simplify Rigid bodies (The current modes are just combinations of different common Rigid bodies configurations) -Reforce Kinematic bodies and movement algorithm (work on a functional sliding algorithm and expose things like snapping, floor vector etc on the kinematic bodies ) This also should be more clear and effective than integrate a new character bodie (wich is a much deeper thing and should not be necesary with correct kinematic physics) |
@yosoyfreeman honestly I find this kind of excessive, IMO the So, I propose so split all of KinematicBody's utilities(move_and_slide, floor snapping, etc) into a specialized child node, which could allow more uses and implementation made by the user with only what they want. Edit: Made my intent clearer |
I think i Am not explaining well. Sorry for my English. I was saying that the Kinematic body should stay as a separate node. Personally i Don't get the point of creating nodes for the movement functions. A Kinematic body without movement functions is in fact a static body. As for the character controller node i still think is Unnecesary and no really posible right Now. The current Kinematic body movement is not working, so anything that inherit from the is going to be a work around, wich is what we are trying to avoid. Again, sorry for my poor language. |
Don't worry, I got what you mean and I think I explained myself the wrong way. I too think that KinematicBodies should stay separate from RigidBodies, but I also think that all utility(not essential) methods are excessive and should be moved in a separate extending node.
I'm not saying to remove all of its current methods, only all of them that aren't strictly necessary. Let me explain:
Yeah, currently some core behaviour of tl;dr: I'm not saying that all of the utilities inside a
You're actually pretty clear and understandable. I'm not a native speaker either, so the issue probably comes from my side. |
Okay i think i get your point now. My biggest fear with renaming "KinematicBody" to "CharacterBody" is that a kinematic body can be used as much more than characters. For example, they are used frequently to create platforms, obstacles and any kind of object with a specific movement, such as bullets, props and other things. So we would need another node (characterbody). But in my experience trying to offer an all in one character objects is extremely difficult due to the immense differences between games. I am not against the creation of a character node, but i think that should be the next step on the chain. Thats why i said that we should focus on "fixing" the current physics issues and the sliding method. (Andrea catania did an awesome implementation with bullet) but maybe a simplier method. Once we have a working kinematic body core (Movement and snapping) we will be more ready to approach more specific things like step offset and where to put them (on a character body or as separated nodes, or inside the kinematic body) |
Exactly, that's why I proposed not to rename it, but to create an extending node( |
This PR is part of implementing godotengine/godot-proposals#1384 and the changes that @reduz wants to make to Physics for Godot 4.0.
However, it's important that we first agree the way forward. Therefore, I've created this initial suggestion as a draft PR. It is by no means complete. Instead, it is designed to generate the needed conversation.
The commits currently included in this PR: