Add support for per-shape physics materials

[tancop]

Closes godotengine/godot-proposals#7401.

This PR adds:

• Methods shape_set_friction, shape_get_friction, shape_set_bounce, shape_get_bounce to PhysicsServer3D
• Property physics_material to Shape3D

This is implemented for both Godot and Jolt Physics (using a custom Jolt physics material like one of the official samples).

Example project that uses two different materials on one body: per-shape-materials.zip

[tancop]

Fixed the xml method order and added support for concave shapes.

[tancop]

Added support for changing materials at runtime. I had to add a new custom shape type JoltCustomMaterialOverrideShape, add a new virtual method on JoltShape3D and change some others to return a mutable JPH::Ref<JPH::Shape> instead of a JPH::ShapeRefC.

[tancop]

@AThousandShips I guess this is ready for review. If you see something wrong or confusing let me know

[tancop]

@jrouwe thanks! I saw RestoreMaterialState in the docs but thought it was just for deserializing from binary state. You saved 200 lines and a custom shape slot

[tancop]

Renamed JoltShape3D::_set_material to _update_material, it only changes the generated Jolt material not the shape itself

[tancop]

Rebased on latest master

[mihe]

Apologies for dragging this out. I want to sit down and review this PR in-depth, but making time for lengthy Jolt-related tasks has been tough these past few weeks.

Just quickly trying this out with Jolt I ran into a pretty fundamental issue right away, as seen in my review comment, so that's something that needs to be addressed at least.

I'll set aside time this friday to do a more in-depth review.

[mihe]

I've had a closer look at this PR now, and I have a couple of changes lined up that I'd like to see done for the Jolt side of things.

Instead of going back-and-forth with review comments I decided to just go ahead and make the changes myself, which you'll find in this diff.

I've tried to isolate the commits as best as possible, so you should hopefully be able to inspect them individually.

These are the more notable changes I guess:

1. I moved the all the shape material stuff from JoltShapedObject3D to JoltBody3D. There wasn't much of a reason to have it be shared with JoltArea3D, and this maps better to them being stored in GodotBody3D for Godot Physics.
2. The updating of manifold reduction was not being done correctly, and resulted in areas enabling it, which they shouldn't do. I also couldn't quite understand why it was being done in JoltShapedObject3D::commit_shapes, so that's all similarly been moved to JoltBody3D, and now follows the same thing_changed() update_thing() pattern that's used elsewhere in that file and the module in general, to (hopefully) ensure that this state doesn't go stale.
3. Having uses_shape_materials() potentially loop over hundreds of friction values and hundreds of bounce values for complex compound shapes had me concerned, given that it was being called for every contact in the contact listener. I went ahead and added caching of that value instead, which gets updated whenever the shape materials change in any way.
4. Having _try_override_collision_response be involved in deciding whether to call _override_contact_properties seemed unnecessary. That now instead follows the _try_do_thing pattern that's used for the other stuff in the contact listener.
5. I moved the combiner functions into jolt_math_funcs.h, to avoid duplicating them in jolt_contact_listener_3d.cpp. They probably don't belong there per se, but I couldn't justify creating a whole new file for them.
6. There wasn't much point to storing friction/bounce as real_t, since Jolt itself doesn't use double-precision for these, so these now get converted to/from float at the physics server boundary, same as a lot of other floating-point values in that module. This technically means you won't always return exactly the same value from the getter that's passed to the setter, but I feel that's a minor concession.

It's up to you how you'd prefer to merge these in, assuming you don't have any objections to the changes, or spot some potential problems with them. I think I have the necessary permissions to push to your branch, if you're fine with that. If not, you should be able to git apply this patch as well, or just add my fork as a remote and squash them in.

I haven't looked too closely at the Godot Physics side of the PR, so I can't say much about that, but I do have a couple of concerns, which I've left here as review comments.

[tancop]

@mihe thanks for the review just merged all the changes. I see you removed some casts to uint32_t in new JoltBody3D methods, had to add them back because -Wsign-compare is turned on for official builds

[tancop]

@mihe this good to go now or you still got questions? just wanna make sure everything clean before it gets merged

[mihe]

I found a fairly critical issue with the Godot Physics implementation, and some very minor cosmetic remarks in the Jolt implementation.

Outside of these review comments, I must admit that I'm becoming more and more uncomfortable with the API of these two PhysicsServer*D methods:

void body_set_shape_friction_override(RID p_body, int p_shape_idx, bool p_enable, real_t p_friction = 0.0);
void body_set_shape_bounce_override(RID p_body, int p_shape_idx, bool p_enable, real_t p_bounce = 0.0);

I realize it's a bit late to be having this conversation, and that the current design stems from feedback that have been given here already, so I won't push too hard on this, but the whole thing with having p_enable there, and then defaulting the values to 0.0, just so you can pass false without needing to give it a value. It makes for an odd-looking API in my opinion.

Unfortunately I struggle to think of an alternative that wouldn't ideally require a bool to be added for each material state as well, which seems like a hefty price to pay for what is only (subjectively) a better API.

Anyway, I just figured I'd voice my concern at least, in case anyone had any other ideas, or know of other Godot APIs that do something similar already.

[tancop]

@mihe switched this to use shape owner methods can you take a look if i did it right

[tancop]

@Calinou looks like mihe doesnt have time to review. is anyone else free right now?

[Calinou]

Tested again, it works as expected with GodotPhysics3D and Jolt Physics. Code and documentation look good to me.

I suggest having mihe take a final look at the API still, just in case. We can't change what's exposed once it lands in a stable release, so we need to make sure it's rock-solid.

[mihe]

I did another pass on this and found some bugs with the recent changes, which you'll find in the review comments. I also threw in some more nitpicks while I was at it.

I've also spent some more time thinking about the PhysicsServer*D API, and I think I've arrived at a better API for this:

func body_set_shape_friction_override(body: RID, shape_idx: int, friction: float) -> void
func body_get_shape_friction(body: RID, shape_idx: int) -> float
func body_is_shape_friction_overridden(body: RID, shape_idx: int) -> bool
func body_clear_shape_friction_override(body: RID, shape_idx: int) -> void

This gets rid of NAN from the API completely, by having body_get_shape_friction fall back on the body's friction when there is no override set, while still not burdening implementers with a separate enabled state.

To save us some time, I've gone ahead and made these changes already, and just like before you'll find the changes here (patch here), which also includes fixes for the new review comments.

Like before, if you have no objections to these changes, I can go ahead and push directly to your fork/branch as well. We're only a few days away from the 4.5 feature freeze, and I don't see anything else in this PR that should prevent this from being merged by then.

EDIT: Changes rebased on top of latest push (de20ef0).

[mihe]

This isn't needed anymore.

Suggested change

_FORCE_INLINE_ bool is_area() const { return area; }

[mihe]

Same feedback as with 2D.

Suggested change

_FORCE_INLINE_ bool is_area() const { return area; }

[mihe]

This check doesn't make sense anymore.

Suggested change

	if (shape.is_null()) {
	return;
	}

[mihe]

Same feedback as with 2D.

Suggested change

	if (shape.is_null()) {
	return;
	}

[mihe]

You're not disconnecting from the changed signal when the physics material is cleared. See CollisionShape2D::set_shape for reference.

[mihe]

Very nitpicky, but in most other places friction is listed before bounce.

Suggested change

	GDVIRTUAL_BIND(_body_set_shape_bounce_override, "body", "shape_idx", "enable", "bounce");
	GDVIRTUAL_BIND(_body_set_shape_friction_override, "body", "shape_idx", "enable", "friction");
	GDVIRTUAL_BIND(_body_get_shape_bounce_override, "body", "shape_idx");
	GDVIRTUAL_BIND(_body_get_shape_friction_override, "body", "shape_idx");
	GDVIRTUAL_BIND(_body_set_shape_friction_override, "body", "shape_idx", "enable", "friction");
	GDVIRTUAL_BIND(_body_set_shape_bounce_override, "body", "shape_idx", "enable", "bounce");
	GDVIRTUAL_BIND(_body_get_shape_friction_override, "body", "shape_idx");
	GDVIRTUAL_BIND(_body_get_shape_bounce_override, "body", "shape_idx");

[mihe]

Same nitpick about the ordering here.

Suggested change

	ClassDB::bind_method(D_METHOD("body_set_shape_bounce_override", "body", "shape_idx", "enable", "bounce"), &PhysicsServer2D::body_set_shape_bounce_override, DEFVAL(0.0));
	ClassDB::bind_method(D_METHOD("body_set_shape_friction_override", "body", "shape_idx", "enable", "friction"), &PhysicsServer2D::body_set_shape_friction_override, DEFVAL(0.0));
	ClassDB::bind_method(D_METHOD("body_get_shape_bounce_override", "body", "shape_idx"), &PhysicsServer2D::body_get_shape_bounce_override);
	ClassDB::bind_method(D_METHOD("body_get_shape_friction_override", "body", "shape_idx"), &PhysicsServer2D::body_get_shape_friction_override);
	ClassDB::bind_method(D_METHOD("body_set_shape_friction_override", "body", "shape_idx", "enable", "friction"), &PhysicsServer2D::body_set_shape_friction_override, DEFVAL(0.0));
	ClassDB::bind_method(D_METHOD("body_set_shape_bounce_override", "body", "shape_idx", "enable", "bounce"), &PhysicsServer2D::body_set_shape_bounce_override, DEFVAL(0.0));
	ClassDB::bind_method(D_METHOD("body_get_shape_friction_override", "body", "shape_idx"), &PhysicsServer2D::body_get_shape_friction_override);
	ClassDB::bind_method(D_METHOD("body_get_shape_bounce_override", "body", "shape_idx"), &PhysicsServer2D::body_get_shape_bounce_override);

[mihe]

This is not correct, since it'll keep the same reference even when we change values within the material.

Suggested change

	if (sd.material == p_material) {
	return;
	}

[mihe]

Same feedback as with 2D.

Suggested change

	if (sd.material == p_material) {
	return;
	}

[mihe]

This is not needed.

[mihe]

As another last-minute decision, I've omitted the body_is_shape_(friction|bounce)_overridden physics server methods from the API that I suggested above, because I struggle to see a use-case for such a query, and it's not something that's needed by the scene nodes anyway.

If anyone needs this in the future it can trivially be added then instead.

So the PhysicsServer*D API would look like this instead, which I'm mostly happy with:

func body_set_shape_friction_override(body: RID, shape_idx: int, friction: float) -> void
func body_clear_shape_friction_override(body: RID, shape_idx: int) -> void
func body_get_shape_friction(body: RID, shape_idx: int) -> float

The branch/patch linked above should have updated accordingly, but here (patch here) it is again if you need it.

EDIT: Changes have rebased on top of latest push (de20ef0).

[Xtarsia]

Does this have any chance of working with Heightmap Shapes? (I belive these construct a grid of Quad shapes under the hood, that are tested for in a specific way due to the nature of heightmaps.)

In Terrain3D I would like to be able to send a physics material "ID" for each Quad. Since We have access to an index map that could determine the dominant texture for any given quad, and that texture has other properties associated with it already, linking each texture ID (upto 32) to a physics material, would essentially Let us have paintable physics materials.

[mihe]

Does this have any chance of working with Heightmap Shapes? [...] In Terrain3D I would like to be able to send a physics material "ID" for each Quad.

@Xtarsia Not as-is, no. The same goes for individual triangles in ConcavePolygonShape3D. It's technically doable with Jolt, which supports this for both shapes, but it's not immediately clear to me how you'd go about implementing it for Godot Physics.

Either way, we'd need some way of actually assigning material values to groups of faces, both from a UX perspective and from an API perspective, which is likely quite a bit of work, and better suited for a future PR. The texture approach might make some sense for HeightMapShape3D, but I'm not sure it suits ConcavePolygonShape3D as well.