Why IrMap over Brute force for animation rendering?

[coolhand78]

Following VRay's guide to rendering animations why is it recommended to use IrMap over brute force for an animation in VRay 3.4?
is it significantly faster? or are there other factors at play?

[Rens]

Yes, it's faster, especially indoors. BF is more accurate but I find that usually IrMap works fine for what I need and the added speed is very welcome with 100s of frames. Very rarely would I need the IrMap detail enhancement or a dirt/AO pass. IrMap is quicker because it takes much less samples than BF and then blends them in a smart way to make it smooth yet keep as much detail as it can.
For stills you tend to look more at the details so BF would be a better option there. In outdoors scenes I usually find the speed difference too small to bother with the extra IrMap passes.

From your link:

This tutorial focuses on the irradiance map to gain some speed. If you can afford longer render times, using a simpler approach like Brute force GI for primary rays, and Light cache for secondary rays might prove less complicated and faster to set up.

[^Lele^]

Following VRay's guide to rendering animations why is it recommended to use IrMap over brute force for an animation in VRay 3.4?
is it significantly faster? or are there other factors at play?

That page is obsolete (1.5x times), and we planned for its removal a while back, but it clearly hasn't quite happened yet.
Please disregard it.
The chaos-suggested method *IS* BF/LC, with the two very small changes to be made to the LC settings as instructed by the tooltips when going from stills to animations.

No need to EVER use "follow camera path", incremental modes, or long sequence LC renders: it's one size fits all, and it's the best possible compromise of speed and quality V-Ray has to offer, bar none, whether you are trying to render a ball on a plane, or a scene with topology-changing geo, moving and appearing and disappearing lights, billions of triangles as grass and trees, or an architectural interior.
Don't use it at your own loss.

[pixelplume]

So on my last interior animation I switched to the new BF method and it seemed to work great but I didn't do an AB comparison in regards to render times and quality. I'm confused by Lele's "No need to EVER use "follow camera path", since I was used to the old method. So....I left the sampler the default 1/24 .01, set lightcache to flythrough, 3000 subdivs checked "use camera path" cooked that out, saved it and then sent it Rebus. Is that still "correct" in regards to the lightcache?

[^Lele^]

set lightcache to flythrough, 3000 subdivs checked "use camera path"

no, it's not unless you also changed the LC sample size TYPE to world scale, adjusted their size in world units, and sert the LC subdivs number to what you'd need for the whole sequence (say, for a 100 frames with 1000 subdivs each, you'd need 10000 subdivs. you see how the method won't be able to cover an arbitrarily long sequence with subdivs capped at 65000.).
Further, to avoid any surprise, you'd need to make sure you didn't get LC-coverage issues (Edit: as now your LC samples are world-oriented, and the number you set isn't in relation to the screen, but the scene, so coverage becomes a case of finding the right number of samples and their right size, and WILL change in quality based on scene contents on the given frame.) anywhere in the sequence, which may well mean rendering out a frame every N to double check, or better still find and render the frames you know will be less covered given your current settings.

Do instead as the tooltips suggest, and each frame is a self-contained calculation unit, freely distributable, and independent in its calculation from what preceded it and what followed it.
Nor there is need to change sample size type, or double check a long sequence for issues: set the file up, send that to your farm, each pc will give you back a self-sufficient frame, any problem not spilling over any other job (unlike, in fact, sequence long maps which tie all the sequence together under the one caching structure.).

edit #2:

Fly-through – Computes a light cache for an entire fly-through animation, assuming that the camera position/orientation is the only thing that changes. The movement of the camera in the active time segment only is taken in consideration. Note that it may be better to set Scale to World for fly-through animations. The light cache for the entire animated sequence is computed only at the first rendered frame and is reused without changes for subsequent frames.

[Vizioen]

I'm a little confused now. I have to render an animation flythrough and I want to send it to the farm. I read all the tooltips but I'm not sure which ones you are referring to. I want to render BF/LC. To what do I set LC?

-3000 subdivs?
-8.0 retrace?
-Use camera path off?

[pixelplume]

ok.....I read that twice and still have some dumb questions/clarifications....

the animations I typically produce for this client are:
- only 720p as it goes into a powerpoint presentation
- fly throughs of Revit Geometry that I import into max and clean up and add texture/lighting
- glass and/or background as a fast separate non GI pass
- some motion blur in aftereffects

https://vimeo.com/202095497 Password: tumi

Do instead as the tooltips suggest, and each frame is a self-contained calculation unit, freely distributable, and independent in its calculation from what preceded it and what followed it.

So don't even use flythrough mode? just hit render and let V-Ray cook out each individual frame? sorry for the confusion.

[coolhand78]

So if I'm reading this correctly basically we just set it up like a still but for X no. of frames?

So no need to pre-calculate LC or IM and save them out before rendering out all the frames...?

The tool tip for *Use camera path* for light cache still says that it "Stabilises the light cache with respect to camera movement... useful to avoid flickering in animations where the camera moves..."

So for my animation whereby the camera moves and we have moving objects should this option be selected and if so do we then need to set the SCALE to World and adjust the sample size? and on that note how does one determine
what the sample size should be? I usually just use 0.02 and we have our units set to mm.

Also, i'm assuming that we leave MODE set to single frame?

This document also suggests to use the USE CAMERA PATH setting to reduce flickering in animations...

I'm quite confused about what to do here, if this could be clarified in detail it would be a great help as I have a lot of animations to do at present and a best practice would be a great help.

It would be very useful if Chaos group could clarify this and issue a best practice for animations given that it has clearly changed significantly from what long time users might have done in the past...

[rikou]

I'm quite confused about what to do here, if this could be clarified in detail it would be a great help as I have a lot of animations to do at present and a best practice would be a great help.

It would be very useful if Chaos group could clarify this and issue a best practice for animations given that it has clearly changed significantly from what long time users might have done in the past...

+1
I am always uncomfortable when I have to make animations even if I read and read and read ... and read everything I could read on the subject !

[^Lele^]

Yes, yes, and yes.

Let me elaborate a bit more, as i sound, as per usual, trenchant and it's never my intention.
All of the interpolated modes (besides the LC, which is a fairly different kettle of fish.), including all and any which expect just the camera to move, are what was originally developed to solve one burning issue: lack of computational power.
It's not like BF GI wasn't present in early V-Ray, on the contrary, it's that it'd feel like one was running a scientific experiment of the grade of SETI@Home, when compared to the interpolated methods, which still made renders just go about as fast as BF does today, back then.

In the decade (and a bit. ugh.) that came next, Vlado and the crew put a lot of effort into refining the brute-force techniques and a number of ancillary sampling technologies (last of such a line, Adaptive Lights. But also the new sampler, better shaders sampling, the list is very very long...), and the motivation to do so was to make it as transparent and hassle-free to users -no matter the content of their scenes- from the word go (rather than follow a four page tutorial, for example.).
The reasons why IRMap isn't a very good choice in principle anymore, besides specific corner cases, have chiefly to do with the average scene complexity of today.
One evermotion exterior scene i just converted for our own benchmarking had 25000 geo nodes, a swathe of proxies, and geo detail MANY times smaller than a pixel across half the screen.
A shaggy carpet, some grass, some foliage, and bam, IRMap is bound to fail.


So, as of 3.3 in particular, along with the sampler we changed also the defaults, to reflect the optimal set of technologies V-Ray offers to get a job -any job, ideally- done with a minimum of fuss, to a specific (per pixel!) quality target, with the minimum amount of overall calculations involved.

So, the first of the yes: default settings -> raise LC subdivs, raise retrace threshold, render.
The second: yes, no need for any flythrough/camera follow, spheregizmo,comp-through-render-passes-sh*t-the-client-changed-the-potted-plant-on-frame-345 thing. Ever again.
The third: yes, we had a bit of a hiccup in communication, already at work on making it clearer.

It goes without saying that if you're rendering super simple, super even geometries and shaders, there is likely no beating an IRMap in those large, largely uneventful, areas.
But for anything else, there's ..., well, you get the gist. ^^

[coolhand78]

So would this be correct for an animation that has a moving camera and a moving object (car)?

[^Lele^]

That's correct.

It worked with all this sequence, in 2.X, with a very very similar approach (minus a couple of new, and life-saving techs we didn't have back then: retrace and leak prevention. So my per-frame subdivs had to be a bit higher still.), where the camera path failed badly due to the combination of sequences' lengths and geometric complexity per frame, but showed errors only at the end of the (1200+ frames long for some) sequence, with quite devastating results on the farm.

https://www.youtube.com/watch?v=ciST26Kx2z8

[coolhand78]

That's correct.

you are a good man Charlie Brown

thanks.

[pixelplume]

thanks for the clarification!

[rikou]

So would this be correct for an animation that has a moving camera and a moving object (car)?

[ATTACH=CONFIG]35695[/ATTACH]

even with the LC Scale to"screen"??