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.

Thanks Jesse, I merged to that report since we confirmed the issue to be this particular case.

There is also T85512 which deals with the same .274 cutoff.

Good catch, thanks Evan!

The denoise albedo pass has a hard transform at the square root of 0.075 which is 0.273861

In T99087#1378537, @Omar Emara (OmarSquircleArt) wrote:

The issue seems to be with Clear Coat in Principled BSDF in this case. A simpler example is to have two planes, the lower one has a default Principled BSDF with Clear Coat set to 1, while the upper plane has a completely transparent shader. A lamp is positioned away from them along the x axis.

One would expect no different since the upper plane is transparent, but it seems to be less noisy and brighter.

cyclesTransparentClearCoat.blend782 KBDownload

The issue seems to be with Clear Coat in Principled BSDF in this case. A simpler example is to have two planes, the lower one has a default Principled BSDF with Clear Coat set to 1, while the upper plane has a completely transparent shader. A lamp is positioned away from them along the x axis.

Doesn't have to be a full pause functionality. It'd also be great if you could say 'pause after finishing current render tile' :)

The code did change a lot, and the out-of-date inlined comments (which are also in the wrong lines now!) do not make it easy to have a manageable review. Lets move to the D15254 and archive this revision.

Update to the latest branch state.

I also thought so. But how do the versions prior to the introduction of Cycles X so it so quickly?

The edges might be just noise also. Edges by themselves will have anti-aliasing noise and that can get amplified with noise from other sources.

I think this just a consequence of the design of the rendering mechanism, canceling is only allowed after the current piece of work is done processing, so I don't this can be considered a bug.
But it does take a significant amount of time, not sure if canceling can be made more granular, so tagging the module for more information.

Any temporary solutions has a problem of crating legacy that is always hard to enhance and maintain.

In T96740#1366146, @kayfee (hercules) wrote:

So, NO support for polaris cards,

In T96475#1376513, @Eugene Du (APEC) wrote:

Not acceptable "trade-off", for architectural modeling...

Not acceptable "trade-off", for architectural modeling...

This update to the revision supports point lights in the light tree (to some degree). Most tests are passing, but I'm still getting a few errors. Given 100 point lights, this is the default implementation's render:

Could be the same as T69535: CPU + GPU render precision differences for small, far away area light?

Sorry, made a mistake (GPU was disabled when testing 2.93 -- it is actually also the case there)

OK, can confirm.
Seems to be more prominent with GPU (but also apparent on CPU).
This was fine in 2.93 (probably came with CyclesX)

In T68915#1375094, @Ryan Rickett (glencandle) wrote:

In T68915#1374927, @Neo_Hoa (NEEO) wrote:

The meaning I can centrally manage light links here without click properties for each light, it clearly lists exclude and include options, includes all objects and lights in the scene, all operations here, maximize reduction mouse click and makes life easy.

In my opinion this still makes the process over complicated, especially for smaller scale projects, VFX/motion graphics/etc. How many times do you have hundreds of lights in a scene!? I think it is much more common to have only a few lights.

Anecdotally: Imagine you have your scene molded and you start placing your lights. It would be a huge benefit to be able to tweak the light settings (type of light, intensity, color, etc) and include/exclude objects to illuminate, all in one interface, without having to click away. This is a lot easier than your proposed method.

Your solution is very Maya, I will grant you that, but then again Maya is an over-complicated team sport (which is I why I stopped using it) and Blender is better suited for individual artists; so let's just please focus on simplicity.

We can always start here and add a central Light Linking tab later, no?

In T68915#1374927, @Neo_Hoa (NEEO) wrote:

The meaning I can centrally manage light links here without click properties for each light, it clearly lists exclude and include options, includes all objects and lights in the scene, all operations here, maximize reduction mouse click and makes life easy.

Great, thank you, Philipp Oeser!
Now the only remaining issue is that Viewer Image doesn't exist in Headless mode (when Blender runs with "-b" in commandline), which is often used for batch rendering in background.

awesome. Yeah read only would be sufficient. At the moment it's not actually possible to find out which node will supply the render. I'm having to ask users to select the composite node manually before rendering to let my addon know which branch it should work on :)

Like I said: makes sense probably, but a bit more work since managing setting NODE_DO_OUTPUT would mean carefully checking any sideeffects this could have (could be painless... but havent checked on this yet).
My patch is just mimicing existing behavior, what you propose is more or less a feature request (one that makes sense, no doubt).
Could look into this next, but as immediate step, D15203 should already bring us across the goalline of this report, no?

Having access to the NODE_DO_OUTPUT tag in python would solve the issue because it would enable python to also find the viewer node that's in use and the composite node that will be outputting at render time by doing:

If you have seen maya light linking UI you'll understand that this is a very clever design.

In T68915#1374813, @Ryan Rickett (glencandle) wrote:

I don’t see how putting it in the render properties makes sense. You nailed in that second image above, stick an include/exclude list under Light Linking in the Light properties. Simple and powerful.

reg. active_viewer or active_composite: this might make sense (but is more of a refactor, since internally, there is no such distinction, there is only the NODE_DO_OUTPUTtag (used for viewers as well as composite) and from this, the active gets determined on the fly). Will discuss this, but shortterm, will just post P2990 as a proper Diff (this will make it so once you set the viewer active via python, it will also properly be tagged NODE_DO_OUTPUT -- same as done via a mouse).

In T68915#1374800, @Neo_Hoa (NEEO) wrote:

In T68915#1374747, @Nebulous (Nebulon1212) wrote:

Why not start small and work up. If you want to keep it simple for now and avoid having light linking scattered all over the interface, why not just make it part of the object properties like in LightWave (image attached).

Then people could just right-click on the object from Blender's Outliner to bring up a panel that lets you check or uncheck the light that you'd like to exclude.

(As I add more lights, they populate the list and it's per-object).

I'm sure, at this point, people would like to have any form of light linking -- even a rudimentary one.

I don't think it's smart, when there're too many lights and objects, it will definitely increase the amount of mouse clicks, imagine you have to click on each light or object's property, this may be hundreds of times mouse repeat operation! We just need to add a double list to the render bar, simple, easy and clear, that's all, this is the best way to handle it till this moment.
idea made by someone, just don't do this👇🏼

This feature is a must for an advanced rendering engine.

I don’t see how putting it in the render properties makes sense. You nailed in that second image above, stick an include/exclude list under Light Linking in the Light properties. Simple and powerful.

Sorry, I mean we can add a double list called ‘light linking’ with drop-down in the 'render properties' bar, most of the functions are here, it's also UI logical.

What does “add a double list to the render bar” mean? What is the render bar?

In T68915#1374747, @Nebulous (Nebulon1212) wrote:

Why not start small and work up. If you want to keep it simple for now and avoid having light linking scattered all over the interface, why not just make it part of the object properties like in LightWave (image attached).

Then people could just right-click on the object from Blender's Outliner to bring up a panel that lets you check or uncheck the light that you'd like to exclude.

(As I add more lights, they populate the list and it's per-object).

I'm sure, at this point, people would like to have any form of light linking -- even a rudimentary one.

Why not start small and work up. If you want to keep it simple for now and avoid having light linking scattered all over the interface, why not just make it part of the object properties like in LightWave (image attached).

@michael campbell (3di) yeah, triggering a set/get to activate a viewer by name would be fantastic.

would it not make more sense to be able to get/set with

Regarding these other questions: question1, question2
This other test does not seem to work, having two viewer nodes and trying to activate one from Python:

I don't think there's a way to get the active viewer or composite node for a scene is there? Oh wait, active just means seleted doesn't it. For a moment I thought we could now find out which are being used for the backdrop and output.

@Philipp Oeser (lichtwerk) I have downloaded 3.3 and tried the following:

I didn't spot anything immediately wrong in transferring to the device with a quick skim over the code, but let me know if I need to take a closer look.

Begin integrating the light tree traversal into the device kernels. Just a few notes:

• The splitting threshold is currently not being implemented (more discussion is needed) because Cycles samples light sources one at a time.
• There seem to be some issues when constructing or transferring the light tree to the device. This must be fixed before further testing can proceed.

The problem is still there with Blender Version 3.2.0 (3.2.0 2022-06-08) on Macos 10.13.6.

today i update my mac os to 10.15.7 and try use blender 3.2