If I just start up my default startup file and render an animation, the previous frame is always replaced with a blank transparent checked pattern before the next frame starts rendering.

However, in this file the next frame is displayed as rendering over the previous frame.

I have also noticed that in the file linked above some tiles will briefly appear transparent (checkered) before rendering, however others do not.

Why is this?
Is there some setting I don't know about?

Is it possible I could render animations without anything appearing transparent?

  • $\begingroup$ I have encountered this problem using Cycles in 2.83 as well. $\endgroup$ – Eric Xue Jul 3 '20 at 14:07

Cycles cuts the final image into a number of tiles, as each tile begins to be processed it is cleared before the result gets entered into it. Blender internal doesn't appear to do this clearing step, leaving each tile update being drawn over the previous frame content.

For not seeing a tile in it's cleared state you will find the screen view gets updated in a thread separate from the rendering. A tile may get cleared and updated in between two screen updates so a tile that gets cleared may not be seen in a screen update before an image update is entered into it. The quicker the first sample is ready the more chance that the cleared tile is not updated to the screen. To test this set a large tile size and high samples rate using cpu so that it takes a while before an update is ready to view, even a simple background colour that updates quickly can be seen cleared before it gets updated.

As for the difference between your two example files, the startup.blend file has border turned on in the resolution settings with crop turned off. blue_ring.blend has both border and crop turned on.

It appears that border on with crop off causes full image clearing between each frame. Border off or border on and crop on doesn't perform this clear full image step.

Rendering within a border that doesn't get cropped would be a reason to clear the entire image to prevent any old image data being present around the cropped render. For an animation this step should only be needed for the first frame and should be able to be skipped after that. Probably no has thought of only running the clear step once at the start of the render animation task.

  • $\begingroup$ Then is this a bug? Should I report it? $\endgroup$ – gandalf3 Jan 14 '14 at 22:33
  • $\begingroup$ Not a bug, clearing the entire image for every frame could be considered an unnecessary step when rendering animations, so it could be removed as a small performance improvement. The real question would be whether the amount of coding to do that is worth the half second per frame that it saves (wouldn't even be 1% speedup). You could mention it to one of the cycles devs and see if they think it's easy to change. $\endgroup$ – sambler Jan 14 '14 at 23:23
  • $\begingroup$ Also wouldn't clearing be unnecessary if the border region covers the entire camera? And where would I mention something to a developer (besides the tracker)? $\endgroup$ – gandalf3 Jan 14 '14 at 23:36
  • $\begingroup$ It would be unnecessary but it only checks if the crop option is enabled, not whether the rectangle for the crop matches the camera size, it isn't important enough to do that much testing. #blendercoders on irc is the place to chat with developers more info here $\endgroup$ – sambler Jan 15 '14 at 0:08
  • $\begingroup$ I'm not sure it's not that important.. Think of all the times it will have to refresh in a 1000 frame animation. $\endgroup$ – gandalf3 Jan 15 '14 at 0:10

The Blender Internal rendering engine (which is what the default startup file is set to) behaves different than the Cycles rendering engine. This might account for the discrepancy in what you are seeing. Otherwise I am not aware of any other setting that might affect the rendering output.

This is what I see when I render the file you provided: enter image description here

  • $\begingroup$ Sorry.. I forgot to mention I have cycles as my default. I added a link to my startup file in the question. $\endgroup$ – gandalf3 Jan 13 '14 at 19:33

I believe it has to do with the "Persistent Images" option in the Performance section of the Render settings. According to the docs, "Persistent Images option to keep images loaded on the device, saved time initializing next rendering." Though that's not very helpful, it might explain some things.

  • $\begingroup$ I tested with this enabled and disabled on my startup file and it didn't change anything. This setting is also disabled in the other file I linked. $\endgroup$ – gandalf3 Jan 13 '14 at 19:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.