V-Ray 3.5: Understanding Resumable Rendering

What is resumable rendering?

In short, resumable rendering is the ability to have incomplete renders resume where they left off. The rendering could have stopped because of some outside circumstance, such as a power failure, or have been stopped based on the needs of the user.

In the next 3.5 service pack of V-Ray, we will be introducing resumable rendering as a new feature. This will first come out in V-Ray for 3ds Max, and then released for the other platforms. To use it, simply turn on Resumable Rendering in the VFB settings in the render dialogue or pass the -resume=1 option to V-Ray Standalone. You will also have to set a time interval for incremental saves if you are using progressive rendering.

Please note that this feature is still under development and some of the functionality may change in the final release of the service pack.

Two type of resumable rendering in V-Ray:

As you know, V-Ray has different ways to render. For resumable rendering, the difference is mainly between bucket rendering and progressive rendering.

• Bucket rendering:
  With bucket rendering, the case is fairly simple. V-Ray writes the image as each bucket drops as part of a sidecar .vrimg file. When the rendering is resumed, V-Ray reads the partial .vrimg file and picks up on the next buckets that need to be rendered. The light cache is also stored in the .vrimg file so V-Ray doesn’t need to recompute it when resuming the render.
• Progressive rendering:
  In this case, you need to set a time interval in the Resumable Rendering settings which tells V-Ray how often to save the state of the rendered image so that it can be resumed from that point forward. V-Ray will save a sidecar .vrprog file that has all the information that V-Ray needs to resume the progressive rendering. In addition to the contents of the progressive buffer, the light cache is also stored in the file so that it doesn’t have to be recomputed when resuming. After stopping and resuming the rendering, V-Ray will read the .vrprog file and pick up the rendering process where it left off.

A few things to consider:

Since this process relies on either a sidecar .vrimg or .vrprog file to be saved, it will save that file in the directory where you are saving the final image. Both files can be large as they contain a lot of data. This is especially true for the .vrprog as it has all the needed data for the whole image, not just the completed buckets.

When a rendering is resumed, there is still some preparation that needs to be done before the rendering starts that has to be redone. This includes scene prep, and texture loading. The GI light cache is saved, but the irradiance map is not and would have to be recalculated.

Use cases:

• Rendering got stopped by outside forces: There are many reasons that an outside situation could have caused a rendering to stop. The computer could have had a power failure, or ran out of ram, or you could have been rendering on the Cloud such as Google Computer Engine which offers Preemptible VMs. In this last case, the VMs are significantly cheaper at 20% of the cost of standard VMs. The issue is that Preemptible machines can be recalled at very short notice. If this happens, a new VM can come back up and resume where the rendering left off.
• Choosing to stop a render: A user may choose to stop the rendering on purpose. This could be because the current rendering is taking too long and there is a rendering that of a higher priority that needs to be done right away. In that case, you can easily stop the rendering without losing any progress when you resume it.

Another case could be set up as part of the render farm policy that all renderings are stopped after certain amount of time to ensure that every shot gets rendered overnight. If you are using progressive rendering, a grainier version of the render will still be available to review and can be resumed if the rendering looks good enough to warrant the full quality.

• Incremental animation rendering: Depending on your render manager, a simple script could be set up so that the entire animation is rendered for example at 5 minutes a frame and then resumed to render for another 5 minutes until the rendering has reached the desired quality. This means that no matter what, you will have a version of the animation that can be seen in it’s entirely that will continue to incrementally get better as it stays on the farm with every pass.

Keep in mind that, based on the fact that your scene still needs to be loaded, and prepped for every instance of the resumed rendering, this in itself can take a bit of time. So it is recommended that you don’t do very short increments of your rendering such as 30 seconds.

Conclusion:

Resumable rendering is an important feature that could drastically change your workflow and choices you make while rendering. It could also greatly reduce the anxiety associated with long renders. We have only listed a few examples of uses cases for resumable rendering but are eager to hear of other ideas and examples of where this feature could change the way you work.

This article is published by permission of Chaos Group. you can find the riginal article on labs.chaosgroup.com.