Commit graph

11 commits

Author SHA1 Message Date
Rémi Verschelde
a2c68d9da7
lightmapper: Disable build if raycast module can't build
We need to propagate the hacky checks from the raycast config to the
lightmapper config, as the failure of a `can_build()` check is not notified to
other modules (which might even be checked further depending on the processing
order in SConstruct).

A more thorough fix would be to change SConstruct to do two loops on modules:
one to check `can_build()` and disable modules which can't build, then another
one to rechecked `can_build()` with the new lineup and do further config.
But there would be more risk for regressions than with this ad hoc hack.

Similar story for the `platform/x11/detect.py` change... oh my eyes :(
2021-04-22 19:12:37 +02:00
Pedro J. Estébanez
6d89f675b1 Modernize Thread
- Based on C++11's `thread` and `thread_local`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed (except for the few cases of non-portable functions)
- Simpler for `NO_THREADS`
- Thread ids are now the same across platforms (main is 1; others follow)
2021-02-18 11:58:08 +01:00
JFonS
56bf256d76 Add options to reduce lightmaps disk usage.
Added BakedLightmap.use_hdr and BakedLightmap.use_color properties
that can reduce the flie size of lightmap texture at the expense of quality.

Changed the denoiser to work in a single buffer, reducing RAM
usage. Also added the `-mstackrealign` flag in the denoiser compilation
for MinGW builds. This flag helped fix a bug in Embree, so I want to see
if it will help fix GH #45296.
2021-02-16 13:20:27 +01:00
Rémi Verschelde
f36c529ad0
Merge pull request #45752 from JFonS/cpu_lightmapper_fixes
Assorted CPU lightmapper fixes
2021-02-06 11:44:52 +01:00
JFonS
27c1e65969 Assorted CPU lightmapper fixes
- Fix crash when a ray hits a texel with a UV2 coordinate exactly
  equal to 1.0.
- Take BakedLightmap extents into account.
- Clear capture data between bakes.
- Fix minor issues with seam correction.
2021-02-05 19:18:19 +01:00
Andy Maloney
85377e96d2 Fix undeclared identifier error in lightmapper_cpu.cpp
Compiling with latest clang on macOS produced this error: use of undeclared identifier 'rand'.

Fixes godotengine/godot#45342

This file is not present in 4.0/master.
2021-01-21 13:07:30 -05:00
Rafał Mikrut
d025194602 Remove thread after use to prevent memory leak 2021-01-20 09:37:25 +01:00
Lyuma
2c2f70c444 embree: cross compile fixes.
Fix typos in #if; add missing _MSC_VER; avoid warning in random generator.
2021-01-18 06:20:24 -08:00
JFonS
b1ca82c43a CPU lightmapper fixes.
- Fix Embree runtime when using MinGW (patch by @RandomShaper).
- Fix baking of lightmaps on GridMaps.
- Fix some GLSL errors.
- Fix overflow in the number of shader variants (GLES2).
2021-01-15 12:32:54 +01:00
JFonS
7d7d7ef16d CPU lightmapper formatting and minor fixes. 2021-01-14 18:08:33 +01:00
JFonS
112b416056 Implement new CPU lightmapper
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>
2021-01-14 18:05:56 +01:00