Why IrMap over Brute force for animation rendering?

[kosso_olli]

Scene was sent to support. Thanks!

[Vizioen]

@Lele

any idea how to speed this up? Settings in this are the defaults (Lightcache @ 1000 and retrace at 2.0, for testing purposes). Results are a 10 min render for a 720p (2x Xeon 2695V2 with 64GB RAM). But with LC, 3000 and 8.0 it will take a while longer. In total it's a sequence of 1500 frames at 24fps.





The ceiling (and later in the movie) is quite complex as you can see here; but what strikes me is that this doesn't pose that much problems. But rather the flat concrete surfaces as you can see from the samplerate pass.

This one frame is even 23 minutes.





I need this to be quite fast. As fast as possible. I tried changing the reflection depth of all glossy materials to 2 but that doesn't seem to change much.

I tried playing with adaptive lights and uniform probabalistic lights too. With adaptive lights I have to up the default of 16 because some lights seemed to disappear.

Thanks.

[iancamarillo]

The whole point is to forget to precalc a thing,

So no precalculating is needed BUT if you are doing a camera path ONLY animation, you could save time by ticking "use camera path" in LC and precalculating the camera?

[^Lele^]

[ATTACH=CONFIG]35786[/ATTACH]

This may signal an issue somewhere else, it looks indeed WAY too red for the RGB shown (a murky gray).
As for making it fast, well, lower retrace as much as you can get away with (that is the part of the set up which decides when an LC sample can be reused more, or if more tracing need to happen still) without creating issues. \
That means rendering short sequences with various settings, at different times, and verify them), so i personally wouldn't do it.
If that scene is deemed a 30 minutes per frame job to cleanliness (ie. that is what the settings take), lowering through "optimising" will only introduce issues (noise, splotches, whatever.), so one can take the 30mins, or spend that credit in more noise, more troubleshoot time, and more chances to do things ever so slightly wrong.
I set up and send to the farm EARLY knowing without looking it will work, and not bite me back after a weekend of rendering.

Now what you see there is either shading setup, a bug, lighting setup, whatever.
I wouldn't send a sequence of that shot to the farm just yet, until i got to the bottom of that huge amount of sampling effort for nearly invisible areas (if you have v-ray dirt, do yourself a favour and toss it away.).

So no precalculating is needed BUT if you are doing a camera path ONLY animation, you could save time by ticking "use camera path" in LC and precalculating the camera?

No.
Rather, sure, the options stay, but no, it's *not* what is suggested.
What is suggested is unequivocally ONE approach. Rain or shine, LC @ 3k, and retrace at 8 (to begin with. follow where the direction goes.).

[Vizioen]

This may signal an issue somewhere else, it looks indeed WAY too red for the RGB shown (a murky gray).
As for making it fast, well, lower retrace as much as you can get away with (that is the part of the set up which decides when an LC sample can be reused more, or if more tracing need to happen still) without creating issues. \
That means rendering short sequences with various settings, at different times, and verify them), so i personally wouldn't do it.
If that scene is deemed a 30 minutes per frame job to cleanliness (ie. that is what the settings take), lowering through "optimising" will only introduce issues (noise, splotches, whatever.), so one can take the 30mins, or spend that credit in more noise, more troubleshoot time, and more chances to do things ever so slightly wrong.
I set up and send to the farm EARLY knowing without looking it will work, and not bite me back after a weekend of rendering.

Now what you see there is either shading setup, a bug, lighting setup, whatever.
I wouldn't send a sequence of that shot to the farm just yet, until i got to the bottom of that huge amount of sampling effort for nearly invisible areas (if you have v-ray dirt, do yourself a favour and toss it away.).



No.
Rather, sure, the options stay, but no, it's *not* what is suggested.
What is suggested is unequivocally ONE approach. Rain or shine, LC @ 3k, and retrace at 8 (to begin with. follow where the direction goes.).

Turns out having 250+ lights didn't really work fine with this particular scene. I reduced them 20 times and reworked the floor from a geometry to a simple bitmap with some bump and it looked pretty much the same, except for the lighting which was kind of plain. I'm going to do some tests with lights to see which is fastest.

[^Lele^]

Oh, i see what it COULD be.
At the risk of running into (different) issues later, try the same exact frame, same exact settings as the one you posted above, but set Leak Prevention to 0.0 (down from 0.8. LC->expert mode dialog) and rerender.
If the SR re turns a nicer shade, we found the culprit.
I did get that odd behaviour very intermittently depending on the scene, when light counts were high, well over 10k, so maybe it applies here too for some reason.

Just as a test: if it's the case, we may want a scene to try out (or piece thereof, as long as it behaved the same, so we could try and track down what it is.).

[william.morris]

Lele! You legend! Thank You!! I have been looking for a thread like this for so long!! I will definitely be giving these settings a go! I have avoid rendering moving objects for so long as the precalc used to take ages. One setting which always confuses me for animations with moving objects.....'lock noise pattern' should this be on or off?

[coolhand78]

maybe this should be made a sticky or smth?

seems that for rendering animations people aren't aware of the new "rules"...

can also safely say that they work a treat, am doing a fair bit of animation work atm (architectural) and these settings have worked without issue...!

once again big thanks the Lele, for taking the time to set me right!

[Pixelcon]

As above. Starting an animation in two weeks (I've only ever done one before) and reading this is putting my nerves to rest considering I was supposed to be "the vray guy" handling all the supposedly hard stuff at work. Thankfully none of my colleagues are present on these forums so they'll never know it's become a whole lot simpler in recent times...

Thank you once again, Lele.

[JezUK]

Me too - I'm getting animations coming through my workflow these days and I'm actually looking forward to my next one !

Thanks Chaosgroup - and Lele, you're a star !

[Pixelab]

I'm puzzeled. I don't want to spit in the soup (like we say here) but I rendered multiple shrot flytroughs on a project (250 frames each). With camera path + flytrough mode. 1080p, frame time between 8 / 15 minutes on a bi Xeon E5 2630 v4. A lot of forest, tiny geometry. No moving lights nor objects (those were added separately) All was perfectly fine.

LC precalc (2000 samples, world units) was around 5 minutes on the first frame and I was done with it.

I really don't see the point of doing a new LC pass on each frame with single frame mode (and 3k sample seems overkill for me) this would double the times of my frames.... for what benefit?

Actually, denoising did a very effective job (single frame denoise, because multiframe was too long and involved cumbersome file manipulations)

Client was really happy so who gives a s*** about the tiny splotches here and there if you can cut your render time by half? As long as the architecture isn't worth it and you're not aiming at an Oscar like Vlado , I won't.

Though, I'm happy we got rid of the IM workflow which was prone to user error (and you do a lot of those after midnight)

[gadzooks]

Does this Technique apply regardless of rendering resolution. Would it be the same as a 640x480 image and a 1920x1440?

[coolhand78]

Does this Technique apply regardless of rendering resolution. Would it be the same as a 640x480 image and a 1920x1440?

i just rendered out an animation at 1920x1080 using this method and it worked a treat.

[pixelplume]

this new step forward is just fantastic. It's so much less to think about. I had a couple bad frames (one didn't render & the other bad geometry) and I fixed stuff and just hit the button and rendered it locally. This is amazing in the middle of crazy production mode late at night, tired and crazy. I did not have to think about pre-calculating, resending the render farm and all that crap. No blotches or anything. .......totally worth using the new method imho

[Pixelab]

I'm still puzzeled. What's the point of doing a LC calculation before each frame when 1 flytrough calculation yields good results ?

How much ime does it take to render the LC for each frame on your side ?