VFB saving out broken frames

[SonyBoy]

Since this didn't get a response in the general forum, I'm reposting here! I've noticed an extremely problematic behavior with the VFB that I'm certain was not previously there. When rendering out an animation into the VFB -- which is often my preferred batch method so I can monitor progress visually -- previously I'm pretty sure hitting Esc would simply kill the current frame and nothing would be written to disk. However, I've now noticed that this is no longer the case, and unfinished frames are fully written out. This results in what appears to be a finished frame being written into the sequence, with full file size and date stamp, but in fact what is written out is a frame containing the previous frame's pixels in the unrendered areas of the current frame, with only those buckets that have completed from the current frame. Effectively, these are broken frames containing pixels from two adjacent frame numbers. Often this is not obvious to the naked eye, depending on the animation, and I've already had to circle back a couple of times to fix renders that I thought were finished only to find such frames later. Is this by design or this is a bug? It seems to me that if a user hits "Esc" while a render into the VFB is in progress, it means they do not want anything from the current render written out in this way.

[hermit.crab]

Thanks for the report. Saving the canceled/stopped frames has been the behavior in V-Ray for Maya when saving multi-channel .exr and .vrimg files for quite some time.
We may consider changing it in future V-Ray for Maya releases, however, if implemented, it won't affect the saving of images when resumable rendering is active (since the data needs to be saved from the start). Does this make sense?

[SonyBoy]

Hi Aleksandar thanks for the reply. Well, if what you say is correct I'm REALLY surprised I haven't noticed or had problems caused by this issue before. I am talking specifically about when using the VFB to render out frame sequences. Previously I would have bet money that killing the current frame would NOT result in a numbered frame being dropped into the output folder, which is what now occurs. If the output frame is visibly obviously not completed, this is likely to get noticed quite quickly and the frame can be requeued for render. However, the situation I had recently involved very long per-frame render times, creating the need to repeatedly interrupt the overall render of the sequence. This resulted in many incomplete frames being dropped into my frame sequence containing pixels from two different frame numbers. Since I was using Brute Force for both primary and secondary GI (meaning no visible presample passes), it was not at all obvious this was happening until I started to notice some very odd frames in my "completed" sequence. As I pointed out in my OP, I can't think of any scenario where a user is going to want a frame they are killing to be saved out into the animation sequence in the way that the VFB currently does it.

[hermit.crab]

Thanks for the feedback, I'll forward your request to remove this behavior towards our developers. For now, you may check the 'Clear frame buffers' option (Common>Render View), which clears the VFB before each frame, so that you may notice these frames more easily, should they occur.

[SonyBoy]

Ah, yes that would definitely do it and I wasn't aware of this option -- maybe I've always had this checked on in the past which is why I've not encountered the problem before. Thanks!