[3.2] Batch of lightmapper fixes and minor improvements #46932

JFonS · 2021-03-12T10:00:50Z

Fix objects with no material being considered as fully transparent by the lightmapper. Fixes Baked Lightmap Regression #46861.
Added "environment_min_light" property: gives artistic control over the shadow color.
Fixed "Custom Color" environment mode, it was ignored before.
Added "interior" property to BakedLightmapData: controls whether dynamic capture objects receive environment light or not. Fixes CPU lightmapper capture doesn't make use of the environment lighting #46591.
Automatically update dynamic capture objects when the capture data changes (also works for "energy" which used to require object movement to trigger the update).
Added "use_in_baked_light" property to GridMap: controls whether the GridMap will be included in BakedLightmap bakes.
Set "flush zero" and "denormal zero" mode for SSE2 instructions in the Embree raycaster. According to Embree docs it should give a performance improvement.

doc/classes/BakedLightmapData.xml

doc/classes/VisualServer.xml

drivers/gles2/rasterizer_storage_gles2.cpp

drivers/gles3/rasterizer_storage_gles3.cpp

akien-mga · 2021-03-12T10:17:27Z

modules/raycast/lightmap_raycaster.cpp

@@ -33,6 +33,7 @@
 // From Embree.
 #include <math/vec2.h>
 #include <math/vec3.h>
+#include <xmmintrin.h>


Note that this won't compile on !SSE2 AFAIK. That's currently guarded in config.py since we only support x86_64 currently, but eventually this will need to be improved (not necessarily in this PR).

And it would probably crash if run on non-SSE capable CPU (e.g. 32 bit x86). I assume from above you don't build in the lightmapper into 32 bit builds, or something like this. Mind you you'd be hard pressed to find a non-SSE1 capable CPU these days lol.

Yeah both Embree and OIDN only support x86_64 currently, so modules/denoise and modules/raycast are both only compiled on this arch. There's an aarch64 fork for Embree but we have yet to investigate using it (for macOS aarch64 mostly): https://github.com/lighttransport/embree-aarch64

Yeah, I'll be taking a look at embree-aarch64 since we will need it for 4.0's occlusion culling too. But in the meantime this change should not cause any issues given it's disabled on anything other than x86_64.

scene/3d/baked_lightmap.h

akien-mga

Left some comments, looks good overall.

JFonS · 2021-03-12T10:43:16Z

Pushed a new version, all the comments should be addressed now :)

doc/classes/BakedLightmapData.xml

- Fix objects with no material being considered as fully transparent by the lightmapper. - Added "environment_min_light" property: gives artistic control over the shadow color. - Fixed "Custom Color" environment mode, it was ignored before. - Added "interior" property to BakedLightmapData: controls whether dynamic capture objects receive environment light or not. - Automatically update dynamic capture objects when the capture data changes (also works for "energy" which used to require object movement to trigger the update). - Added "use_in_baked_light" property to GridMap: controls whether the GridMap will be included in BakedLightmap bakes. - Set "flush zero" and "denormal zero" mode for SSE2 instructions in the Embree raycaster. According to Embree docs it should give a performance improvement.

akien-mga · 2021-03-12T11:30:40Z

Thanks!

Calinou · 2021-03-12T12:39:00Z

Added "environment_min_light" property: gives artistic control over the shadow color.

This isn't urgent for 3.2.4, but I was thinking about this since the "min_light" terminology reminds me a lot of the minlight functionality available in Quake lightmapping tools.

In particular, we may want to have an option to add the ambient lighting to the lightmap instead of clamping the darkest lighting values to avoid making ambient lighting too uniform. Improved versions of the Quake light tool (such as the one linked above) provide this as an -addmin option:

−addmin

Changes the behaviour of minlight. Instead of increasing low light levels to the global minimum, add the global minimum light level to all style 0 lightmaps. This may help reducing the sometimes uniform minlight effect.

Is this already supported by configuring ambient light in the Environment? If so, disregard this 🙂

JFonS · 2021-03-12T13:10:45Z

@Calinou I was debating myself whether to add a "min" or an "add" option and I decided to go with "min" because it won't modify the overall brightness of the scene, it will only affect dark spots.

But I can see how a global "add" could also be useful. Right now you can set a custom environment color that adds light to the scene, but it takes geometry into account, so regions of the scene that are mostly covered wil not receive much of that light.

JFonS added bug topic:rendering labels Mar 12, 2021

JFonS added this to the 3.2 milestone Mar 12, 2021

JFonS requested review from a team as code owners March 12, 2021 10:00