Second try after the revert in 8a28339 due to an unexpected regression.
- Rigidly animated models (e.g. the glTF frog node) were not working correctly,
since cloning the mesh ignored the transformation matrices.
Note that scaling the mesh needs to occur *after* transforming the vertices.
- Visual scale did not apply to skinned models,
as resetting the animation overwrote scaled vertex data with static positions & normals.
For backwards compatibility, we now apply a 10x scale to static, non-glTF models.
We now do scale static meshes, as the bug that caused meshes not to be scaled was limited to skeletally animated meshes,
hence we ought not to reproduce it for skinned meshes that do not take advantage of skeletal animations (e.g. current MTG doors).
However, glTF models (e.g. Wuzzy's eyeballs) up until recently were always affected due to technical reasons
(using skeletal animation for rigid animation).
Thus, to preserve behavior, we:
1. Do not apply 10x scale to glTF models.
2. Apply 10x scale to obj models.
3. Apply 10x scale to static x or b3d models, but not to animated ones.
See also: #16141
We are being lax here, but the glTF specification just requires that "when the weights are stored using float component type, their linear sum SHOULD be as close as reasonably possible to 1.0 for a given vertex"
In particular weights > 1 and weight sums well below or above 1 can be observed in models exported by Blender if they aren't manually normalized.
These fail the glTF validator but Irrlicht normalizes weights itself so we can support them just fine.
The docs have been updated to recommend normalizing weights (as well as documenting the status of interpolation support).
Weights < 0, most of them close to 0, also occur. Consistent with Irrlicht, we ignore them, but we also raise a warning.
Also removes all animations but the first one from gltf_frog.gltf
to address the corresponding warning.
Catches some more possible exceptions (out of bounds, optional access)
which might be caused by a broken model to properly log them.
Sets the surprising row-major conventions used here straight.
Renames rotateVect to rotateAndScaleVect:
If the matrix also scales, that is applied as well by the method.
Obsolete rotateVect variants are removed.
The inverseRotateVect method is also renamed accordingly.
Note that this applies the transpose of the product
of the scale and rotation matrices, which inverts just the rotation.
