Skip to content
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

Add Root body type for collision generation #3355

Open
Shatur opened this issue Sep 26, 2021 · 5 comments
Open

Add Root body type for collision generation #3355

Shatur opened this issue Sep 26, 2021 · 5 comments

Comments

@Shatur
Copy link

Shatur commented Sep 26, 2021

Describe the project you are working on

A third-person shooter.

Describe the problem or limitation you are having in your project

Let's imagine I want to create a physics-enabled object. I have two options:

  • Use the "Dynamic" type for "Body type" in the import menu. In this case I will need to force my artist to merge all meshes into one, because the object will just fall apart if each mesh will has a separate RigidBody3D. Also root node will be Node3D by default, and I will have to create a custom class that exposes the selected RigidBody3D child to apply a force or to get the real translation (because the translation of the parent Node3D will be incorrect).
  • Make the root scene a RigidBody3D type, do not use the collision settings from the import dialog, and create a post-import script that will generate only CollishionShape3Ds for each mesh and make them children of the root scene.

Both workflows above are inconvenient.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose a simple change: add additional "Body type" called "Root". In this case, the generated collision will be added as children to the root scene. This way users will be able to use generated collision for the root scene, the type of which they can select in the import settings (this functionality already available since 3.x).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

We have "Body type" with "Static", "Dynamic" and "Area". I suggest adding a new "Root" option, which will be first in the list, to make it the default, because I think that this workflow is better in general.
In this case, your root scene will represent the actual type and the collision objects will be added as children with no intermediate objects. It will be convenient to interact with it (for example, apply force or take coordinates) and you will also have less objects:

Before
изображение
After
изображение

If this enhancement will not be used often, can it be worked around with a few lines of script?

The user can write his own custom import script, which will add a collision by a special prefix in the name as a child of the main scene.

Is there a reason why this should be core and not an add-on in the asset library?

I think this is a very simple feature that will greatly improve the usability of import workflow.

@pouleyKetchoupp
Copy link

CC @AndreaCatania

An option like this sounds useful, but maybe as a separate option rather than body type? It could be used for Static and Area types as well.

@Shatur
Copy link
Author

Shatur commented Sep 27, 2021

but maybe as a separate option rather than body type? It could be used for Static and Area types as well.

You may have misunderstood me. At the moment the Static, Area and Dynamic options create the corresponding intermediate objects. But the suggested option just attaches the generated collision to the root of the scene.
You can choose any type for the root scene (e.g. you can make it StaticBody, Area, RigidBody or any other). There is a separate option for this, which has already been implemented.
So the proposed option cannot be combined with others, but it can be used instead of all of them. That is why I propose to make this option the default :)

@pouleyKetchoupp
Copy link

@Shatur You're correct, I thought you were proposing to automatically set the node type to RigidBody on the root as well.

If it's just meant not to set any physics node, yes it does make sense to make it a body type.
If #535 was implemented, we could even leave the collision shapes as children of the different meshes for clarity, just without rigid body nodes.

I'm not so sure about making this option the default though, since it requires an additional step to make it work in physics (you need to change the root node to a physics node afterwards). Otherwise it might look like it's not working by default.

The most common use case for this workflow is making static bodies out of meshes, so I'd like to make sure we keep this case straightforward.

Rigid bodies are a bit more of an edge case, generally you set one primitive manually for them instead of using the more detailed mesh, for performance reasons.

@Shatur
Copy link
Author

Shatur commented Sep 27, 2021

since it requires an additional step to make it work in physics (you need to change the root node to a physics node afterwards).

Yes, you are right. But on the other hand, it is more convenient to work with such a node, because in this case it is a physical object. Also scenes will be better organized - it will be immediately visible which physical object each imported node represents (compared to just using Node3D for each model).

@pouleyKetchoupp
Copy link

Yes, you are right. But on the other hand, it is more convenient to work with such a node, because in this case it is a physical object. Also scenes will be better organized - it will be immediately visible which physical object each imported node represents (compared to just using Node3D for each model).

Yeah, I wonder if we could actually change the workflow a little bit and have:

  • Physics body type on the root itself (Static, Area or Dynamic) to get just one body by default.
    (it would make the root node physics instead of Node3D so you wouldn't need the extra manual step)
  • Custom body type on each mesh, with something like None or Root by default
    (this would be used only when mixing body types in the same model, which shouldn't be very common)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants