@Clément Foucault (fclem) Don't have commit rights, you have push it if you're fine with it. Thanks!

• Save and restore previous background alpha.

I think this was introduced by 41cb5658803. This patch fixes it temporary, but its maybe a dirty hack: https://developer.blender.org/D4637.

In my current case its definitely a limitation, since its not possible to create a smooth animation for the first few frames (at least from the graphs visualization). Raised the 32 limit, but crashed here too. Idea: Exponential distribution of samples towards bezier handles.

In T62958#648339, @Jacques Lucke (JacquesLucke) wrote:

I see the issue.
Can you describe more precisely when this is an issue in practice?

Thanks @Clément Foucault (fclem)! Do I have to do something, it says "ready to land"?

Hey guys, is there anything I can do on this patch to get it approved? So many reports on those fireflies are coming in.

Hey guys, what do you think about this patch? Its mostly motivated by performance considerations. In some scenes you need the expensive soft shadows only for some lights. Also I realized that the halton pattern can be cached (don't know if this has any interesting performance impact).

• Remove comment.
• Activate soft shadows per default for all lights.

Changed clamp range and corrected spelling.

In T57752#606034, @Clément Foucault (fclem) wrote:

There is no separation. The problem is that the specular lighting is VERY strong and even if multiplied by a very low value (the shadow) it will still produce a visible amount of light.
What could be done for this is to introduce a clipping value (or bias) at which the shadows is considered completely dark and will let no light pass trough (basically a step function). I think the VSM already have something like that but not the ESM.

Here's a (temporary) fix for this issue: https://developer.blender.org/D4269.

Regarding 2.: I'm diving into the code atm, @Clément Foucault (fclem) could you point me to the right direction? I think I understand how lightning is calculated in lightning shader and that we have a out_spec and a out_diff factor, which are accumulated in the result.radiance field. Then the material pass is blended with the shadow pass. But somewhere some kind of separation must be still present, as shown above:

It seems to me that there are two separate issues in this task.

• Remove comment.

@Clément Foucault (fclem) I moved this patch to arcanist, therefore a new task was created: D4160. The influence radius now takes volume into account.

Seems to be related to T59784.

I reproduced this under the following circumstances (file attached):

In D4026#91120, @Clément Foucault (fclem) wrote:

This is a nice patch. The only thing missing is that the influence radius should take the volume power into account (see light_attenuation_radius_get).

How can the volume power be included there without influencing shading on non-volume fragments?

It would be a great opportunity to fix the two /* XXX : Removing Area Power. */ present in the lighting code.

I'll have this in mind but at the moment coding time is limited. :(

Also you should try to use arcanist to upload patches.

I'll look into it.

Code review changes.

The console output is a relict of some driver stuff the file contained, may be another issue. I figured out that the crash is related to enabling Vector Pass output. If the switch is off all cases from above work. Going to update the description.