Replies: 1 comment 5 replies
-
Oh, this topic again. We don't even agree on the discussion category o,.,o. Changing this now would be too much of a breaking change. So, it will be one of those topics that will come back from the grave once there is a Godot 5 announcement. This is what I can come up with for deciding what to use:
※: you can enable detection of static bodies in Jolt. Of course, the requirements might change, or you might run into a bug, and that might force us to reconsider the decision. Static If I have decided something that does not move should move, it is trivial, since I don't have motion code to translate. Similarly, if I decided something that moves shouldn't, I'm removing the motion code. So I don't think this is an issue. Animatable I void it. Beyond the naming issue with which we have to live with. Animating something else and having a character body programmed to follow it solved many issues for me in prior versions of Godot. Perhaps I won't have these issues in Godot 4, in particular with Jolt, but I'm not trying, I'm sticking with what worked. Thus I won't have to consider changing something from animatable to something else, or something else into animatable. Character and Rigid bodies If you need to migrate from rigid to character body, you need to implement impulse and forces. This should be doable (I tried, and could not get torque right, but still). And if you need to migrate from character body to rigid body, your move calls should translate to impulse and forces, which isn't too bad. You might also need to teleport the rigid body, which you can do by calling directly into the physics server, or by changing modes and other work arounds. A teleport method would be welcome. I'm saying impulse and forces to cover all bases, because I recall some differences between 2D and 3D rigid bodies, I do not know if they still stand (I mostly do 3D). I'd wish we had official examples of a character body with impulse and forces, and a rigid body with move methods, so they would serve as reference for people doing these kinds of migration. How can we design it so we don't need that? I would like a "motion driver" type (or the same thing by a better name). That you could add to a physics body. In fact, I would like physics bodies to have multiple "motion drivers", and they get called one after the other. Many of us already do something like this in character controllers. But having it as part of the engine would allow Godot to provide "motion drivers" that have the methods we use to move either rigid and character bodies, and they might call the physics server under the hood to enable features as needed (e.g. allow the body to detect collisions so the rigid "motion driver" can react to them). And we might even have a follower "motion driver" for the animatable body use cases. Note, however, that I don't mean they replace coding the motion in physics process. So you could still program the way you are used to. But making a character behave as a rigid body should be as simple as adding a rigid motion driver, and configuring it. Note if we combine the physics bodies this way, it would also add friction: when you want to add a rigid body and you open the dialog search for rigid... It won't be there. The new node dialog needs improvements We might use a simplified mode. For example, what Miguel De Icaza did: https://blog.la-terminal.net/giv/ We could have the search include the class descriptions or keywords, so we might find stuff even if the name does not match. And we could have some build-in templates, which could appear as children of the nodes, but are not other classes... They are the same node but with some configuration already done for an specific use case and a name that is easier to find for that use case. |
Beta Was this translation helpful? Give feedback.
-
Related to #5274. Pertains to 2D as well, but I wasn’t sure if this qualified in the Core category.
I expect hot debate on this, but I’d really like to see an overhaul to the physics nodes.
The distinction between their features and how they interact is pretty unintuitive. I see them misunderstood constantly. Even the proposal thread for the current setup is filled with debate and confusion.
You have to do a lot of work to port features of one to another if your use case falls outside their specific scope. The majority of my time working on the physics of my game is dealing with this. I’ve spent a lot of time digging through source just to make sense of things.
What we have:
What I’d like to see:
I feel this is more in line with Godot’s philosophy. The current nodes are written with intended use cases that would be better left to the developer to distinguish. I’m interested to hear others’ thoughts.
Beta Was this translation helpful? Give feedback.
All reactions