V-Ray Scene Optimisation Script

[^Lele^]

EDIT:
A word or two of warning:
DO NOT use the script, OR the methods outlined in the thread, UNLESS you are VERY comfortable with V-Ray's inner workings (ie. you're a VFX LnR TD used to tinkering with the shots to extreme levels.).
It is meant as a VERY AGGRESSIVE, VERY IN-DEPTH approach to V-Ray, and the gains are going to be VERY MARGINAL from the approach of raising the "min shading rate", and rendering away.
Further, it CAN and WILL produce both LOOK and RENDERTIME issues if used improperly.
The way Vlado has updated V-Ray for version 3.0 makes the script obsolete, and the method overly complex for very minor speed gains.
You are STRONGLY ENCOURAGED to follow HIS approach, NOT MINE.
I repeat: there is NO NEED to use the script to get speed gains: raise the "min shading rate" and you will be VERY fine , and also able to control all of V-Ray's from one comfortable place.
You have been warned, with plenty of caps and bold, underlined text. ^^

Well, i guess i may as well chime in on the V-Ray sampling techniques, given most of this stuff was discussed in the beta groups, and i did come up with a script to allow for precise(ish!) sampling calculation.
It still needs some work (mainly, allowing for parts of the optimisation process NOT to take place, if the user wishes so) but i do use it daily to make sure i get my renders fast and clean.

To use it, just unpack the two files into the same folder, and run "Vray3RenderPal_V1.50.ms"

To give you an idea, Grant Miller (i have no clue as to your nick in the forums, Grant, sorry :P) tested it with these results:

5 png's attached, rendered on dual Xeon 5650s w/ 24 gb of ram.

• 23:39 - rendered as sent
• 24:49 - 2 stop preset
• 40:09 - awsm preset
• 30:04 - universal: default vray, BF + LC, 1-64, 1.0 adaptive, .01 noise threshold
• 22:20 - universal w/ embree on (go embree!)
• 3:13:34 - universal w/ .001 noise threshold w/ embree on

Note: the first render was as clean (well, cleaner, actually) as universal with a threshold of 0.001, so it's 23:39 versus 3:13:34 we're comparing.

The key concept here, which i used throughout years of Film and Product design production, is to leverage the specialised rays, rather than relying on the camera ones to do the cleanup work.
In tandem with this, as low an adaptivity as can be had will speed up things even more, although the caveat here is that without adaptivity things can (and sometimes will) get quickly out of hand.

I would *NOT* recommend using this in production straight out of the box.
Rather, take old scenes and give the script a whirl, compare render times, read what the listener states it's done to your scene, and in case poke me back for changes should stuff fall apart for you (not that i had any shot behaving so, so far, but i am sure the wilderness will provide for more entertainment than my own, or the beta groups experience ever could.)
The various pre-made presets were tests, really. I'd recommend using the "StdGeo" and "FineGeo" ones for best results, and in case save yourself a couple more presets with the global subdivs multiplier halved, should you have scenes which tend to clean up quicker (ie. aim for 512 SPP on all effects).

Notes:
* you may want to set up your GI by hand as BF/LC for best results.
* no change happens to your scene while you choose presets and tweak parameters in the script. Only upon pressing the huge button at the bottom (say this quickly three times, i dare you.) will changes ensue.
* The script will save a temp VFB image, and the eventual region area, reload it and wipe it from your history after the changes, so to allow for direct comparison of results. Soon there should be (or maybe it's there already. i'll investigate) a way to delete the old VFB, but for now, you will need to do that by hand. If confused, simply close them all, and press "show the last VFB" in the render settings.
* The script turns on Embree, so if you know that doesn't work for you, feel free to either switch it off manually, or dig in the script and comment out its line.
* The name may be a tad unfortunate, i am told, as there's a commercial product that goes by a similar name. I may change it to RenderMate, much like the dreaded CoffeeMate the Brits in here will be familiar with.
* When in doubt, please ask!

[^Lele^]

The script has been updated to allow for selective changes (not suggested AT ALL in the first use of the script. good if you want to change only lighting/sampling or cameras without touching materials after you tweaked them.), its name has been changed to avoid clashing with the other application, and the StdGeo and FineGeo presets have been tweaked to match my latest findings in performance (namely, down to 768 SPP minimum, from 1024, and with GI/IBL sampled the same amount, instead of 4 times more than the shaders).

I am waiting for authorisation from the powers that be to see if i can post images from the closed beta group here, so to show its behaviour and key concepts.
If not, i'll rewrite it all.

p.s.: ctrl+rmc will clear the custom preset from a button (and your disk.)

[m_hinks]

Testing on a nice heavy scene as I type, been giving my jip all week!. Clearly a lot of work involved in the script, thanks for sharing. I'll see what results I get.

Just to be clear, the script is a set of presets based on tests by you and the beta group, it doesn't analyse the scene to work out the best settings?

Just a thought, but maybe it would help (as i'm a bit confused) if you just quickly listed the steps you go through with using the script on a new scene?

Mark

[AlexP]

Also just gave it a quick test, and IR map was much slower which I guess is down to the global subdivs multiplier.
Maybe an option to automatically change your Hsph subdivs to suit the global subdivs setting so it stays at whatever value you had it set as before? (maybe also LC, guess this is changed by the global setting as well)
Going to test a bit more, on another scene.

[MoonDoggie]

Testing now Lele, glad you're still doing some scripting. Will you be at Siggraph this year? If so, let's grab some more bourbon.

[RockinAkin]

Very Awesome! Thanks for sharing!

[^Lele^]

*VERY dense post warning.*

Yep, it is NOT meant to work with anything else than LC/BF, as the usage of the global subdivs multiplier will wreck havoc into the IRMap settings.
I'll look into that, but given we're talking integer, for subdivs, whereas the global subdiv multiplier actually multiplies the SAMPLES (ie, the square of the subdivs) finding an exact subdiv value for it may prove difficult.
The Lightcache, on average, when used in screen space, has a sweet spot that's EXACTLY equal to

sqrt(imageWidth*imageHeight)

, leading to one sample per pixel (ie. for a 1k x 1k image, 1000 subdivs), and there's hardly any benefit going higher than that (or so i have found over the years. G.I. Joe, Oblivion, all used exactly those settings.) EDIT: unless there is extremely fine, sub-pixel geometric detail, for which doubling or quadrupling the subdivisions will result in a better sample average and minimize the occurrence of light leaks and splotches, whereas going lower tends to have the primary engine do more work.

The script is wholly of my own development and ingenuity, hence it being quite shaky and rough around the edges.
Me having been one of the earliest and sterner requester of the "divide shading subdivs" option (i asked for it around 2008, to put it in perspective), when that became a reality, i had my window of opportunity to finish off this skeleton of code i used personally to figure out vray's behaviour.

The settings are the synthesis of a few years of research: before 3.0, to achieve similar results, i used to use adaptive Subdivision AA so to make sure *I* was the one choosing how much a pixel was sampled before AA kicked in, rather than relying on the adaptation routines and camera rays to do the heavy lifting.

For materials, it limits the number of glossy bounces (while setting the non-glossy ones higher, by defaut), to avoid ray explosion when adaptivity is low or none.
To do some simple math, a 64 subdivs, 5 bounces glossy reflection would trace, without adaptivity, a quintillion rays per pixel, on the fifth bounce.
I know this, because i have seen it done.

lights and GI/IBL subdivisions are of course arbitrary, but unless you're hitting extreme cases (tiny, far away light source, and extremely long shadows), the presets ought to resolve your shadows very cleanly, with only a minimum of overtracing (thanks to the leftover adaptivity).

the true "tricks" are around the global sampler and the AA modes.

You'll notice i express the noise threshold in BITS, not a float value directly.
It means that when set to 8 bits, the threshold will be 1/256, when set to 10, 1/1024, and so on.
This is because one bit is equal to one Stop of brightness (ie. it expresses twice the brightness), and if you set the threshold to ten bits, you'll be able to stop the image up twice (ie. brighten it by 4 times) after the render is done, without any visible noise, as vray will have sampled well over what you are able to view on your 8bit display device.

Adaptivity is another part that is able to shave huge rendertimes, as inherently tracing without going through the adaptation routines and threshold check will reduce the amount of time it takes to trace the given ray.
Too low, and you may end up with ray explosion in some cases. Too high, and invariably the AA sampler will end up doing more of the work (which is, and i'll show this later, much slower than letting the AA just do the Geo AAsing).
A value of 0.5 is generally good, but the whole point of the script and its infobox is to let you, the user, choose what vray will trace "blindly", a-la Arnold, and what it will keep in reserve should the effect be noisy after the first non-adaptive rays have been traced.
Change the spinner, and watch the infobox, and you'll see what i mean.

The global subdivs Multiplier is in reality slightly wrongly worded, as it doesn't actually change subdivs, but samples.
So, if you have a shader with 8 subdivs, and a GSM of 2.0, you are NOT tracing (8*2)^2 samples, but (8^2)*2, or in straight numbers, not 256 Samples Per Pixel, but 128.
Again, play with it while staring at the infobox, and it will become very clear very quickly.
I use it to EXACTLY nail my non-adaptive and adaptive sample amounts.

Decoupling the AA threshold from the sampling one, and setting it higher (normally, to 1/256, or what's needed to correctly sample the 8-bit alpha channel edges), means the AA will hardly ever kick in to fix your glossies. Which is desirable.

Any other shader and light cutoff is set to exactly the global noise Threshold, so to insure no stray black pixel kicks in when the user doesn't want to.

Another thing which is slower than doing without is stepping up and down AA levels.
For this reason, a (to alle ffects) fixed of 4 tends to be faster than a 2-4 for the same level of AA (ie. 4 subdivs, or 16 camera rays per pixel.).
Hence the presets for stdGeo and fineGeo being to all intent and purpose fixed AA.

As for the Camera rays doing the work, this is a test i did (and with authorisation i may even post the test scene) to quantify the speed decrease of using more camera rays:

a 1Mpx, 4-4 with 1.043 Billion rays cast, renders in 107 seconds.
a 1Mpx, 16-16 with 1.329 Billion rays cast, renders in 299 seconds.

shadow rays and reflection rays are identical in the two images.
adaptivity is 0, cutoffs and dmc thresholds set to 1/1024

there is the only difference of 256mil cam rays. making all that impact.
notice the proportion is maintained across the screen sizes (100x100 has the same tradeoff as 1000x1000)

What this means is that you should try and achieve your results with the least camera rays that give you a clean GEOMETRIC/TEXTURE result.
In other words, first set the AA rays for your DoFed/MoBlurred scene so the alpha channel, and any fine detail texture is well resolved, and then clean noise using specialised rays, rather than simply going the universal settings route to clean the render up.

I know, it's quite dense.
Then again, i did warn you. ^^

Vlado's very busy currently, so the images may take a bit to get posted, but i don't think he'll object .

Keep hitting me with questions should you need any clarification!

[^Lele^]

Colin, only in Spirit, i am afraid.
I wish i had a teleportation device, right now...

Go hit the Alibi Room, and tell the guys behind the bar that Lele says hi, if you can.
they may throw you out right away, so bring a phone to film it all! :P

[Jason Stewart]

Wow, I will have to play with this a bit and see what it can do. The explanation may have went over my head but hopefully after I install it maybe it will make some more sense what you are saying.

[MoonDoggie]

Colin, only in Spirit, i am afraid.
I wish i had a teleportation device, right now...

Go hit the Alibi Room, and tell the guys behind the bar that Lele says hi, if you can.
they may throw you out right away, so bring a phone to film it all! :P

Will do, will video it. Wish you could be there this year. Keep up the good work.

[Pixelcon]

The script didn't automatically set the GI methods correctly (to LC/BF) and didnt set the LC subdivs to your equation above (not sure whether you've not implemented this or it's a bug).

I just re-rendered a scene using IBL + 117 lights.

'New universal method' (Global subdivs: 0, min shading rate: 16) : 75 mins.
RenderMate (embree on) : 35 minutes.

results are quite clean even with the difficult scene I have presented it. Only the most 'glossy' of materials have suffered persistent noise and differing appearance. On a side note, some settings may still be present from the previous render settings I had. Should the script be used on default vray 3 settings?


Very eager to try this out on a scene I just rendered at work which took all night (16 hours) using the 'new universal method'. 100's of lights, light materials, lots of glossy effects, large detailed proxies etc rendered at 5000px wide...

[^Lele^]

Yeah, i didn't have it set the GI, initially, as i didn't want to force people in that area, but then again, i might as well.
It's trivial, i'll hit it on the head tomorrow.

Don't worry about the noisy glossies: i am not performing clever math to get different shading scenarios clean before the render starts, so feel free to raise the sampling for the problematic materials (slightly! they are multiplied by the AA subdivs, remember. Use the script as a calculator without applying changes to see where you'd want them as far as subdivs go), and definitely return the bounces back to where you need them so that the look is preserved.
3 is quite good for very glossy materials, but it may not work well at all in low-gloss, multiple-bounce scenarios.

The whole idea of going this far out with the script, rather than relying on the render panel spinners alone is to one-click get you in the ballpark of cleanliness, while leaving you totally free to tweak what you need.

As far as stray render settings go, it may well be the case: the script collects your previous ones (including overrides, maps, saved GI/caustic files, and such), and then switches to scanline and back to vray, applies the key settings i want, and reapplies whatever stuff you had which wouldn't make a difference to performance.

Feel free to let me know if it behaves in a way you don't think it's right for this or the other parameter, and i'll try and change its behaviour.

[cheerioboy]

Hey Lele,

Neat script! Is it suppose to reset the color mapping? I picked the Awesome preset and the rendering came out brighter than the original (Reinhard burn value had reset to 1.0). That's all I got right now, need to play with this a bit more..

[^Lele^]

Yes it will reset the color mapping to Linear (or the default Reinhard which with burn 1.0 is linear.).
The debate isn't something i want to rekindle, but there is no gain to be had sampling other than Linear, in modern CG (ie. where post will come in after the render), and i am on record being not happy at all when the default was changed from Linear to Reinhard.
I have absolutely NO experience as to what the sampler would do when tweaked with anything but Linear, so i can't guarantee you that it'll work as intended.
But feel free to set it back to what you wanted, and give the render a whirl.
I don't think it'll change much in terms of speed gains, unless the settings are extreme.

Also, Awsm is very very likely overkill for ANY shot.
I'd try first the "Clean" and "2Stops", but the best results for a given cleanliness are to be had with the StdGeo one.

[Pixelcon]

I think it's great to see such savings over the savings I was already seeing with the 'new universal method'. Unfortunately in my position at work I literally have zero time to do any sort of optimization and test renders are a rarity. This is why using a universal method of sorts works for me. As long as the render is clean and takes less than 16 hours at 5000px then I'm happy (shamefully long, I know). I'm going to try out some of my recent scenes from work out with the script just to see how it holds up so I maybe can learn to anticipate what further tweaking might need to be done beyond what the script does, to get a clean render.

Really cool stuff. I love reading all the technical stuff and seeing settings so different from 'the norm' is really intriguing! Well done indeed!

Yeah, i didn't have it set the GI, initially, as i didn't want to force people in that area, but then again, i might as well.
It's trivial, i'll hit it on the head tomorrow.

Don't worry about the noisy glossies: i am not performing clever math to get different shading scenarios clean before the render starts, so feel free to raise the sampling for the problematic materials (slightly! they are multiplied by the AA subdivs, remember. Use the script as a calculator without applying changes to see where you'd want them as far as subdivs go), and definitely return the bounces back to where you need them so that the look is preserved.
3 is quite good for very glossy materials, but it may not work well at all in low-gloss, multiple-bounce scenarios.

The whole idea of going this far out with the script, rather than relying on the render panel spinners alone is to one-click get you in the ballpark of cleanliness, while leaving you totally free to tweak what you need.

As far as stray render settings go, it may well be the case: the script collects your previous ones (including overrides, maps, saved GI/caustic files, and such), and then switches to scanline and back to vray, applies the key settings i want, and reapplies whatever stuff you had which wouldn't make a difference to performance.

Feel free to let me know if it behaves in a way you don't think it's right for this or the other parameter, and i'll try and change its behaviour.