I found this behaviour continued independent of choosing CPU, CUDA or Optix rendering in Cycles.

You accidentally reverted some changes, but I'll fix those and commit.

• updated the wrong diff

• review fixes
• review fixes

Tooltips will automatically get a dot added at the end, so whatever ensures there is a dot at the end of every sentence is what is needed.

Regarding the missing dotes at the end of the line break, I am not sure if the guideline refers only to the first line or to every line

• review fixes

• Cycles-X: Path Guiding: turning on path guiding by default

In D15286#412851, @Alaska (Alaska) wrote:

If this isn't the right place to make bug reports about this patch, then please direct me else where.

When testing the cycles_path_guiding branch of Blender (which I believe is this patch) I could cause Blender to crash with these steps. Keep in mind this issue may be localized to my build.

1. Change the render engine to Cycles with the compute device set to CPU.
2. Disable Guiding.
3. Switch to the rendered 3D viewport.
4. Enable Guiding. Blender will crash.

If Path Guiding is enabled before switching to the rendered 3D viewport, then there are no issues.

System information if it is useful:
Operating system: Linux-5.18.0-2-amd64-x86_64-with-glibc2.33 64 Bits
CPU: Ryzen 9 5950X
Blender version: 3.3.0 Alpha, branch: cycles_path_guiding, commit date: 2022-06-25 03:11, hash: rB591c7e79b7d0

• deps: fix openpgl assuming dynamic embree
• deps: better fix for static embree
• Cycles-X: Path Guiding: UI: updating ui behavior
• Cycles-X: Path Guiding: Fixing crash when turning guiding on/off during rendering.
• Cycles-X: Path Guiding: Fixing regression for random walk SSS and RR

Thanks for working on this. I added a few comments to the specific descriptions, but realize these are sometimes just copied from the manual.

• retrives some mistakeingly deleted commas

cc @Lukas Stockner (lukasstockner97)

ok thanks for letting me know, I will do that.

Indeed if you have a bug, please submit a new report with all the information required. Is always better to do it this way than to re-open old archived/closed reports.

I have also documented a bunch of limitations with Cycles shadow caustics in the Blender manual: https://docs.blender.org/manual/en/latest/render/cycles/object_settings/object_data.html#shading

In T97784#1380705, @Alaska (Alaska) wrote:

In T97784#1380692, @Connor M. Denning (ConMan) wrote:

yeah this clearly shouldn't be Closed. took all of 30 seconds to test this guys file and up the sub divisions don't fix anything. when everything else in the software respects smooth shading your convincing no one this is reasonable

The report wasn't closed because it isn't a issue. It was closed because it was a known limitation and presumably it has been documented somewhere to potentially be fixed at a later date.

---

In T97784#1380692, @Connor M. Denning (ConMan) wrote:

... but this looks terrible if I'm moving the camera ever to hid artifacts in a pathtracer then something is wrong.
what happens when I need to do a close up of something with caustics on it? The answer is I can't or it's going to look terrible. If I had animation I'd have to have it hand painted out of each frame. why isn't caustics an experimental feature this doesn't work well enough to be called a feature.

Cycles shadow caustics is based on a rendering technique known as "Manifold Next Event Estimation (MNEE)". MNEE is known to have limitations and artifacts, and as such it is not a general caustics solution and is not recommended for a wide variety of uses, like some of the ones you're talking about.
This is not an issue with Cycles and shadow caustics, it's mostly an issue with MNEE as a whole. Many of the same limitations will occur in other render engines with MNEE.

There are other techniques available to speed up the rendering of caustics without many of the limitations of MNEE, and work is underway to investigate implementing some of these into Cycles. So hopefully things will improve for you in the future.

In T97784#1380692, @Connor M. Denning (ConMan) wrote:

yeah this clearly shouldn't be Closed. took all of 30 seconds to test this guys file and up the sub divisions don't fix anything. when everything else in the software respects smooth shading your convincing no one this is reasonable

In T97784#1351285, @Olivier Maury (omaury) wrote:

Hi @Tamino Fischer (Oristur) and @Pratik Borhade (PratikPB2123), this behavior is to be expected.

If you think of the light paths responsible for the caustics, they depend also on the position at which the interface is crossed ( = normal refraction behavior based on normal, IOR and hit point). The interface in this case is coarsely tessellated, so it's not unexpected to see some kind of discontinuity in the caustics. If you apply a subdivison modifier, these tessellation artefacts will progressively go away (as I'm sure you had noticed).

Sorry, the fix was rB328dfab4236a: Fix T97003: color-management settings can't be animated (and no, there is no chance to have this in 3.1.X -- since there is not going to be another 3.1 corrective release)

@Philipp Oeser (lichtwerk) unfortunately I cannot use 3.2, I installed 3.2 and had to return to 3.1.2 days ago because 3.2 had many bugs that interfered with my project, so my current project will have to be completed and finished in 3.1.2, its impossible for me to use 3.2 in its current state, too many bugs still

Actually, this was originally caused by rB35aedd87e78d: Fix T66913: undo after frame-change doesn't refresh properly

thank you Philipp, I explain you my scenario:
I have a complex scene where I need motion blur, and motion blur works nicely until a certain moment in which it produces an exaggerated and not attractive effect on some elements, so at that point I need to tune it down with keyframes, so for me its definitely super useful to be able to animate the shutter value,
thank you

Not sure this should be animateable tbh, but can confirm it was in 3.0.1 (not so in 3.1), will check why that changed.

Didn't have time to check the entire code yet, here's some initial comments.

This is a WIP for support for distant and background lights. This is more of an update because the heuristic is more of a placeholder at the moment. It seems to work for very simple scenes but there are definitely improvements to be made.

Hi, I think I have an exsample of this happerning in a file I can share. This is archived so I dont know if im breaking some rule I dont know about but ive got the rights to share, this project was built on blender 3.1, in 3.2 the buggyness is reduced but not complelty gone.
Its a simillar enviroment from what I can tell but ill be happy to go into more technical details and provide exsamples if I know anyones still intrested in tackling it.
Like for example should I start a new thread for the description?

If this isn't the right place to receive bug reports, then please direct me else where.

In T98367#1379836, @Michele Poletto (mickeplt) wrote:

Same error here in 3.2 downloaded from blender.org site.

Same error here in 3.2 downloaded from blender.org site.