9
$\begingroup$

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 < LightSamples. To explain it better:

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

And for example, with AA=64 & 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

$\endgroup$
  • $\begingroup$ What exactly do you call "Arnold Renderer theory"? I think these results would not be surprising - neither in Arnold nor in Cycles, it depends on the scene. $\endgroup$ – lbalazscs Dec 30 '16 at 15:02
7
+100
$\begingroup$

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:

enter image description here

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:

enter image description here

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

enter image description here

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:

enter image description here

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"):

enter image description here

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

$\endgroup$
  • $\begingroup$ 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: $\endgroup$ – Marc Alloza Ayxendri Jan 3 '17 at 1:39
  • $\begingroup$ Check out the updated answer. $\endgroup$ – lbalazscs Jan 3 '17 at 4:48
  • $\begingroup$ maybe it helps you if you render the comparison images in Blender and enable the render passes for Diffuse Direct, Diff Indirect, etc. You might be a bit surprised as of what you get there when you just compare pass by pass. $\endgroup$ – aliasguru Jan 3 '17 at 8:07
  • $\begingroup$ @aliasguru Indeed, interesting, the indirect passes are actually better in the second image (which is overall worse). I will update my answer with more analysis later. $\endgroup$ – lbalazscs Jan 3 '17 at 12:54
  • $\begingroup$ Is 64x1 the same as ordinary path tracing in Cycles? $\endgroup$ – John Dvorak Jan 7 '17 at 1:39
2
$\begingroup$

I think there is something that has been forgot here, you couldn't just compare camera samples(AA) with diff/gloss... samples because there is something missing:
The bounces
AA samples aren't related to ray bounces but Duffuse/glossy... samples are.
Samples are how many times you shoot a ray and bounces how many time it bounces in the scene.
For AA it's the number of "rays" for a pixel (2D) but for diffuse/glossy... samples it's the number of rays shoot * the number of bounces.
In other words AA sample are multiplied by one bounce (2D pixels) and diff/gloss... samples are multiplied by the number of bounce(s) set up in light paths. Wich can make a huge difference.
Correct me if I'm wrong.


Edit
In your exemple 64AA*1diffuse VS 8AA*8diffuse, you have the same number of bounces for the diffuse but not for the AA, if we consider AA = 1(pixel)bounce*by the number of sample.
So it's logical to have a difference since AA (for what I understand of it) it's a kind of blending between pixels, so if you change the amout of blending you don't have the same pixel at the end.


Edit 2 In fact I've forgot something too, and it's directly related to your question about the difference between a render in pathtracing or branched pathtracing. Pathtracing shoot a ray that bounce on a surface, the surface deviate the ray and it continue like this until it reach the number of bounces you specified in the light path.
Branched pathtracing act differently, a ray is shoot but when it hit a surface it's split in serveral rays. I couldn't explain much but a bit more infos here: Stack Exchange question about branched pathtracing
So the render is different because the rays don't act the same way.

$\endgroup$
  • $\begingroup$ You are correct Mareck, but one thing is the theory and the other one is what's happening using Cycles. By AA * Diff/Gloss * bounce has different lighting results increasing Diff/Gloss instead AA $\endgroup$ – Marc Alloza Ayxendri Jan 4 '17 at 18:27
  • $\begingroup$ I could be wrong but I'm not sure it's theory and practical related. In your exemple 64AA*1diffuse VS 8AA*8diffuse, you have the same number of bounces for the diffuse but not for the AA, if we consider AA = 1(pixel)bounce*by the number of sample. So it's logical to have a difference since AA (for what I understand of it) it's a kind of blending between pixels, so if you change the amout of blending you don't have the same pixel at the end. $\endgroup$ – Mareck Jan 4 '17 at 19:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.