EEVEE-Next: Add Volume Probe > Blending Size setting #118342

Miguel Pozo · 2024-02-15T19:16:12+01:00

Miguel Pozo commented

2024-02-15 19:16:12 +01:00

Allow the user to control the size of the irradiance grid blending.

Miguel Pozo added the

labels 2024-02-15 19:16:12 +01:00

Miguel Pozo added 1 commit 2024-02-15 19:16:22 +01:00

Add grid_blending_size da6f42da3b

Miguel Pozo requested review from Clément Foucault 2024-02-15 19:16:39 +01:00

Clément Foucault reviewed 2024-02-21 11:44:22 +01:00

Clément Foucault left a comment

I think we should reuse LightProbe::falloff for that property instead of adding another one. To me it is doing almost the same thing. It just changes behavior for EEVEE-Next.

But that pauses the question of backward compatibility (we would have to patch older file). So I'm not sure.

I think we should reuse `LightProbe::falloff` for that property instead of adding another one. To me it is doing almost the same thing. It just changes behavior for EEVEE-Next. But that pauses the question of backward compatibility (we would have to patch older file). So I'm not sure.

Miguel Pozo commented

2024-02-21 15:54:47 +01:00

Even if they're kept as separate rna properties so they don't have to share docstring and the min-max range, I don't know if there would be a way to use different default values based on probe type.
Also, I don't know if setting a >1.0 value on a volume probe and changing the type to sphere would break the expected falloff range.

For backward compatibility, I think it could be handled by checking the probe type.

So, it may be doable, but I'm not sure it's worth the trouble.

Even if they're kept as separate rna properties so they don't have to share docstring and the min-max range, I don't know if there would be a way to use different default values based on probe type. Also, I don't know if setting a >1.0 value on a volume probe and changing the type to sphere would break the expected falloff range. For backward compatibility, I think it could be handled by checking the probe type. So, it may be doable, but I'm not sure it's worth the trouble.

Miguel Pozo added 1 commit 2024-02-21 16:03:20 +01:00

Merge branch 'main' into pull-eevee-grid-blending-setting e2537de1cd

Miguel Pozo added 1 commit 2024-02-21 18:53:06 +01:00

Remove random remapping 86dbfd19fa

Clément Foucault requested changes 2024-02-25 18:24:42 +01:00

Clément Foucault left a comment

After experimenting, I think adding a Blending Size setting is not worth it for now and opens a different can of worms to avoid light bleeding and what space is best for blending. For now, we can settle on reducing the blending to a half voxel blending (that doesn't overlap the data).

Blending with surrounding probes will be implemented in another way which should be more efficient and noise free (see #118725 but with blending added at volume upload time on more than 1 voxel).

So keep this PR to remove the random remapping and reduce the blending to half a voxel (so that it ends at the border samples locations), but remove the addition of a new parameter.

After experimenting, I think adding a Blending Size setting is not worth it for now and opens a different can of worms to avoid light bleeding and what space is best for blending. For now, we can settle on reducing the blending to a half voxel blending (that doesn't overlap the data). Blending with surrounding probes will be implemented in another way which should be more efficient and noise free (see #118725 but with blending added at volume upload time on more than 1 voxel). So keep this PR to remove the random remapping and reduce the blending to half a voxel (so that it ends at the border samples locations), but remove the addition of a new parameter.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

EEVEE-Next: Add Volume Probe > Blending Size setting #118342

Pull request closed