Add scene-wide collision settings for imported scenes.

[SaracenOne]

Supersedes #70256
Long overdue taking over of this PR which I agreed to do but kind of forgot about. 👀

Reopening it now due to recently realizing the extent of what a massive usability slog it is for users to manually have to set individual collision settings for each individual mesh, which is pretty bad if you're, say, wanting to rapidly prototype a complex character controller in a variety of 3D scenes. As far as I can tell, the way that the enums are set up should mean there is no backwards compatibility breakage with existing projects; imported scenes which have physics settings set to off should now be set to default, which uses the scene settings which is also off, so it should all line up fine.

This PR makes the following changes to the initial implementation:

• You can now select any of the valid shape types avaliable for individual mesh nodes as a scene-wide default option, including convex decomposition, trimesh, or various primitive types. All decomposition and primitive settings are also contextually exposed.
• You can choose default physics materials, layers, and masks too.
• The PR has been fixed so that visualization of scene-wide collision import options actually appears now.

[Calinou]

Tested locally, it works as expected.

I'm not sure if there's a lot of use to the primitive box/sphere/cylinder/capsule colliders as a default though, given scenes made of multiple meshes will most likely have different shapes for each part of the scene. The trimesh and convex options are more suited here. I guess it's not a big problem to expose anyway.

[SaracenOne]

This has been rebased and now also includes full documentation.

[Mickeon]

I am pleasantly surprised in the way these descriptions are subtly written to guide the reader. For example, meshes/physics/shape_type shares which shapes are primitive, as a point of reference for the next descriptions.

As future reference, a lot of these settings are also present in MeshConvexDecompositionSettings, and they have entirely different descriptions. The ones in this PR are somewhat more informative. Perhaps it would be a good idea to standardize them in the future.

[SaracenOne]

Rebased and implement @Mickeon's recommendation for re-wording of certain documentation.

[aaronfranke]

Use the enum type instead of int. You need to bind the enum with VARIANT_ENUM_CAST and BIND_ENUM_CONSTANT.

[SaracenOne]

I don't disagree, though I might want to investigate why we haven't done this for any of the other enum types in the import system either. It might simply be because the .import files don't really have any concept of enums yet and will simply serialize them as raw integers (this is very bad and fragile, but I think fixing this should probably be part of a broader improvement to the import system which may go a bit beyond the scope of this PR). Either way, let me know if you feel like this a sticking point; I've at least gone and change the internal handling of this value to work with the enum type, but I'm a bit hesitant to expose this enum to the scripting layer since there no-consistency precedent in the context of the import system, no practical use of this value for the end-user, and I wonder if this should be part of a broader set of improvements to the system.

[lyuma]

Is the issue that this enum would look very similar to another enum but off by 1 and it would be confusing to users which enum constants to use?

Is there a way to choose which subset of enum values are visible to the user (hide "Default" from the advanced importer settings, but show it on the global import dock)?

I agree with Saracen that what is suggested is just not trivial from the advanced importer (and anyway the properties won't be properly exposed to scripting, so people will be manipulating int values in a dictionary either way).

@aaronfranke Would you be open to perhaps doing this enum change as a separate PR so we can see what is required to make typed enums happen for import settings without mixing it with the rest of the complexity of this change.

[aaronfranke]

Changing the public API later breaks compatibility, and using an enum is clearer in the code. If we think it's fine to use non-enum integers then maybe we can go ahead, but I would prefer to "get the API right the first time". I don't think we should merge this in with the intent to change it in a follow-up PR. Unless you mean opening a separate PR before this one is merged, which would change existing numbers to enums and explore if that can be done without compatibility breakage or not, in which case I am in favor of that.

[lyuma]

Oh, I see the problem. I didn't notice the extra int function argument to the virtual function.

I think we should avoid modifying the API and instead use the existing p_options argument to lookup the setting from inside _post_fix_node:

	CollisionMode default_collisions = COLLISION_DISABLED;
	if (p_options.has(SNAME("meshes/generate_collisions"))) {
		default_collisions = (CollisionMode)p_options["meshes/generate_collisions"];
	}

I understand there is some inconsistency between this and other settings such as fps or root_scale, but this is just for historical reasons. The argument cannot be removed since we've had fps in the API for a long time, so it stays there. But for new things I think the code is generally reading the options from p_options instead of making an argument for each new setting.

[aaronfranke]

Why not the other motion types? Also, why doesn't this also have "default"?

[SaracenOne]

The other motion types I believe were discussed, and I think there was some hesitation over broadening the useful scope of the feature (your most-likely application for this is for people wanting to bring in full kitbashed 3D scenes without manually having to set up collision on every node). As for why disabled is the default, that's simply because the default behaviour for importing individual nodes is to simply not create collision for node unless explicitly stated otherwise. The basic idea for the flow is you have scene-wide collision generation settings, and each individual node is now instead set up with 'default' instead which will match the scene-wide settings. This also ensures this feature is implemented with backwards-compatibility of existing setups.

[lyuma]

I think the other types could make sense when Godot finally gets support for indirect collision shape children of rigid bodies.

Basically, I think it is a bit unusual to have an option to automatically convert all mesh instances in the scene to rigid bodies or other types, once per mesh (the scene is not one object, but instead exactly one physical object per mesh). This is very awkward and probably not what the user wants.

I think the user might want to import the whole scene as a single rigid body, but this is where we get the problem with indirect children.

For static bodies, we don't have this problem because you can safely create as many or as few StaticBody3D nodes in the scene without impacting the physical nature.

[aaronfranke]

See also godotengine/godot-proposals#542 and #106048

Honestly, I'd really like to get these merged in first. Having the importer generate CollisionShape3D nodes would be a much better workflow for most cases. so I'd like to see that be both available and given priority, and the scene import code can work around that. So I'd like to consolidate the plan for this PR together with #106048, but that requires merging #77937 first, which is still awaiting approval.

[AThousandShips]

Suggested change

	r_options->push_back(ImportOption(PropertyInfo(Variant::FLOAT, "meshes/decomposition/max_concavity", PROPERTY_HINT_RANGE, "0.0,1.0,0.001", PROPERTY_USAGE_DEFAULT), decomposition_default->get_max_concavity()));
	r_options->push_back(ImportOption(PropertyInfo(Variant::FLOAT, "meshes/decomposition/max_concavity", PROPERTY_HINT_RANGE, "0.0,1.0,0.001"), decomposition_default->get_max_concavity()));

Redundant, for all these

[AThousandShips]

Suggested change

	r_options->push_back(ImportOption(PropertyInfo(Variant::FLOAT, "meshes/decomposition/min_volume_per_convex_hull", PROPERTY_HINT_NONE, "", PROPERTY_USAGE_DEFAULT), decomposition_default->get_min_volume_per_convex_hull()));
	r_options->push_back(ImportOption(PropertyInfo(Variant::FLOAT, "meshes/decomposition/min_volume_per_convex_hull"), decomposition_default->get_min_volume_per_convex_hull()));

Same for all these

[AThousandShips]

Suggested change

	Ref<MeshConvexDecompositionSettings> decomposition_default = Ref<MeshConvexDecompositionSettings>();
	Ref<MeshConvexDecompositionSettings> decomposition_default;

[AThousandShips]

Suggested change

	The radius of generated primitive shapes. Only used when [member meshes/physics/shape_type] is set to [b]Spheres[/b], [b]Cylinders[/b], and [b]Capsules[/b].
	The radius of generated primitive shapes. Only used when [member meshes/physics/shape_type] is set to [b]Spheres[/b], [b]Cylinders[/b], or [b]Capsules[/b].