The built-in ALPHA in spatial shaders comes pre-set with a per-instance
transparency value. Multiply by it if you want to keep it.
The transparency value of any given GeometryInstance3D is affected by:
- Its new "transparency" property.
- Its own visiblity range when the new "visibility_range_fade_mode"
property is set to "Self".
- Its parent visibility range when the parent's fade mode is
set to "Dependencies".
The "Self" mode will fade-out the instance when reaching the visibility
range limits, while the "Dependencies" mode will fade-in its
dependencies.
Per-instance transparency is only implemented in the forward clustered
renderer, support for mobile should be added in the future.
Co-authored-by: reduz <reduzio@gmail.com>
This prevents errors when encountering options which have been defined in newer
versions of clang-format, and are invalid in the YAML for the old version.
Bump minimum supported clang-format version to 12 (where `--Wno-error=unknown`
was added).
Use clang-format 12 on CI (13 is not available yet on the Ubuntu 20.04 images).
Mapping and other "abstract base classes" were moved after python 3.3 from collections to collections.abc
Python 3.3 is long gone and a newer version of python won't support this code.
When emitting stops CPUParticles3D::_set_redraw(bool p_redraw) will set that value to 0 so when you change the amount after that it will actually not update correclty.
This fixes an issue where if it was not emitting when the scene loaded and it start after that the amount is not reflected correclty. This also happened when you checked out the box for emitting in the editor, changed the value of amount and then checked on the box for emitting. With this change if it is emitting during the change it does interrupt the previous particles when you change. The amount and the emit starts from beginning but that is to be expected on an amount of particles change.
Disable minimum amount of spaces in comment prefix for now, as it otherwise
modifies the whole codebase. That's something we probably want to use as it
matches our convention, but we should look into fully converting these
comments to our style guide at the same time.
Should be changing the local center of mass, which is then transformed
into `center_of_mass`.
It was causing the center of mass to be always in (0,0) by default with
multiple shapes.