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.

If your wondering why I didn't add the subdivide to the file I just don't know if the bug is caused partly when adding the modifier and not just when changing the levels. Know you'll have to add the modifier your self to test. between level 6-7 it gose from 1 gig to 11 I'm thinking it should only go up to 4 am I missing something?

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

In T96718#1349867, @Alaska (Alaska) wrote:

@Connor M. Denning (ConMan) , reports about different bugs should be made in different bug reports. Please report your issue elsewhere by selecting from the top of Blender Help → Report a bug and filling out all the relevant information.

In T96718#1349609, @Lukas Stockner (lukasstockner97) wrote:

Can reproduce, the problem appears to be caused by the shader on rock.005.

Something is going wrong with SVM there, it's reading an uninitialized location from the stack, which returns garbage, which in turn gets used as an emission value, resulting in the bright pixels. That also explains the differences between compilers/platforms.

In T96576#1327386, @Alaska (Alaska) wrote:

In T96576#1327321, @Connor M. Denning (ConMan) wrote:

idk if related but in some test renders I did recently with like 256 bounces or something I thought it looked overly bright for having shaders that shouldn't be emitting more then possible I had one that wasn't even fixing that it looked to bright to me. If I can reproduce it I'll post it most likely I have another report in the works though so might take a few days. But I'm really not getting why there being a .blend that test just about every thing like this in one go hasn't been some we have for each blender release that would fix things like this from getting missed in optimizations.

There was a issue reported recently of the Principled BSDF reflecting more light than it theoretically should in the specular part of the material when the material base colour was above a certain threshold. This might of been what you were experiencing? If so, it has already been reported and it is not considered a "bug". Apparently this is because the Principled BSDF is based on a shader from a white paper from Disney. And the shader proposed by Disney has this exact same issue. Cycles replicates this issue to ensure compatibility between other software using the same shader model (which also most likely have that issue).

idk if related but in some test renders I did recently with like 256 bounces or something I thought it looked overly bright for having shaders that shouldn't be emitting more then possible I had one that wasn't even fixing that it looked to bright to me. If I can reproduce it I'll post it most likely I have another report in the works though so might take a few days. But I'm really not getting why there being a .blend that test just about every thing like this in one go hasn't been some we have for each blender release that would fix things like this from getting missed in optimizations.