While adding more debug checks to legacy renderer, I closed 2 types of vulnerabilities:
* TYPE_PRIMITIVE would previously read from uninitialized data if only specifying a single color
* Other legacy draw operations would fail in debug AFTER accessing out of bounds memory rather than before
Many calls to glBufferSubData are wrapped in a safe version which checks for out of bounds and exits the draw function if this is detected.
Large FVF allows batching of many custom shaders, but should not join items which have shaders that utilize BUILTINs which would change for each item, because these will not be sent individually, and all joined items would wrongly use the values from the first joined item.
As a result of the GLES specifications being vague about best practice for how buffers should be used dynamically, different GPUs / platforms appear to have different preferences.
Mac in particular seems to have a number of problems in this area, and none of the rendering team uses Macs. So far we have relied on guesswork to choose the best usage, but in an attempt to pin this down, this PR begins to introduce manual selection of options for users to test their configurations.
It can be enabled in the Project Settings
(`rendering/quality/filters/use_debanding`). It's disabled
by default as it has a small performance impact and can make
PNG screenshots much larger (due to how dithering works).
As a result, it should be enabled only when banding is noticeable enough.
Since debanding requires a HDR viewport to work, it's only supported
in the GLES3 backend.
Batching is mostly separated into a common template which can be used with multiple backends (GLES2 and GLES3 here). Only necessary specifics are in the backend files.
Batching is extended to cover more primitives.
Don't apply lighting to objects when they have a lightmap texture and
the light is set to BAKE_ALL. This prevents applying the same direct
light twice on the same object and makes setting up scenes with mixed
lighting much easier.
Option in MeshInstance to enable software skinning, in order to test
against the current USE_SKELETON_SOFTWARE path which causes problems
with bad performance.
Co-authored-by: lawnjelly <lawnjelly@gmail.com>
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.
While OpenGL ES 3.0 and WebGL 2.0 both support non power-of-2 (NPOT)
textures in their specification, the situation seems to be less clear
about *compressed* NPOT textures using repeat or mipmap flags.
At least Chrome on Linux doesn't seem to support this combination,
and a variety of mobile hardware have similar limitations.
As a workaround, we force decompressing such textures when running on
WebGL 2.0, at the cost of loading time and memory usage.
Fixes#33058.
This is a new singleton where camera sources such as webcams or cameras on a mobile phone can register themselves with the Server.
Other parts of Godot can interact with this to obtain images from the camera as textures.
This work includes additions to the Visual Server to use this functionality to present the camera image in the background. This is specifically targetted at AR applications.
The bake mode property of lights previously didn't affect GI probes.
This change makes the GI probe ignore lights that have their bake mode
set to disabled.
- Cleaned up and improved the code determining when we need to use a depth
prepass (previously it wasn't executed in certain cases even if it was
needed)
- Added code to prepare and bind the depth texture even when no depth prepass
or MRTs (more precisely effect buffers) are used
Fixes#25870, #25535, and #25387.
Remove animation loop from ParticlesMaterial and move it to
SpatialMaterial for 3D particles and Particles2D for the 2D case.
Added animation to CPUParticles2D as well as the "Convert to
CPUParticles2D" to the PAarticles2D menu.
Fixes the following Clang 7 warnings:
```
core/object.cpp:44:1: warning: '_ObjectDebugLock' defined as a struct here but previously declared as a class [-Wmismatched-tags]
core/variant_call.cpp:43:1: warning: '_VariantCall' defined as a struct here but previously declared as a class [-Wmismatched-tags]
drivers/gles3/rasterizer_storage_gles3.h:765:2: warning: 'MultiMesh' defined as a struct here but previously declared as a class [-Wmismatched-tags]
editor/editor_node.h:794:1: warning: 'EditorProgress' defined as a struct here but previously declared as a class [-Wmismatched-tags]
modules/bullet/rigid_body_bullet.h:230:17: warning: class 'KinematicUtilities' was previously declared as a struct [-Wmismatched-tags]
modules/bullet/space_bullet.h:60:1: warning: class 'btSoftBodyWorldInfo' was previously declared as a struct [-Wmismatched-tags]
scene/resources/world_2d.cpp:40:1: warning: 'SpatialIndexer2D' defined as a struct here but previously declared as a class [-Wmismatched-tags]
scene/resources/world.cpp:39:1: warning: 'SpatialIndexer' defined as a struct here but previously declared as a class [-Wmismatched-tags]
servers/audio/reverb_sw.cpp:60:1: warning: 'ReverbParamsSW' defined as a struct here but previously declared as a class [-Wmismatched-tags]
thirdparty/bullet/BulletSoftBody/btSoftBody.h:43:1: warning: 'btSoftBodyWorldInfo' defined as a struct here but previously declared as a class [-Wmismatched-tags]
```
This allows more consistency in the manner we include core headers,
where previously there would be a mix of absolute, relative and
include path-dependent includes.
