In T71908#1004171, @Alexander Court (spiegelball) wrote:

A workaround for some cases is to reassign the animated property from the evaluated datablock to the original one at the end of the script, e.g.:

...

obj.scale = obj.evaluated_get(deps).scale

EDIT:
In this case the following line enables animation of the ocean modifier:

scene.objects["mesh_cache"].modifiers["Ocean"].time = scene.objects["mesh_cache"].evaluated_get(depsgraph).modifiers["Ocean"].time

A workaround for some cases is to reassign the animated property from the evaluated datablock to the original one at the end of the script, e.g.:

Contrary to T79846 the problem is still there after D8676.

Probably this is also similar to T79846.

Just realized the mouse has to be over the left panel in the dopesheet editor for the shortcut to work. -.- Thanks for response and sorry for the noise!

• Correct versioning code.
• Merge branch 'master' into vol-fac
• Fix versioning code and light type name.
• Merge branch 'master' into vol-fac
• Implement code review notes.

Thanks alot for this quick fix! From the user perspective I'd even propose to make "Keep Transforms" the default case and drop transforms with the alt key. This would match behaviour of other DCCs.

From an artist point I'd prefer to have the subpixel jitter decoupled from soft shadows. Whilst subpixel jitter seems to be a useful addition in most cases, soft shadows often come at high cost and are not used.

Can you share a .blend file with your setup?

@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.