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.
CImageWriterPNG::writeImage() and writeJPEGFile() explicitly allocate
and deallocate memory with `new` and `delete`, which is prone to programming errors.
The code also has non-functional error handling:
When memory allocation fails, `new` throws an `std::bad_alloc` exception
and never returns `nullptr`, so the check for `nullptr` is always false.
Co-authored-by: DS <ds.desour@proton.me>
This is a newer feature introduced in CMake 3.12, which is now our
minimum version. It supercedes `add_definitions`. I've also replaced
some calls to set `CMAKE_<LANG>_FLAGS` that were used to set
definitions. This is a fairly trivial routine build maintenance that
is not intended to have any behavioral effects.
TGA uses BGR(A)8, stored in memory in that order. Irrlicht typically expects 0xAARRGGBB, which depends on endianness.
(This means that on little endian, no [B][G][R][A] -> 0xAARRGGBB conversion needs to be done, but Irrlicht was swapping the bytes.)
This makes both conversion functions consistently convert from [B][G][R]([A]) to 0xAARRGGBB (SColor), documents them properly and moves them to CImageLoaderTGA.cpp
so no poor soul shall be fooled by them in the near future.
---------
Co-authored-by: Ælla Chiana Moskopp <erle@dieweltistgarnichtso.net>
- 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
The branch removed in this patch handled color format A1R5G5B5 specially
when creating a texture from a TGA type 1 file, i.e. an image that has a
colormap. It did not handle the 1-bit alpha channel correctly, rendering
transparent pixels black instead.
Since the colormap is converted to A8R8G8B8 earlier anyways, the code
for the general case is able to handle this scenario already – at the
expense of making the created texture use twice as much GPU memory as
necessary.
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.
Easy way to reproduce:
1. Connect a bluetooth mouse to your Android phone with Minetest installed
2. Play Minetest
3. Slowly move the mouse to the right so that the camera rotates continously
4. While still moving the mouse continously, tap the screen a few times per second
Before this commit: The camera jumps around randomly.
After this commit: The camera moves like it should.
This is a combination of two Irrlicht changes copied from MoNTE48/irrlicht
and one Minetest change authored by me. I have no idea why this works, but
it does work and I have spent way too much time on this bug already.
