Baking Indirect Lighting is broken #105555

New Issue

Steve · 2023-03-08T07:43:16+01:00

Steve commented

2023-03-08 07:43:16 +01:00

System Information
Operating system: Windows 11
Graphics card: Nvidia 1660S

Blender Version
Broken: 3.2 and newer
Worked: 3.1.2

Caused by c722993ef1

Short description of error

Baking indirect lighting is currently broken and seems to simply ignore any light sources in the scene.

Exact steps for others to reproduce the error

Open attached .blend file
Bake texture

**System Information** Operating system: Windows 11 Graphics card: Nvidia 1660S **Blender Version** Broken: 3.2 and newer Worked: 3.1.2 Caused by c722993ef1 **Short description of error** Baking indirect lighting is currently broken and seems to simply ignore any light sources in the scene. **Exact steps for others to reproduce the error** - Open attached .blend file - Bake texture

Indirect Lighting.blend

17 MiB

Screenshot_6.png

1.1 MiB

Steve added the

labels 2023-03-08 07:43:16 +01:00

Germano Cavalcante commented

2023-03-08 22:39:36 +01:00

Worked: prior 3.3

I tested previous versions and the result is the same.

I'm not sure that should be the expected result. Need information from developers.

> Worked: prior 3.3 I tested previous versions and the result is the same. I'm not sure that should be the expected result. Need information from developers.

Germano Cavalcante added

Module

Render & Cycles

Status

Needs Info from Developers

and removed

Status

Needs Triage

labels 2023-03-08 22:39:52 +01:00

Steve commented

2023-03-09 01:37:52 +01:00

Sorry for my mistake, I've updated the latest working Blender version. It's broken since Blender 3.2.0

This is the expected result (from Blender 3.1.2):

The issue is only happening when only baking the indirect lighting contribution. Direct + indirect contribution still works as expected.

Sorry for my mistake, I've updated the latest working Blender version. It's broken since **Blender 3.2.0** This is the expected result (from Blender 3.1.2): ![Screenshot_1.png](/attachments/9e4a6429-ad5e-4314-9735-81df9066511c) The issue is only happening when only baking the indirect lighting contribution. Direct + indirect contribution still works as expected.

Screenshot_1.png

1.3 MiB

Germano Cavalcante commented

2023-03-09 04:11:50 +01:00

I can confirm the different result in 3.1.2 (which seems to be the correct one).

Germano Cavalcante added

Status

Confirmed

and removed

Status

Needs Info from Developers

labels 2023-03-09 04:12:02 +01:00

Philipp Oeser referenced this issue from infrastructure/blender-projects-platform

2023-03-29 14:35:29 +02:00

Issues and triaging features #12

Philipp Oeser commented

2023-03-29 16:59:10 +02:00

Caused by c722993ef1

@brecht : ~~looks like that commit made it so the Contributions checkboxes will only be taken into account for the PASS_COMBINED (and it it is still the case now in bake_setup_pass)?~~

~~If that is intended behavior (dont think so?), then we should at least make them greyed out for other Bake Types?~~

Seems I checked a wrong revision here, will check again...

Caused by c722993ef19d6e6a564311f4bdc3cfb214b1474a @brecht : ~~looks like that commit made it so the Contributions checkboxes will only be taken into account for the `PASS_COMBINED` (and it it is still the case now in `bake_setup_pass`)?~~ ~~If that is intended behavior (dont think so?), then we should at least make them greyed out for other `Bake Types`?~~ Seems I checked a wrong revision here, will check again...

sophieYang commented

2023-03-30 03:48:47 +02:00

Same error happens to me

The expect result (Blender version:3.1.2):
Should be able to bake indirect diffuse and direct diffuse separately.

But thing goes wrong in Blender 3.4:
It is fine when baking direct diffuse.

But when baking indirect diffuse, it return an almost black image

When bakcing dirct AND indirect diffuse, it seem's fine again

I linked my test blend file below

Same error happens to me The expect result (Blender version:3.1.2): Should be able to bake indirect diffuse and direct diffuse separately. ![16800895188533.png](/attachments/7a846924-4165-4ae0-85d5-bc9361e4c907) ![16800895512554.png](/attachments/b1d39110-c99b-46b4-94c5-8856f8eb6307) But thing goes wrong in Blender 3.4: It is fine when baking direct diffuse. ![16800898992560.png](/attachments/2c070ef3-dbca-4906-b285-920015b76018) **But when baking indirect diffuse, it return an almost black image** ![16800905336120.png](/attachments/7f3645b9-e62a-4d80-b503-a5df414f6d23) When bakcing dirct AND indirect diffuse, it seem's fine again ![16800899448741.png](/attachments/c42ac2f7-6ca3-4525-a6b4-b17da46bb671) I linked my test blend file below

16800898992560.png

548 KiB

16800895188533.png

656 KiB

16800899448741.png

601 KiB

16800895512554.png

733 KiB

16800905336120.png

613 KiB

sophieYang commented

2023-03-30 03:49:19 +02:00

here's the blend file

bakingTest.blend

1.1 MiB

Philipp Oeser commented

2023-03-30 09:55:01 +02:00

Hm, I think the behavior was also wrong before c722993ef1 if you used the Combined Bake Type. If you had Direct disabled and Indirect enabled, you would also not get indirect at all...

@brecht : dont really know the internals well, but could it be that for light contributions, we always need to have integrator->set_use_direct_light(true) ?
Otherwise SD_BSDF_HAS_EVAL gets cleared , integrate_surface_direct_light does nothing (so misses a whole lot of stuff that might actually be needed in the following integrate_surface_bsdf_bssrdf_bounce).

Not sure though, just guessing...

Hm, I *think* the behavior was also wrong before c722993ef1 if you used the `Combined` `Bake Type`. If you had `Direct` disabled and `Indirect` enabled, you would also not get indirect at all... @brecht : dont really know the internals well, but could it be that for light contributions, we **always** need to have `integrator->set_use_direct_light(true)` ? Otherwise `SD_BSDF_HAS_EVAL` gets cleared , `integrate_surface_direct_light` does nothing (so misses a whole lot of stuff that might actually be needed in the following `integrate_surface_bsdf_bssrdf_bounce`). Not sure though, just guessing...

Philipp Oeser referenced this issue

2023-06-13 16:00:12 +02:00

Regression: Directional light caustics absence in indirect diffuse lighting bake #108916

Philipp Oeser commented

2023-06-13 16:00:42 +02:00

Since this has been reported again (and was considered High priority there, see #108916), will raise priority here as well.

Philipp Oeser added

and removed

labels 2023-06-13 16:00:53 +02:00

Lukas Stockner commented

2023-06-14 00:24:21 +02:00

dont really know the internals well, but could it be that for light contributions, we always need to have integrator->set_use_direct_light(true) ?
Otherwise SD_BSDF_HAS_EVAL gets cleared , integrate_surface_direct_light does nothing (so misses a whole lot of stuff that might actually be needed in the following integrate_surface_bsdf_bssrdf_bounce).

Disabling SD_BSDF_HAS_EVAL is a trick to skip direct light evaluation, but of course indirect bounce light also originates as direct light (before it bounces). Therefore, in the attached scene, what happens is:

The path starts on the white floor
Direct lighting on the floor is skipped (correct)
The path bounces to the purple box (correct)
Direct lighting on the purple box is skipped (incorrect)

Just globally enabling use_direct_light would work, but would lead to wasted computation (since we'd no longer skip the direct light on the baking location either). Instead, I think we should only disable SD_BSDF_HAS_EVAL at the initial location. I'll give it a try.

Also, yeah, same problem applied to the indirect filter for Combined baking even before the commit in question, that one only extended the problem to the Diffuse/Glossy/Transmission filters.

> dont really know the internals well, but could it be that for light contributions, we always need to have integrator->set_use_direct_light(true) ? Otherwise SD_BSDF_HAS_EVAL gets cleared , integrate_surface_direct_light does nothing (so misses a whole lot of stuff that might actually be needed in the following integrate_surface_bsdf_bssrdf_bounce). Disabling `SD_BSDF_HAS_EVAL` is a trick to skip direct light evaluation, but of course indirect bounce light also originates as direct light (before it bounces). Therefore, in the attached scene, what happens is: - The path starts on the white floor - Direct lighting on the floor is skipped (correct) - The path bounces to the purple box (correct) - Direct lighting on the purple box is skipped (incorrect) Just globally enabling `use_direct_light` would work, but would lead to wasted computation (since we'd no longer skip the direct light on the baking location either). Instead, I think we should only disable `SD_BSDF_HAS_EVAL` at the initial location. I'll give it a try. Also, yeah, same problem applied to the indirect filter for Combined baking even before the commit in question, that one only extended the problem to the Diffuse/Glossy/Transmission filters.

Lukas Stockner referenced this issue from a commit

2023-06-14 01:48:08 +02:00

Fix #105555: Cycles: Baking only indirect lighting is broken

Lukas Stockner closed this issue

2023-06-14 01:49:14 +02:00

Blender Bot added

and removed

labels 2023-06-14 01:49:15 +02:00