please help me understand render times in cycles...

OK, below are two images from the same scene. The ONLY thing that is different between the two images is the placement of the camera. And yet…, the close-up takes over twice as long to render. It is 59 seconds versus 2 minutes 7 seconds.

Why?!?!?!

I’m having a problem where I’m trying to use this scene in an animation, but when it gets to the part where the camera swings to the close up, I get stuttering in the playback of the video. I noticed that these frames are taking twice as long to render as the zoomed out shots. Any thoughts about why?



Because of the difference in the cameras, the rays that Cycles has to trace will be taking different paths, and this could easily change how long it takes to render to the same amount of samples.

Stuttering in the video seems like an issue unrelated to the rendering? I presume you render frames (to .png) then stich them in Blender VSE or another software of your choice?

Unless you meant there is excessive noise in the close ups? 2 min/frame isn’t really that long either.

Yeah, I have another thread in the compositing/post processing forum about the stuttering issue. I thought maybe the difference in render time was somehow contributing to the stuttering.

But yes, I’m rendering out to .png and I’ve tried VSE, premiere pro, after effects, everything I can think of and still get stuttering video. I’ve matched framerates and tried frame blending and everything else people have suggested. The only thing that seemed to work was rendering out PNGs at 30 fps instead of 24 to give me some more frames during the camera movement.

The weird thing is that the part of the video with the frames that only take 1 minute to render is perfectly smooth. But when it gets to the part where the camera pans to the close up and the render time increases, that is the part of the video that stutters. Since I’m rendering out to PNGs, I can’t think of any possible reason for that. The only thing I can think of is that I’m moving the camera too fast for 24 fps. dunno…

The excess noise is just because I only did 100 cycles for the two images above. It takes about 1,000 cycles to clear up completely.

I have used cycles very little, but my guess is that it is taking longer in the second image because (assuming you have reflections in that table’s wood and the ceramic) from what I remember a lot of reflections slow down cycles (and I guess most other renders) and the second frame seems to be catching only reflective surfaces, as opposed to the first one where most of the frame is background with “flat” materials.

About the video stuttering, I don’t get what is stuttering. is it the video file itself? Have you tried opening the rendered png files manually? Are there any missing or dropped frames? Are the stuttering frames rendered incorrectly, as in to similar image files with the same frame?

In Case you haven’t done it yet, try maybe another codec h264 with variable bitrates
How big is your video file?

I’ve tried every codec I can think of. All ends up the same.

It’s only 250 frames long. Not much at all.

My guess is similar to dphantom. The closer your camera is to any surface, the longer it will take because the closeup is gathering more details of reflections soft shadow areas and surface detail. Farther away there is less work because the reflction and shadow areas are much smaller in relation to the camera. I think this is true for most renderers.

Don’t know about the stuttering though.

In the first picture you have an open door, which I assume goes out to infinity in the form of a background image. These rays can be thrown away pretty much instantly and take pretty much 0 time to calculate. Your background also appears to be mostly diffuse surfaces, which are easy to calculate as long as no more than 80% of light is reflected. The second shot is mostly glossy surfaces, which take a long time to resolve. Try turning of blur glossy and make sure caustics are turned off. No matter what you do, though, the shot where more rays are hitting objects and glossy materials are involved is going to take more time.

Thanks again for the advice. The light from the doorway is actually a light place directly in the door with backfacing on. So the light is only emitted into the room.

I think the stuttering will largely be solved now that motion blur is available. As for the render times, it makes sense it takes longer to render a closeup image.