Cycles feedback

Thanks a lot @Alaska
I just noticed I already subscribed to this task a while ago. :+1::wink:

Hey Devs, I got confused a bit. Says that Blender 3.0 catches Indirect Light but it still seems to be Black and white and doesn’t catch indirect light bounce or at least I’m not seeing the color. If I missed something, I would love to know or if I’m mistaken, I can provide screenshots comparing the same shots in Clarisse and Blender with the Indirect Light being caught. Talking about the shadow catcher btw.

The shadow catcher catches indirect light in the “Shadow Catcher” pass. You need to enable the “Shadow Catcher” pass in the “View layer Properties” tab.

ohh thanks! I was expecting it to be seen on the viewport

So wait, how am i supposed to use that? Do i add it to the footage cause it seems like it’s entirely filled with white spaces instead of alpha?

I was about to ask the same and then saw this on the release notes:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles

1 Like

Also there is the official documentation of Blender here:

image

Not much of info but basically it says “multiply it onto your background”. And it works… beautifully.

2 Likes

On the subject of the new shadow catcher, can someone please clarify the behavior of the second line:

Shadow Catcher

The shadow catcher was rewritten. New features include:

  • Indirect and environment light support, for more accurate compositing
  • Option for lights to be considered included or excluded, that is if they are real or synthetic objects

edit: Alaska explanation in the next comment

When a light has the Shadow Catcher option enabled, it is considered a “real life object”. As such the CG lighting information caught by other shadow catching objects in the scene won’t include any of the light contribution from that light as the contribution from that light is already in the real life footage, it doesn’t need to be added again.

When a light has the Shadow Catcher option disabled, it is consider a “CG object” and as such the other shadow catcher objects in the scene will catch the light contribution from it and “add” it to the real life footage.


Here’s an example. Here is a “real life” scene. It consists of a red light, a blue light, and a plane.

I now wish to add a cube to that scene using the Shadow Catcher to add the shadows and other light contribution. The way I do this is I add a plane with the same position and material properties as the “real life” plane with the Shadow Catcher option enabled. I also add lights with the same intensity, colour, and position as the “real life” lights so my CG objects have the same lighting as the “real life” scene. These lights should have the Shadow Catcher option enabled as the contribution of those lights to the scene is already in the “real life” image. The same way the plane has the Shadow Catcher enabled as the plane already exists in the “real life” image.

I then render it out and do the compositing and I get this result:

But now I want to add a new light to the scene, using CGI and the shadow catcher. This can be done by adding the new light to the scene, and having the Shadow Catcher option disabled. The option is disabled because the new light I’m adding isn’t in the “real life” scene. It’s part of the CG scene. Here’s what the scene looks like with the new light added:

If I had left the new light with the Shadow Catcher option enabled, it is assumed that the light I’m trying to add to the “real life” scene is already part of the scene. As such the shadow catcher produces incorrect results, because it’s only capturing shadows for a light in the “real life” image, but the light actually doesn’t exist in the real life footage so only part of the expected information is actually caught. Here’s what that looks like:

11 Likes

Probably the best explanation about how the new shadow catcher works. It would be awesome if someone could include this example in the documentation.
Thanks!

hello Alaska thank you for the detailed explanation much appreciated! I will try it out

Hi everybody, excuse my inexperience on here but I’ve been testing all three recent version but I’ve found only in 3.1.0 while rendering using system settings CUDA with both my AMD processor and NVidia graphics card selected for Cycles rendering I get a (top) half scrambled picture, but if I select only one at a time (graphics or processor) then it renders fine. It works as it should in the earlier version 3.0.0 and 2.93.6.

This sounds like a bug and should be reported. To report a bug, select from the top of Blender Help -> Report a bug and fill out the form.

Excellent thanks Alaska

1 Like

I have had this happen to me yesterday - completely out of nowhere. Suddenly none of the Cycles-x releases rendered correctly on Cuda (gtx 1060). In the top third of any render all the triangles were messed up. Optix worked fine, stable Blender with Cuda too. It dissapeared after updating the nvidia driver. I am curious what it was though because I hadn’t really changed anything other than running the newest alpha.

When viewport rendering to find the best noise level for the final render, you often find that the noise level was inadequate so you need to lower it a bit. The problem is that Blender will restart the render from the beginning, leading to unnecessary waiting times.

I’d suggest either or Both of the below:

A) Resume rendering rather than restarting when user changes noise level.

B) User sets the noise level extremely low so that it will render until manually stopped. Then show the current (lowest) noise level of the pixels that have not yet met the noise level requirements. This could be shown as a toggleable heat map (lowest incomplete to highest noise levels) + text info overlay next to the sample in the top left.

1 Like

Something like what you have described has been reported here and has been fixed. ⚓ T93283 top third of defuault cube render not rendering properly

A new version of Blender from the build bot will be available soon with the fix.

Good news the new version “blender-3.1.0-alpha+master.d1a4e043bdb0-windows.amd64-release” has fixed the issue. thanks again Alaska for all your help, and the Dev’s who work so hard to provide a great piece of software.

I very much like the new noise-based threshold system in cycles-x, but I’ve found I lose quite a bit of time tinkering with the “noise” and “max samples” values, trying to optimize my render’s time and noise. I think a lot of it could be mitigated if cycles gave the user some feedback on the noise levels of the finished image, or – better even – in real-time as the image gets rendered.

The two (related) questions I find myself asking time and again, and would like cycles to help me answer are:
a) Did my render finish because the noise levels were met, or was it because the samples number was reached? The answer, naturally, changes from pixel to pixel.
b) Which parts of my render are most problematic, noise-wise?

Ideally, cycles would display a coloured overlay indicating the noise levels of each part of the image , that gets updated as the render progresses, along with a legend. I don’t know how feasible this would be, but since cycles must calculate noise levels for adaptive sampling to work, I hope this is not too unrealistic?

Perhaps @Alaska or @brecht could weight in.

4 Likes

I’m testing viewport performance in yesterday’s 3.0 build (with my gtx 1080)
My verdict: It’s so much better looking but - surprisingly - it feels much slower than in 2.93 which I use as a benchmark.

I’m not sure how should I write about this because my results are controversial.
(if this was discussed already then sorry and please point me to any relevant info)

So - on one hand - at the same sample count (let’s say 25) 3.0 generates waaaay better looking results (no matter if Noise Threshold is ON or OFF)
In fact it generates better looking results at FIVE samples than 2.93 generated at TWO HUNDRED.

So this is crazy good, right?

No, because getting to that 25 or even 5 samples are muuuuuuuuuuuccchhh slower than it was in 2.93
So I’m getting huge and beautiful incremental updates in the viewport render but I’m getting them super choppy and slow.

After I wrote all this down I realized I still can’t describe it well enough so here’s a video of it.
2.93 vs 3.0 (with and without Noise Threshold ON but it doesn’t make much difference)

So is it me haven’t gotten used to this new method or does this viewport behavior feel worse to others too? Is it choppy or I perceive it as choppy? And does the semantics matter if it feels slower? :thinking:

1 Like