For ConcavePolygonShape in active mode Debug visible collision shapes, when the collision shape changes, the auxiliary MeshInstance does not change.

[OlexiyKravchuk]

Godot_v3.3-stable_win64

OS/device including version:
Win7 x64

Issue description:
For ConcavePolygonShape in active mode Debug visible collision shapes, when the collision shape changes, the auxiliary MeshInstance does not change.
When using ConvexPolygonShape everything is fine.
P.S. It seems to me that auxiliary forms for visualizing collision forms are better to attach to their collision forms as children, so it is more convenient to work when they do not get confused, especially if there are several forms.

Steps to reproduce:
Try a minimal example project.

Minimal reproduction project:
BUG_DEAD_FORM.zip

[OlexiyKravchuk]

#48085

[trollodel]

I tested MRP using #48175, and it changes the debug shapes correctly.

P.S. It seems to me that auxiliary forms for visualizing collision forms are better to attach to their collision forms as children, so it is more convenient to work when they do not get confused, especially if there are several forms.

Since 3.3, debug shapes are placed by CollisionObject, which should know nothing about CollisionShapes.

[OlexiyKravchuk]

I tested MRP using #48175, and it changes the debug shapes correctly.

If I understood the translations correctly, in a future release, the rendered form will no longer be a node at all, and will be served directly by the visual server?

Since 3.3, debug shapes are placed by CollisionObject, which should know nothing about CollisionShapes.

I meant that if the system adds a debug form as a node, then the problem is that the node of the physical object already knows about the number of its children, and in many cases, with a complex combination of the composition of forms of interaction in physical objects, the forms of design created for debugging also become children of the physical object. This violates the scripts where the children of this physical object are viewed in which the script expects to find only the collision forms.
Therefore, if the forms of design were attached to the very forms of collision as children, such a conflict would not have occurred.
In addition, such an approach would simultaneously solve the problems with the transformation of any form of collision individually and the entire physical object at the same time, and even in mixing, instead of manual control, it would be solved by the natural mechanisms of the engine, since children automatically follow the transformations of their ancestors.

[trollodel]

If I understood the translations correctly, in a future release, the rendered form will no longer be a node at all, and will be served directly by the visual server?

Yes

Therefore, if the forms of design were attached to the very forms of collision as children, such a conflict would not have occurred.
In addition, such an approach would simultaneously solve the problems with the transformation of any form of collision individually and the entire physical object at the same time, and even in mixing, instead of manual control, it would be solved by the natural mechanisms of the engine, since children automatically follow the transformations of their ancestors.

This is how it works before 3.3, CollisionShape creates the debug shape node. The issue with that approach is that if you want to use CollisionObject API directly, without using a CollisionShape node, there is no way to show the debug shape.