Cheatsheet: How to get a Cleaner image with SP3

[hammerbchen]

Hi Lele

What if:

If the SampleRate shows Red in the noisy areas, should I raise noise threshold or keep it?
If the SampleRate shows Blue in the noisy areas, should I lower max AA subdivs or keep it?


Chen

[^Lele^]

Very good questions, Chen.
I think i may have found a decent analogy for the max AA / Noise Threshold debate, which would perhaps help clearing it up.

Let's divide the rendering into two stages, from the V-Ray perspective while it renders (this is NOT how it works internally, but it's a good analogy, hopefully.):
A) V-Ray needs to see things in the scene before it can choose if sampling them or leaving them be.
We can decide how accurate V-Ray's vision of the scene is with the Noise Threshold.
Lower Noise Thresholds make V-Ray look harder to find things to sample in your scene, and be more obstinate in wanting to clean them up before calling them done.
B) Once V-Ray has found things to sample, it will go about the job until the things are clean (in other words, it SEES no reason to continue sampling them), or until it reaches the Max AA, obeying our command to stop working.
If we used a high enough noise threshold, V-Ray would in fact stop immediately, no matter the max AA value, because we told it that whatever it found was good enough, so please stop looking.
If conversely we used a value of 0.0, V-Ray would keep sampling to max AA value even on the simplest of scenes.

If the SampleRate shows Red in the noisy areas, should I raise noise threshold or keep it?

Red in the noisy areas means V-Ray has found something to sample there, but got to the end of its sampling abilities (Max AA) before it considered it done.
So, no need to touch noise threshold there, which by analogy drives "how much V-Ray sees" in an image.
Rather, we need to leave more room to V-Ray to sample those areas, so raising max AA is the way to go.

If the SampleRate shows Blue in the noisy areas, should I lower max AA subdivs or keep it?

In this case, it means the max AA was never reached in those areas, so by the analogy of before, it's not "seeing enough" of the image, so it doesn't know there are things to be sampled there, or in other words it deems those areas clean, as instructed by the Noise Threshold.
So, we don't yet know if we need higher or lower max AA, we first need to make sure V-Ray samples those areas in the image, and we will need to lower Noise Threshold before being able to judge what to do with max AA.

Let me know if i answered your questions.

[^Lele^]

Thanks for all the info - much appreciated.
Re IR vs BF, you mentioned BF has sped up a lot in VRay 3.3.... but we're still looking at at least 4-5 times longer renders correct?

What Vlado already said, which is quite on the conservative side of things. ^^
In some cases, there simply is no substitute for a primary BF, unless one's willing to compromise quite severely in some aspects of the image (i mean, including the standard-run-of-the-mill, camera animation archviz project, without going into deforming objects and changeable lights.).

What follows is my very PERSONAL take on it: please do not infer anything at all in relation to V-Ray.
The IRMap had its glory days when we used a lot of interpolative techniques, purely because we could: we had no way, or memory, anyway to add all that superfine detail, in textures and geo.
And that was more than allright, at the time, because client's expectations were correspondingly lower.
Today, it takes a click to make stuff furry, at the tune of a few million strands apiece, and the speed and memory price is overall quite low.
So we use them, because people expect them.
And that is the basic reasoning behind the IRMap (and such interpolative techniques, like FG and such) being thrown out of the window: for what good can come of undersampling something that's many times smaller than a pixel, and of which in a pixel there are very many, with (potentially) very different shading each?
That's a damn hard task to make sense of in the first place, sampling within the pixel a gazzillion times, so it's little wonder sampling every other pixel produces worse results.
Pushing technologies like the IRMap to sub-pixel sample sizes (max rate above 0) makes it go very slow, negating in part the speed advantage, eat more ram (~ 4X for each level, if the sampling stayed uniform, which it isn't. but halve it and take it as a guestimate.) and still won't cure the precision issues with very thin geo.
That is where brute force sampling the pixel multiple times will lead to inherently better results, as the BF technology was meant to work this way, where the IRMap had the theoretical option there for completeness, but could hardly ever be used to its full latitude (ie. max rate of 100. ugh. that is 4^100 times the area to sample. No problem reaching those sample numbers with BF, however. Long, but very doable.)

I hear you say "it sizzles with BF, it's steady with IRMap, if i move the camera! And they rendered in the same time!".
Well, yes, that is undeniable.
What we'd be looking at, if anything sizzled, was too low sampling, and that could be cured, automagically, just by making V-Ray render for longer: no questions asked.
What stuck to the furry carpet, however, won't be per-pixel, accurate lighting, but rather a splotch representing the indirect lighting in a wide area.
And if one needed the accuracy, for whatever reason, from the IRMap, one would be very quickly out of luck.

So, i am not dissing the IRMap at all: it does have specific uses, and it WILL save you loads of rendertime IF you're prepared to do away with some accuracy, and some setup time (which will be very scene, and at times resolution, dependant).
If, however, the scene complexity goes up a bit, and the IRMap starts showing sings of fatigue, i'd take that as a sign that BF may serve me better.

In some of my pre-release tests, some very specific Evermotion interior scenes (exteriors aren't even worth comparing, it's too easy on BF. ^^), BF wasn't that much slower than the IRMap (as the scene shipped), for a very comparable noise level (forget GI. You will get noise from every other effect, and that will require some sampling...).
30% was around the best case scenario, while twice as slow for a comparably clean interior, complex scene was more of the norm (and there will be outliers. Mileage will vary, but BF is now faster than ever was.).
Which hey, i'd buy! ^^

[Alex_M]

Excellent explanation, Lele! I think you could not have explained it better than this. Both very detailed and easy to understand at the same time.

[hammerbchen]

Thanks Lele, much much clear!

I think you can draw a flowchart or decision tree of this, or even make it automatic process if we have an interface to tell V-Ray which area is "noisy". Combined with SampleRate, cycle through the decision tree with few iterations, maybe we can have one button to make all this automatic...

[padre.ayuso]

Thanks Lele, much much clear!

I think you can draw a flowchart or decision tree of this, or even make it automatic process if we have an interface to tell V-Ray which area is "noisy". Combined with SampleRate, cycle through the decision tree with few iterations, maybe we can have one button to make all this automatic...

Stupid question to throw out there, but is VRay or any other engine, actually able to tell what is "noise" and not "noise"? I mean, like it has been discussed in this thread, we tell VRay to sample more here and there, but is VRay able to tell noise from not noise? Cause if so, then yes, a button that says what an acceptable noise level is could be made. Or maybe, a picker that says "there is still noise in this area of the scene" in a test render, and VRay can then "magically" add more samples in that area in the final render and remove noise only in that area. I don't know, just asking weird questions at this point, but I do have that doubt, that the program itself can't tell what the user considers noise?

[^Lele^]

maybe we can have one button to make all this automatic...

Well, i used to say that the day that should have happened, i'd have retired.
I slowly went from yelling it to the four winds, to saying it quietly, to whispering it, to stopping altogether, because i really wouldn't want to retire too early...

[hammerbchen]

What if you're working on a complex production scene that takes 30 minutes just to render a preview image? Figuring out which settings works best takes a lot of time. Sometimes a whole day. If you have the computing power, you cold have spent that time rendering the image. If there'e a quick setup option and you can afford to disregard the render times which I suppose most of the archviz users would choose, than what's the point in meddling with any combination of settings at all?

I think what king_max means:

For archiviz people, all they want is a good, clear, no noisy image. While tweaking all those setting takes time, and even a whole day you still not sure if the settings are able to generate a nice clean image. So without tweaking all day, archiviz users wish after hit render button, they can just wait maybe two days or more, but guarantee they get good image they want.

[^Lele^]

Eheh, i was joking, earlier (and never saw the other post, Max, sorry!), as i feel we ARE indeed nearing the one-button-does-it-all: not there, but the direction is the right one, i think!

So without tweaking all day, archiviz users wish after hit render button, they can just wait maybe two days or more, but guarantee they get good image they want.

That is the way others marketed themselves, for lack of overall speed.
With SP3, an image rendering overnight has got to have reasons to do so, and good ones: most of the usual stuff was clean in minutes, on my ageing AMD.
While this sounds right like trite marketing, it really is not: removing the need for people to tweak means also removing most of the potential mistakes arising in that difficult process.
Tracing in itself isn't the slow part, often enough: human-induced over-tracing is.

With the defaults (although i think they should get a souped up name, so people liked them better, while not associating them with the past ones: something like supah-dupah-fast-n-clean-settings, or something along the same modest and low-key lines... ), and progressive, it's a very good place to be already (hence the choice), regardless of scene.

In most cases, if the defaults aren't as clean as you want them, you just lower NT and be done.
This time around, knowing you could hardly have done any better if you spent days tweaking every single bit of your scene.
So if it takes that long to clean up, that's the MINIMUM time it needs, to clean up.
And by me, that is quite the paradigm shift.

And padre.ayuso, the debate could be lengthy indeed.
Suffice to say that what you ask is precisely at the bleeding edge of worldwide research across the CG world (and not only.).
And we've got Vlado and the rest of the guys in our corner... ^^

[padre.ayuso]

Eheh, i was joking, earlier (and never saw the other post, Max, sorry!), as i feel we ARE indeed nearing the one-button-does-it-all: not there, but the direction is the right one, i think!
And padre.ayuso, the debate could be lengthy indeed.
Suffice to say that what you ask is precisely at the bleeding edge of worldwide research across the CG world (and not only.).
And we've got Vlado and the rest of the guys in our corner... ^^

Thanks Lele! You have got an AMD?

Anyhow, this thread has opened up a lot for me and I'm trying many new things. Precisely, this point about noise being acceptable and BF giving you that. I'll be increasing my hardware power soon, so perhaps going the BF route will soon be a possibility for me.

[glorybound]

I had a bathroom, that in the VFB was noisy and fireflies everywhere, however I had to send the image to the client. When I opened the file in PS, I didn't see any fireflies and the noise wasn't nearly as bad as the VFB showed. With progressive, you can save while it's still rendering, so I would save and see if it is actually better than you think it is. Even though this one was still noisy, the client didn't even notice it.

[^Lele^]

Thanks Lele! You have got an AMD?

Ahah, yes i do!
Good old 8350, still hard to beat for price/performance, if one isn't looking at squeezing the wallet dry...
https://www.cpubenchmark.net/cpu.php...350+Eight-Core

Sure, for 5k i could go three times faster, but this rig served me really well since i bought it in 2012, with very minor updates (one GTX 980 for a 660Ti).
Perhaps not farm material, but for daily (heavy) use, is actually quite the deal...

[hammerbchen]

Hi Lele,

How can I follow your V-Ray 3.3 two rules, combine with "V-Ray Toolbar/ V-Ray Quick Settings"? does the "V-Ray Quick Settings" still valid or I should forget it all together?

thanks,

Chen

[^Lele^]

Well, the quick settings script was cooked up before sp3 and the big sampling changes across V-Ray, so if you use the new approach, it's probably best to not use it.
However, it's still entirely valid if one chooses to go for local subdivisions setups, for whatever specific reason.

[eyepiz]

Well, the quick settings script was cooked up before sp3 and the big sampling changes across V-Ray, so if you use the new approach, it's probably best to not use it.
However, it's still entirely valid if one chooses to go for local subdivisions setups, for whatever specific reason.

Any chance those V-Ray Quick Settings getting updated anytime soon? Or does nobody actually use them.