GI Settings - animation - advice needed please.

[busseynova]

Apologies for my ignorance on this, I'm looking for some advice on best practice on GI set-up when animating a scene (3DSmax 2019 / Vray 3.6); it is around 1900 frames, and is currently set up as one continuous camera movement for convenience in setting up, although I do have the original cameras as individual ones all running from frame 0.If possible I'd like to keep it as the former. The camera runs through 7 different interior and exterior spaces, the scenes are distinct although a few have spaces in common. There is virtually no moving geometry other than one door, which is fairly small in-shot, but the sun does move to 3 different positions between the different scenes. I will comp in animated 3D people afterwards but these will just be rendered as an alpha channel in a separate scene.

My question is what is the best GI set up for this - Walkthrough?

I understand if 'use camera path' is probably not a good idea as the camera covers too much ground. Should I pre-compute light cache for all 7 scenes, or will the moving sun cause issues?

I was planning to use BF/LC, is this an outdated method? I need fairly short render times, but am planning on using the denoiser to clean things up a bit after. currently using 0.25 noise threshold I'm getting 10-20mins on bucket rendering.

I will be using a render farm for these, who are, apparently ok with pre-computed LC, but they have to be bucket rendered.

Thanks in advance for your help, I'll be screwing if I don't get decent results on this!

Cheers,
Tom.

[^Lele^]

From Default V-Ray settings, change LC subdivs to 3000, retrace to 8.0.
*Nothing* else.
Each frame will be its own self-contained unit, and there will be no risk of having to recalculate a (long) LC sequence to be able to cater for changes in a small section of the animation.
This is the method we officially suggest (it's in the tooltips, after all.).
Use the renderer Noise Threshold and max AA to control rendertimes (as you well said.).

[busseynova]

Thanks a lot for the reply.

So there's no longer risk of GI flicker recalculating for each frame?

Would this be likely to be a big uplift in render time over fly-though mode if I were to ditch the sliding door? I appreciate that's probably an impossible question to answer accurately without knowing more though.

[^Lele^]

The higher LC subdivision (some ~10 times the default ones, per frame), Leak prevention and the higher retrace will take care of the flickering in the vast majority of cases.
Feel free to raise both the subdivs and the retrace value a bit more should you find the scene to be difficult (ie. fast moving, tiny detail, and so on.).

The fly-through/camera path option worked well only under specific circumstances, and had a tendency for grievous breakdowns when it exceeded its scope (say, too long a path/too few samples overall.).
It also had the bad side effect of needing to be fully recalculated if even just one frame changed in the whole sequence, or if one frame had an error of any kind with it.
So, overall, there are definite time savings across a production, even if comparing a successful path-driven LC and a per-frame LC seems to suggest differently.

Further to this, the LC compute time is a minuscule fraction of a properly shaded frame, to any decent noise threshold (f.e., 0.01), and will contribute to speeding up the final rendering by virtue of enabling the adaptive lights and adaptive dome techs (which won't work with path-driven approaches).