Improve HeightMapShape3D documentation

[ttencate]

See also godotengine/godot-docs#7471

[Mickeon]

Does this really solve the issue at hand? It still doesn't quite explain "how to use it", but it is a much better description of how it actually works.

[Mickeon]

Coincidentally I had to talk about "nonuniform" just a few hours ago.

Just as an addendum, we wrote "non-uniform" vastly more often than "nonuniform" (that is, not at all). Both are synonyms and apparently "nonuniform" is becoming more common, but I wouldn't drop the hyphen for the sake of clarity here.

Similarly, I see no one can make their mind on whether it's "height map" or "heightmap", the latter of which is more common and I'd keep using for consistency with the very next sentence.

Suggested change

The height map is represented as a 2D grid of height values, which represent the offset of grid points on the Y axis. Internally, each grid square is divided into two triangles. The grid is centered on the origin of the [HeightMapShape3D] node. Grid points are spaced 1 unit apart on the X and Z axes. If you need to use a different spacing, you can adjust the [member Node3D.scale] of the shape. However, keep in mind that nonuniform scales are not supported: you'll need to scale the Y axis by the same amount as the X and Z axes, which means the values in [member map_data] will need to be pre-scaled by the inverse of that scale.

The heightmap is represented as a 2D grid of height values, which represent the offset of grid points on the Y axis. Internally, each grid square is divided into two triangles. The grid is centered on the origin of the [HeightMapShape3D] node. Grid points are spaced 1 unit apart on the X and Z axes. If you need to use different spacing, you can adjust the [member Node3D.scale] of the shape. However, keep in mind that non-uniform scales are not supported: you'll need to scale the Y axis by the same amount as the X and Z axes, which means the values in [member map_data] will need to be pre-scaled by the inverse of that scale.

I would suggest moving anything following "_If you need to use different spacing, you can adjust [...]" to a separate note below the description. This whole line currently goes from describing the heightmap shape to a whole different tangent.
Speaking of the tip itself, we do not recommend to to scale collision shapes, so I'm not sure if this advice is sound, myself.

[ttencate]

I'm going to be stubborn and change it to "height map" consistently because the class name is HeightMapShape3D, not HeightmapShape3D.

Citing the Jolt PR #99895:

Godot Physics supports scaling the transform of collision shapes, shape queries, as well as static and kinematic bodies, meaning StaticBody3D, CharacterBody3D, AnimatableBody3D and frozen RigidBody3D. It does not however support scaling simulated/dynamic bodies, such as a non-frozen RigidBody3D, and will effectively discard any such scaling, instead treating it as (1, 1, 1).

Jolt does however support scaling everywhere, and I've tried my best to utilize that, which means that RigidBody3D will support scaling when using Jolt, despite the warning shown on the node currently.

Jolt also supports non-uniform scaling, so long as the inherent primitive shape is preserved. For example, you can scale a cylinder along its height axis but not along its other axes. You will however currently see warnings on the shape node when doing this, due to Godot Physics not supporting this.

I've updated the advice to account for this.

[ttencate]

Does this really solve the issue at hand? It still doesn't quite explain "how to use it", but it is a much better description of how it actually works.

Removed the "fixed".

[Mickeon]

I need an extra opinion on the "height map" change.