No way to render Multi-Frame Incremental GI pass (VRay, Max)[solved]

Even with the job set to use one node on HIGH priority, each frame is rendered individually and the IR map does not build correctly. Possible work-around is to use Flythrough IR map calculation, however this can cause artifacting and take considerably longer to calculate than Multi-Frame Incremental.

The problem seems to be that the frames are not batched together, and when rendering each frame individually the Multi-Frame map is reset instead of incremented. If it helps to diagnose this, Backburner will correctly render Multi-Frame Incremental GI passes when the job is assigned to a single node at Critical priority.

Hi JoshH,

Like in this other conversation the key is to use the “Dependencies” feature with “Strict” setting. It means that you have to send out incremental precalculation to one specific node first. Please set te max Node limit to 1. In this way one Node will do the precalc first. The next job will start once this is finsh.
I have to mention that we are take in consideration to outomatize this IM LC precalc procces but we did not implemented this feature yet for a reason:
The whole “precalc IM LC” method has its own story. Basically it is a clever cheat and it was a great feature to be able to shorten the render time on weak hardware. But as every cheat it has its own problems: it is complicated and the quality of the render is far from perfect in some cases. So as time passed by, the hardwares got way faster and Chaos decided to spend effort to increase the render time on Bruteforce. It was important because Bruteforce is the far most reliable method in any circumstances, it is simple as a door wedge and it gives you the best render quality. So Chaos followed Occam’s razor and decided to continue the work with the simpler solution. Therefore in the last two-three years the “precalc IM LC” method is officially not recommended by Chaos.

We had the same learning curve at Brick. We used “precalc IM LC” but even if it was automated based on the several steps involved we always had issues with it and we burned a lot of time to experiment with the right calculation to get the best possible result. And approximately 5 years ago we realized that if we sum up the time that we are losing on the hassle, then actually LC BF has a pay off. So we swapped to use LC BF and it gives us excellent quality with simple control and far better render times compared with 10 years ago.

So right now LC BF is the officially recommended method for animation by Chaos and that is the reason why Pulze Render Manager does not have an inbuilt feature for “precalc IM LC”. We could have done it easily but we wanted to be on the same page as Chaos. So to conclude I kindly recommend you to have an experiment. If you have a spare night for testing send out the same sequence with the two methods and check the quality & render-time.

I have to mention that of course if you would like to use “precalc IM LC” in the future we gladly implement a similar feature into the Render Manager but I am afraid it will be less and less supported by V-Ray as the time goes.




I think you mis-understand the problem. I am able to run the GI pass first using Dependencies just fine, but when trying to calculate a Multi-Frame Incremental IR map specifically the Render Manager causes errors. Instead of accumulating data across multiple frames, it will only save the data from the current frame. This can be tested with a simple teapot scene and an orbitting camera - when trying to render the camera after calculating the Multi-Frame IR map, anything that is not visible on the last calculated frame will be missing.

To sum it up, the issue I’m trying to raise is not that there is no feature in Render Manager to automate GI precalc - although that would be a nice feature! The issue is that when manually submitting a Multi-Frame IR/LC Prepass to a single node, even though the node will calculate every frame it will not put the data together. I’m not sure how the Render Manager works under the hood but I suspect the issue is how it assigns frames to nodes.

I did not know that Chaos Group considered the IR / LC method to be deprecated, but I would caution against not supporting it. I agree that BF / LC is much improved over years past, and is the only real solution for scenes with animated geometry, but the IR / LC solution has a very strong place in Arch Viz animation. If we could afford to always render BF / LC we would, but on projects with tight deadlines the difference in speed can be critical. For our studio, at least, the IR prepass remains a big part of our workflow.


Thank you very much JoshH for the clarification!

We will examine the issue and get back to you as soon as possible.



You’re welcome, I hope that it helps!

Dear JosH,

We tested the issue and you are right. For an unknown reason the “multiframe incremental” option does not work properly. We will check how to fix this issue. As a workaround we tested the “incremental add to current map” option and it works perfectly. The only difference is that the Multiframe incremental mode will delete the map in memory at the start of the rendering. With the Incremental add mode, the current map is not deleted. So you can use the “incremental add to current map” without hesitation because the Node always starts a job with a cleaned memory anyways.

So the suggested way is to send out the precalc job first, don’t forget to limit the number of nodes to 1! In this way one Node will calculate the vrmap file. After that you can launch the final render sequence on all the Nodes.
Thank you again for your report. If you have any questions I’d be happy to help.