Branched Path Tracing About Branched Path Tracing, I'm using the Arnold Renderer theory without Square Samples as many forums said, but seems Cycles goes different.

I have better times/results with higher AA Samples value and less Light Sample value than AASamples &lt; LightSamples. To explain it better:

AA = 128 &amp; SS = 1
better than
AA = 8 &amp; SS = 16

And for example, with AA=64 &amp; SS=1 is faster and with better results. And I can use my GPU 1070...
Following maths I don't understand well what's happening, are there any explanation about this?

And one last thing, Path Tracing has different results. SS Indirect is different between Path Tracing and Branch Path Tracing... Anyone knows why?

Thanks in advance



About Arnold Renderer theory, I want to explain that:

AA Samples are for aliasing and multiply every other light component sampling. If you want less noise on glossy component you only have to increase these glossy samples, not others. It contributes to maintain render times under control.

But what I've found on Cycles is that this theory is not real. It makes increase render times and indirect light change on a non-physical way.

In Cycles is not the same:

AA= 8 * Diffuse= 8 == 64
VS
AA= 64 * Diffuse= 1 == 64

You won't have the same results, times, etc... Seems the second way is the correct one for Cycles nowadays...



Thank you so much for your far explanation. This is what I read and understand about "Arnold theory" or this kind of engines. I understand that AA Sample is a multiplier for every kind of ray on the scene, like diffuse, glossy... And at the same time which define super-sampling/over-sampling. Following this idea, the best way to take control and lower rendertimes is to set low AA value and increase any ray as we need. And here is the BUT... When I follow this steps I have unwanted results:

And here is the BUT... When I follow this steps I have unwanted results: - I have higher rendertimes for the same results - Appear another kind of noise with green, red, blue pixels I can't clean with more samples. - If I push up diffuse samples, the indirect power increase and give me unphysical results

All these makes me think Cycles need core development to fix it, because if I increase only AA samples and other rays at 1 everything goes perfect: less noise, faster, no errors. And I can use my GPU (970 and 1070)

Is this an error? Am I losing something?

I hope I have explained better. Thanks to every contribution
So what is "Arnold Renderer theory"? 

Let's read some Arnold documentation:


  Camera (AA) Supersampling control over the number of rays per pixel that will be traced from the camera. The higher the number of samples, the better the anti-aliasing quality, and the longer the render times. (...) This control acts as a global multiplier of all the different rays, multiplying the number of Diffuse and Glossy rays. Motion blur and depth of field quality can only be improved by increasing Camera samples.


This is also true in Cycles:



As you can see, the total number of SS samples is the number of AA samples multiplied by the number of SS samples.

How should we work with these values? As another Arnold page explains:


  Noise nearly always comes from insufficient sampling, but increasing sampling for the wrong rays can make the render times increase without helping to remove the noise. As an artist is usually working to a render time limit or amount of rays the aim is to allocate those rays as effectively as possible to minimize the noise in the most efficient manner. So if the Camera samples have to be increased to remove DOF noise, the other settings must be lowered to keep render times manageable. However, if DOF or motion blur is not a concern, then increasing Camera samples would fix all noise elsewhere but would also slow render times from the unnecessary rays.


This suggests that you have a rays budget, all rays are equally useful and expensive, and 64 AA rays with 1 diffuse ray per AA ray should be the same as 1 AA ray with 64 diffuse rays per AA ray. Let's examine this in detail. I will call the following configuration the 64*1 config:



And I will call the following the 1*64 config:



If I understand your question correctly, you expect these two configurations to create the same results equally fast, but this is not true: the 64*1 is better and slower than the 1*64: 



Is this a bug in Cycles? 

No, I actually tested it in Maya+Arnold, and there are also similar differences. The Arnold settings were the following (note that Arnold always uses "squared samples"):



OK, it is not a bug, but how do you explain the difference?

One obvious difference is that the 64*1 image is anti-aliased, while the 1*64 is not. About the rendering time also consider that the initial number of AA/camera rays does matter, those initial AA/camera rays have to be calculated, and 64 AA rays are more than 1 AA ray. And probably the code is full of tricks and optimizations that could work in one specific case, but not in another.

Conclusion: Don't take the "Arnold Renderer theory" about the "rays budget" too literally, even in Arnold it does not work exactly that way. It is not enough to think about the number of rays, it is necessary to analyze the render passes in every scene, and play with the settings until you find the optimal configuration.



It is also interesting to check the individual render passes. 

The shadow pass is very ugly in the 1*64 case, it contains only black and white, suggesting that Cycles uses only one shadow ray per AA ray.  

The diffuse indirect pass was actually better in the 1*64 setup.

The lack of AA made several 1*64 passes ugly, but for some passes the anti-aliasing was bad in the 64*1 version (and in the simple pathtracing) as well. 



As an interesting fact, I see another problem with these settings, as described here: Minimum number of samples for the Branched Path Tracing