V-Ray Scene Optimisation Script

[^Lele^]

I lack multi-scatter, but i can hazard a guess: either Embree doesn't support it, or my turning the default geo mode to static kills your RAM.
Try disabling Embree, and return the Default Geometry to "Auto", and see if that helps.

I'll make a note not to change those two parts from the original user settings.
EDIT:Indeed, even without multi-scatter (and the corresponding geo), the displacement set as static and the huge VFB, with 22 Render elements (each at 32bpc, when displayed in the VFB) eats around 12gb of ram.
Making me think a swap to disk is in order on your side.

[^Lele^]

Your plant sucks.

And you ought to feel the SMELL of that, too!
Wild GARLIC, man, i don't do things by halves! :P

[joconnell]

Pfft, typical frenchman :P

[rjohnson33]

Just in the interest of that Vray/Corona comparison (although not really the main point of the thread, sorry just thought it was worth noting):

The Vray conversion of the interior test scene looks noticeably brighter and with more contrast throughout than the Corona version.
(I'm just looking back and forth on my monitor between Corona rendering in the background and the latest post of vr_scene06).

There's a blown out area on the ceiling adjacent to the window and in several other areas in the Vray render which don't occur with the Corona set up.
The lighting seems more balanced in the Corona render, as though there's some equivalent to Reinhard colour mapping applied.
I think there might be - I don't know Corona very well but it looks as though there's an option for Highlight Compression in the settings that has a value of 50.0 entered.

[kosso_olli]

I lack multi-scatter, but i can hazard a guess: either Embree doesn't support it, or my turning the default geo mode to static kills your RAM.
Try disabling Embree, and return the Default Geometry to "Auto", and see if that helps.

I'll make a note not to change those two parts from the original user settings.
EDIT:Indeed, even without multi-scatter (and the corresponding geo), the displacement set as static and the huge VFB, with 22 Render elements (each at 32bpc, when displayed in the VFB) eats around 12gb of ram.
Making me think a swap to disk is in order on your side.

Thanks for taking a look Lele.
The displacement was set to static by me, along with the default geometry mode in the Vray settings. That way the rendering is much quicker, albeit at the cost of ram. My machine has 64gb ram, with your settings I am somewhere around 59-60gb while rendering. When I open the scene with my settings though, I am at around 40gb, which is much lower. Basically, my displacement settings were the same as yours (static mode and so on), so I don't know where the difference comes from. Maybe it is from the light cache calculation with your settings? Mine were quite different.

EDIT: The multiscatter thing is a leftover from a little experiment. It shouldn't be there, you can ignore it.

EDIT2: Just mixed my old settings with the light cache numbers from your vfx/complex preset to see if it makes any difference. The amount of ram used stays the same, about 40gb. Strange.

[Paul Oblomov]

Just in the interest of that Vray/Corona comparison (although not really the main point of the thread, sorry just thought it was worth noting):

The Vray conversion of the interior test scene looks noticeably brighter and with more contrast throughout than the Corona version.
(I'm just looking back and forth on my monitor between Corona rendering in the background and the latest post of vr_scene06).

There's a blown out area on the ceiling adjacent to the window and in several other areas in the Vray render which don't occur with the Corona set up.
The lighting seems more balanced in the Corona render, as though there's some equivalent to Reinhard colour mapping applied.
I think there might be - I don't know Corona very well but it looks as though there's an option for Highlight Compression in the settings that has a value of 50.0 entered.

My scene was set up with reinhard mapping (see rghost link). Lele just got rid of it I think he was just trying to lower the noise only.

[lllab]

made me curious the long time on that file so i tested here.

this is a 5min render using Pauls file and changed to my setup, progressive with high min shading rate at 16, AA 1x32x /0.01, let it cook for 5min. br/lc. (lc changed a bit) rest unchanged. is a dual xeon 16 core.
of course has some noise left for the time, (corona renders had also some noise if i remember correct)

Stefan



edit with shading rate 32 it gets a tiny bit less noise even, maybe seems the high shading Vlado i think suggests rate helps here (looks quite ok actually after 3min already)



ps.: tomorrow i try your script Lele

[rajdarge]

thanks a heap lele for all this amazing stuff.
I assume the calculations are done on a per image basis. Does it take into account the render dimension for your sweet spot for LC?
Is there a way to disable the rendering all together, and especially changing the renderheight renderwidth as I generally turn off get settings from max?
Raj

[kosso_olli]

I lack multi-scatter, but i can hazard a guess: either Embree doesn't support it, or my turning the default geo mode to static kills your RAM.
Try disabling Embree, and return the Default Geometry to "Auto", and see if that helps.

I'll make a note not to change those two parts from the original user settings.
EDIT:Indeed, even without multi-scatter (and the corresponding geo), the displacement set as static and the huge VFB, with 22 Render elements (each at 32bpc, when displayed in the VFB) eats around 12gb of ram.
Making me think a swap to disk is in order on your side.

Lele, tried turning off the displacement and renderelements. Now everything is fine on the ram-side, but the rendering still comes to a halt as soon as the buckets hit any geometry.

[^Lele^]

My scene was set up with reinhard mapping (see rghost link). Lele just got rid of it I think he was just trying to lower the noise only.

Correct, Paul.
I don't do renders in anything else than LWF, period. ^^

of course has some noise left for the time, (corona renders had also some noise if i remember correct)

Indeed, the excersice for me is getting rid of any visible noise.
It's common knowledge that the cleaner the image has to get, the harder it becomes for the renderer to get the job done.
Just like for many other endeavours in life, it's the last 1% which makes all the difference.
If i accepted higher noise levels (and plugged my ears as to the compositing department yells), my renders would go a LOT faster.
You all have the EXR, with all the relevant render elements.
The challenge, if any, is to get a quicker render with a different approach for the SAME cleanliness.
A/B will help, for now, until i manage to get some form of numerical noise analysis to precisely pinpoint just how clean the image REALLY is.
Subjective results are incredibly hard to fathom, and they change wildly based on the display device used, the type of lighting in the environment one is watching the image in, and ultimately individual color sensitivity.
I am working on a calibrated monitor to make sure that at least one of those factors is tied down, and my usual working environment does not have particularly changing lighting conditions across the day.
There's still the subjective perception at play, so that's why an A/B is the only way to gauge it now.

I assume the calculations are done on a per image basis. Does it take into account the render dimension for your sweet spot for LC?
Is there a way to disable the rendering all together, and especially changing the renderheight renderwidth as I generally turn off get settings from max?

Yes, in the case of my script i use the max's render height and width as specified in the common tab.
I will add a check to take the V-Ray VFB one when "get resolution from max" is disabled.
The spinner for the sample rate allows you to modify the "sweet spot", but i suppose showing in the script's info panel what the actual LC subdivs are would help understanding what's happening, in "old money" (ie. with a fixed number of subdivs, and a linear fraction of the image size for samples).
I didn't, this far, purely out of old-fashioned laziness: i hate the typing involved, eheh.

In the while, i tried the MSR approach on my scene, with both a fixed 8 AA and a 1/8-2/8 adaptive AA.
However, I could NOT get a CLEANER render for LESS time.
I could get a noisier one, for less time, or I could get it nearly as clean, but for a projected time of over twice my render.
Both defeat the comparison.
Finding the same sweet sampling spot (ie: figuring out what exactly 2306 SPP are under "divide" conditions is hard. Which is why i took to the script, and the "divide" option off.).
I'll need to do some more maths on my side for an apples-to-apples comparison, and a proper benchmark, and will try so today.

[^Lele^]

Lele, tried turning off the displacement and renderelements. Now everything is fine on the ram-side, but the rendering still comes to a halt as soon as the buckets hit any geometry.

Very odd.
I rendered a region here from the scene you gave me, and it went through just fine with no change to the file whatsoever.
Then again, i am missing also BerconNoise and ColorCorrect.
Perhaps, with 16/16 AA, the bercon noise set to pretty high iterations is overkill?

[^Lele^]

so, i have found the MSR factor:
From the scene i last uploaded, turn "divide shading subdivs" on, and set the MSR to 96.
The noise level and patterns are identical, as identical are the samples per pixel.
It's rendering currently, and I expect it to be quite identical, if not slightly faster, than the render i posted yesterday.
We'll know in around one hour. (meh.)

[^Lele^]

As expected, it took nigh the same exact time as my previous setup, for an identical image (given the sampling IS identical across the board, shading and AA wise).
1h10mins04sec. Notice any difference may be down to one core being used for browsing and such, so it's completely irrelevant to the test.

Instead of reposting the render elements, her's a difference of the two images, gained by 1000.
they are identical to the 5th decimal place.



So, as stated before:
Vlado's approach is JUST AS GOOD as the script's: provided the AA is fixed and not allowed to run amok, and the shaders / lights have the same sampling, there will be NO speed or quality difference in either method.

edit:here's the link to the thick EXR for those who would like to do the difference themselves.
https://drive.google.com/file/d/0B1P...it?usp=sharing

[rajdarge]

can I ask a stupid question: exactly what is Vlado's approach? is it spelled out somewhere. I've been clicking a stupid camera the last 4 years, my render finger is a little rusty.

[^Lele^]

basically, you can leave the subdivs on everything to their default, set your AA as it's needed to clean dof/moblur/high frequency geo or texture detail, and the simply use the "min shading rate" spinner to sample multiple times per camera ray shot.
This, in turn, lowers the work the AA has to do to clean the shading, which given the slower nature of the camera rays, speeds up the rendering for a given cleanliness of the final image.
In my case, there's a wee bit more to "leaving everything to defaults", as it's outlined somewhat sketchily in the earlier posts.
Of course, once both approaches are merged (ie. my small tricks to gain more speed) converting from one to the other makes no differenc whatsoever to render times vs. cleanliness, as seen above.