-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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 documentation should teach users to set parameters before adding nodes #45638
Comments
What about setting |
@Xrayez If you really need to, you can set the transform after adding objects, but you just won't get the best performance. So I guess the message documentation can teach is "set parameters before adding objects whenever possible". That said, one way to handle this scenario would be to add a property to disable physics on physics nodes, so that you would have a way to disable physics, add to tree, set everything you need, and then enable physics again to add it to the physics world. I don't think it would be complicated to implement, but it's a bit outside this issue's scope and it would need a proposal. |
IMHO the property trick isn't needed, but I'm thinking the workaround of "disable-add-set-reenable physics" could be documented? |
Well the "property trick" is needed to perform that workaround. You can't disable physics on a per-node basis as of now. |
You can set collision shapes to disabled, I thought that's what they meant. |
@Zireael07 I guess you can disable shapes to work around performance problems in this scenario but it's a bit hacky (in this case the physics body is still simulated but it collides with nothing). This trick should generally work ok, but it's difficult to predict what undesirable side effects it might have in some situations, since e.g gravity and forces would be still applied. I meant to add a way to globally disable physics on an object, which you can't do at the moment and might be useful in other scenarios as well. It would be much clearer and well documented because it would have no possible side effect in physics. |
This follows the recommendation from godotengine/godot#45638
This follows the recommendation from godotengine/godot#45638
…ng it to the scene tree This follows the recommendation from godotengine/godot#45638
…ng it to the scene tree This follows the recommendation from godotengine/godot#45638
…ng it to the scene tree This follows the recommendation from godotengine/godot#45638
…ng it to the scene tree This follows the recommendation from godotengine/godot#45638 (cherry picked from commit 3f0e91a)
…ng it to the scene tree This follows the recommendation from godotengine/godot#45638
Godot version:
3.2.3
OS/device including version:
Windows 10
Issue description:
Based on #45598.
This issue is Bullet specific, but it's generally better to set physics objects parameters before adding them to the simulation in order to get the best performance.
Documentation and tutorials should reflect that so new users can be taught good practice, but it's not the case at the moment.
Example where bad practice is shown as an example:
https://docs.godotengine.org/en/stable/getting_started/step_by_step/your_first_game.html#main-script
There might be more examples of this, so it would be good to make a pass on checking tutorials related to physics. Documentation could also mention it somewhere, but I don't know if there is already a good place for this information.
Steps to reproduce:
n/a
Minimal reproduction project:
n/a
The text was updated successfully, but these errors were encountered: