This makes the setting easier to find, as research has found there are
numerous use cases to limiting FPS. This also improves documentation
related to the Engine property and project setting.
The project setting also works in projects exported in release mode,
so its location in the `debug/` section was misleading.
- Don't warn about minimized/maximized modes not being available.
- Blender and FBX export both depend on running thirdparty applications,
which can't be done (easily at least) for Web and Android editors.
- Editor theme complained about not being able to retrieve texture data
for an icon. It was only used once so instead of flipping at runtime,
let's just add a flipped icon.
Part of #65702.
This allows light sources to be specified in physical light units in addition to the regular energy multiplier. In order to avoid loss of precision at high values, brightness values are premultiplied by an exposure normalization value.
In support of Physical Light Units this PR also renames CameraEffects to CameraAttributes.
As announced in https://godotengine.org/article/godot-4-will-discontinue-visual-scripting,
Godot maintainers have agreed to discontinue the current implementation of
our VisualScript language.
The way it had been designed was not user-friendly enough and we did not
succeed in improving its usability to actually make it a good low-code
solution for users who need one.
So we prefer to remove it for Godot 4.0 and leave the door open for new,
innovative ideas around visual scripting, to be developed as plugins or
extensions now that Godot provides sufficient functionality for this
(notably via GDExtension and the godot-cpp C++ bindings).
The current module has been moved to a dedicated repository (with full Git
history extracted with `git filter-branch`):
https://github.com/godotengine/godot-visual-script
It can still be compiled as a C++ module (for now, but will likely require
work to be kept in sync with the engine repository), but our hope is that
contributors will port it to GDExtension (which is quite compatibile with
the existing C++ module code when using the godot-cpp C++ bindings).
We're targeting .NET 5 for now to make development easier while
.NET 6 is not yet released.
TEMPORARY REGRESSIONS
---------------------
Assembly unloading is not implemented yet. As such, many Godot
resources are leaked at exit. This will be re-implemented later
together with assembly hot-reloading.
The new default window size is tuned to:
- Have a 16:9 aspect ratio,
- Have both dimensions divisible by 8 to better play along with
video recording,
- Be displayable correctly in windowed mode on a 1366×768 display
(tested on Windows 10 with default settings).
This breaks compatibility with projects that didn't change the
window size from the default value (or that kept one of the values
to its default).
This provides a benefit similar to FSR 1.0 (greater texture sharpness
at the cost of some graininess at sub-native resolution scales), but
without the added performance cost of FSR 1.0.
This is consistent with the BaseMaterial3D filtering options.
It can be used for high-quality pixel art textures that remain sharp
when viewed at oblique angles, but prevents them from becoming grainy
thanks to mipmaps.
- Adds more customization options to ProjectSettings.
- Displays navregion edge connections and navigation polygon edges in editor and at runtime.
- Majority of debug code moved from SceneTree to NavigationServer.
- Removes the irritating debug MeshInstance child node from NavigationRegion3D and replaces it with direct RenderingServer API.
Mipmap LOD bias can be useful to improve the appearance of distant
textures without increasing anisotropic filtering (or in situations
where anisotropic filtering is not effective).
`fsr_mipmap_bias` was renamed to `texture_mipmap_bias` accordingly.
The property hint now allows for greater precision as well.
This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks
that can be run on threads (and then waited for). It satisfies the following use cases:
* HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads.
* Thread spawning is slow in general, so reusing threads is faster anyway.
* This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks.
After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
