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>
This change does two things:
1. Properly update the internal shape data using _update_in_shape_owner
when updating a shape (in 2D it was resetting one way collision)
2. Avoid unnecessary updates when calling set_shape with the same shape,
which happens each time a shape property is modified
(e.g shape.extents.x = ...)
Fixes#45090
(cherry picked from commit 4b43cd17c5)
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)
See #36285 which mistakenly added documentation for the whole C++ API, while
some of it is meant to be and stay private as it's not exposed to scripts.
The access modifiers and method prefix were not used properly.
Cleanup code, and rename wrong `group_name` parameters to `method`, as it's a
method name which is being broadcast.
This is a very old class from pre-open source days, chances are that it was
just forgotten and not meant to be kept as is and undocumented.
(cherry picked from commit 79ba70f7ee)
See #43689.
Also 'fixed' some spelling for behavior in publicly visible strings.
(Sorry en_GB, en_CA, en_AU, and more... Silicon Valley won the tech spelling
war.)
(cherry picked from commit a655de89e3)
This fixes a regression from PR #40313 (support for software skinning in MeshInstance).
Before, the base mesh was always updated on load even if not skinning
was used, which caused mesh instance materials to be reset on the
rendering side.
Now the base mesh is set only when it has been modified, or when
switching software skinning on or off. In this case the mesh instance
materials are always updated properly afterwards.
My mistake I missed this before the PR got merged:
is_visible_in_tree() should be avoided being called per frame unless absolutely necessary, because it is a recursive function that traverses the scene tree. It should be used when deciding on rare occasions whether to switch on or off skeleton processing, but it is better to use the cheaper is_visible() check on the per frame update.
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>
InterpolatedCamera has already been removed from the `master` branch.
This adds a deprecation notice to inform people about the upcoming removal
in Godot 4.0.
Its functionality could be replicated in a GDScript add-on with relative
ease.
Changed CPU velocity calculation for EMISSION_SHAPE_DIRECTED_POINTS
to follow the same logic as in the GPU version:
mat2 rotm;
rotm[0] = texelFetch(emission_texture_normal, emission_tex_ofs, 0).xy;
rotm[1] = rotm[0].yx * vec2(1.0, -1.0);
VELOCITY.xy = rotm * VELOCITY.xy;
Now both CPUParticles2D & CPUParticles3D (z disabled) show the same results
as their GPU counterparts and take the initial velocity settings into account.
(cherry picked from commit 1c231cacb3)
Add optional parameter to specify whether applying rotation to the
PathFollow3D's Transform is necessary, preventing erroneous updates.
(cherry picked from commit be3a1769fe)
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)
JFonS
Marcel Admiraal
Rémi Verschelde
PouleyKetchoupp
Rémi Verschelde
Tomasz Chabora
Juan Linietsky
lawnjelly
clayjohn
Duroxxigar
Jonathan Vice
booer
Hugo Locurcio
Yerik
ArrowInAKnee
Maganty Rushyendra
Adam Reichold
hoontee