* Fix attachments lagging behind their parents (#14818)
* Fix animation blending (#14817)
* Bring back cool guy as another .x smoke test
* Add .x mesh loader unittest
* Do bounding box & matrix calculation at proper point in time
* Remove obsolete `SAnimatedMesh`
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 don't have a C++ expert on hand, but taking a pointer to one member
and expecting to access another by an offset is very fishy:
- for one, there could theoretically be padding
- the compiler might assume that we are only writing to that first member
The new code has shown to be free for constant parameter values.
Non-constant ones cause the assembly to have branches (why?), but we don't
use that much.
see #15761
SDL is the only device that supports relative mode and
mouse input is actually somewhat broken if it's *not* enabled.
This reverts commit 45c5ef8798
and 88b007907a.
- Actually it's MSAA I think, or perhaps the terms are equivalent
- I've made it fit into the existing Irrlicht architecture, but that has resulted in code duplication compared to my original "hacky" approach
- OpenGL 3.2+ and OpenGL ES 3.1+ are supported
- EDT_OPENGL3 is not required, EDT_OPENGL works too
- Helpful tutorial: https://learnopengl.com/Advanced-OpenGL/Anti-Aliasing, section "Off-screen MSAA"
- This may be rough around the edges, but in general it works
SColor.h contains many functions which are unused and/or perform linear
operations on non-linear 8 bit sRGB color values, such as the plus operator and
`SColor::getInterpolated()`, and there is no documentation about missing gamma
correction.
Some of these functions are not called or called only once:
* `getAverage(s16 color)`: Unused
* `SColor::getLightness()`: Unused
* `SColor::getAverage()`: Claims to determine a color's average intensity but
calculates something significantly different since SColor represents
non-linear sRGB values.
* `SColor::getInterpolated_quadratic()`: Claims to interpolate between colors
but uses the sRGB color space, which is neither physically nor perceptually
linear.
* `SColorf::getInterpolated_quadratic()`: Unused
* `SColorf::setColorComponentValue()`: Unused
Removing or inlining these functions can simplify the code and documenting
gamma-incorrect operations can reduce confusion about what the functions do.
This commit does the following:
* Remove the above-mentioned unused functions
* Inline `SColor::getAverage()` into
`CIrrDeviceLinux::TextureToMonochromeCursor()`
* Rename `SColor::getLuminance()` into `SColor::getBrightness()` since it does
not determine a color's luminance but calculates something which differs
significantly from physical luminance since SColor represents non-linear sRGB
values.
* Inline `SColor::getInterpolated_quadratic()` into `GameUI::update()`,
where it is only used for the alpha value calculation for fading
* Document gamma-incorrect behaviour in docstrings
