Repeating NPOT textures are not guaranteed to be displayed correctly
in GLES2, since the specification does not mandate support for it.
The warning is also displayed in GLES3 projects that are configured
to allow falling back to GLES2.
This changes the types of a big number of variables.
General rules:
- Using `uint64_t` in general. We also considered `int64_t` but eventually
settled on keeping it unsigned, which is also closer to what one would expect
with `size_t`/`off_t`.
- We only keep `int64_t` for `seek_end` (takes a negative offset from the end)
and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means
we only need to guard against passing negative values in `core_bind.cpp`.
- Using `uint32_t` integers for concepts not needing such a huge range, like
pages, blocks, etc.
In addition:
- Improve usage of integer types in some related places; namely, `DirAccess`,
core binds.
Note:
- On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with
version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for
big files on 32-bit Windows builds made with that toolchain. We might add a
workaround.
Fixes#44363.
Fixesgodotengine/godot-proposals#400.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
During the development of 3.3, internationalization features were added to allow arbitrary bone and node names.
However, doing so will break all references and existing animation clips for projects upgraded from 3.2
This adds an import setting, enabled by default, but disabled for newly generated .import files which restores the old behavior.
Its only purpose was to prevent importing CSV files as translations, but it
would still import them as *nothing*, leading to workflow issues.
This is now properly fixed with #47268 which allows disabling the import for
specific files.
(cherry picked from commit 7ed2220928)
Keyframe times shift slowly in imported animations, starting with a zero shift
at the beginning and increasing and becoming erratic slowly farther into an
animation, reaching significant levels at times after about 3 minutes into an
animation. This commit fixes the issue by increasing the precision of the
floating point numbers used for keyframe time calculations. Only the most
significant cases that cause fast accumulation of errors over a short animation
duration are fixed. Other cases that would have a marginal benefit from
switching to double precision numbers are left for another PR/further analysis.
Note that this change has no impact on the runtime performance of games/apps
created using Godot. It only affects the GLTF importer.
Fixes#47127.
(cherry picked from commit 6770a9413b)
- Based on C++11's `mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
- `BinaryMutex` added for special cases as the non-recursive version
- `MutexLock` now takes a reference. At this point the cases of null `Mutex`es are rare. If you ever need that, just don't use `MutexLock`.
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
Completely re-write the lightmap generation code:
- Follow the general lightmapper code structure from 4.0.
- Use proper path tracing to compute the global illumination.
- Use atlassing to merge all lightmaps into a single texture (done by @RandomShaper)
- Use OpenImageDenoiser to improve the generated lightmaps.
- Take into account alpha transparency in material textures.
- Allow baking environment lighting.
- Add bicubic lightmap filtering.
There is some minor compatibility breakage in some properties and methods
in BakedLightmap, but lightmaps generated in previous engine versions
should work fine out of the box.
The scene importer has been changed to generate `.unwrap_cache` files
next to the imported scene files. These files *SHOULD* be added to any
version control system as they guarantee there won't be differences when
re-importing the scene from other OSes or engine versions.
This work started as a Google Summer of Code project; Was later funded by IMVU for a good amount of progress;
Was then finished and polished by me on my free time.
Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
(cherry picked from commit b5334d14f7)
We should first attempt loading as external files, thus creating a dependency.
Loading as a buffer should only be used as fallback to support manually loading
as PNG or JPEG depending on the defined mimeType.
Fixes#44309, was a regression from #42504.
(cherry picked from commit e268a8e523)
image/gif is not supported in the glTF 2.0 specification,
these files are broken. But let's be lenient...
Fixes#43638.
(cherry picked from commit f70cc0a60e)
1. _gen_unique_bone_name(Ref<GLTFState> state, const GLTFSkeletonIndex skel_i, const String &p_name) won't return an empty string.
2. String GLTFDocument::_sanitize_bone_name(const String &name) will keep Japanese characters. Like: "全ての親".
3. The sanitize function allows the bone name to be not just alphanumeric. The only required conditions are the ones in add_bone.
> ERR_FAIL_COND(p_name == "" || p_name.find(":") != -1 || p_name.find("/") != -1);
(cherry picked from commit 7b76f8783f)
The glTF 2.0 spec only makes `mimeType` mandatory for `bufferView` image data,
so the previous logic to handle URIs with base64-encoded images could fail if
`mimeType` is undefined.
The logic was documented and refactored to better handle the spec, notably:
- `uri` and `bufferView` are now mutually exclusive, and only the latter fails
if `mimeType` is undefined.
- `uri` with a file path will now respect the `mimeType` if defined, and thus
attempt loading the file with the specified format (even if its extension is
not the one expected for this format). So we can support bad extensions (PNG
data with `.jpg` extension) or custom ones (PNG data in `.img` file for
example).
- `uri` with base64 encoded data will infer MIME type from `data:image/png` or
`data:image/jpeg` if it was not documented in `mimeType` initially.
- `uri` with base64 encoded data, no `mimeType` and `application/octet-stream`
or `application/gltf-buffer` will fall back to trying both PNG and JPEG
loaders.
Fully fixes#33796 (and fixes up #42501).
(cherry picked from commit 2e99d0b26f)
See https://github.com/KhronosGroup/glTF/issues/944 for context on the
application/gltf-buffer MIME type.
The glTF 2.0 spec supports `image/jpeg` and `image/png` which can also be
base64-encoded in buffer URIs.
Fixes#33796.
(cherry picked from commit 34a50310ad)
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
(cherry picked from commit cd4e46ee65)
PR #30877 was bogus as it made a blend shape-specific code block apply
to everything but blend shapes (as it seemed not to work properly *for*
blend shapes).
The proper fix should thus be to simply remove the problematic
block (and thus cleanup unnecessary logic).
Fixes#32712.
(cherry picked from commit 0034c88c57)
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
- Add or remove the necessary subdirectorires to the includes to remove
dependency on the editor directory being in the build's include path.
- Ensure includes in modified files conform to style guideline.
- Remove editor from the build include path.
- Skin groups now merge more cleanly together
- Skins whose highest nodes are siblings of another skin now get merged also
- Skin nodes who have children of another skin now also fuse together
- Removed the re-rooting of IBM code, as it is no longer needed with the Skin system
1: Depth draw mode set for transparent materials (iFire)
2: Skeletons
- Bone names now unique and seperate from scene names
- Due to mixture of fake joints and joints, new bone sanitizing for names added
- Fixed an issue where some disjoint skins were not being joined due to a logic error
- Deterministic and Depth-first bone creation order
3: Skins
- Removed duplicate skins when possible
4: Animations
- Fixed invalid morph target names
The last remaining ERR_EXPLAIN call is in FreeType code and makes sense as is
(conditionally defines the error message).
There are a few ERR_EXPLAINC calls for C-strings where String is not included
which can stay as is to avoid adding additional _MSGC macros just for that.
Part of #31244.
Condensed some if and ERR statements. Added dots to end of error messages
Couldn't figure out EXPLAINC. These files gave me trouble: core/error_macros.h, core/io/file_access_buffered_fa.h (where is it?),
core/os/memory.cpp,
drivers/png/png_driver_common.cpp,
drivers/xaudio2/audio_driver_xaudio2.cpp (where is it?)
Godot core needs MD5/SHA256/AES/Base64 which used to be provided by
separate libraries.
Since we bundle mbedtls in most cases, and we can easily only include
the needed sources if we so desire, let's use it.
To simplify library changes in the future, and better isolate header
dependencies all functions have been wrapped around inside a class in
`core/math/crypto_base.h`.
If the mbedtls module is disabled, we only bundle the needed source
files independently of the `builtin_mbedtls` option.
If the module is enabled, the `builtin_mbedtls` option works as usual.
Also remove some unused headers from StreamPeerMbedTLS which were
causing build issues.
It's not necessary, but the vast majority of calls of error macros
do have an ending semicolon, so it's best to be consistent.
Most WARN_DEPRECATED calls did *not* have a semicolon, but there's
no reason for them to be treated differently.
