13
$\begingroup$

When I'm using rendered viewport it initially takes a while before rendering starts, but once it does, I can freely move around and rendering a new view happens almost instantaneously. When on the other hand I'm rendering a movie, for each frame Blender takes a significant amount of time before rendering even starts, usually doing the following:

Synchronizing object, Updating images, Updating meshes, Updating Scene BVH, Packing BVH,

Why does it do this? And is it possible to disable this to increase movie rendering speed?

Improve this question
$\endgroup$
1

3 Answers 3

Reset to default
11
$\begingroup$

It is possible to make the final render almost as fast as the viewport render, but you might not want to. The viewport render sacrifices a lot of features in order to make it update quickly. Firstly, it uses Direct Illumination only, which means that it basically only ever calculates 2 bounces. It also has a lot to do with whatever modifiers you're using. If you have a subsurf modifier that is set to 1 subdivisions for view and 4 subdivisions for render, then your final render has to deal with x^4 more polygons than the viewport does, which is obviously going to take longer.

There's also a little overhead in writing the frame to a file and then loading the next frame to start rendering, which the viewport doesn't have to do.

Lastly, the BVH acceleration structure (selected in the render settings) can make a critical difference in render speeds. IIRC, the viewport ONLY uses Dynamic BVH which spends a lot less time calculating the BVH (because things might move around), but each sample takes longer.

Details: There are two parts to the render: setup and sampling. The right setup can make sampling faster, but if you have to do some complicated setup for every frame, that might actually take longer than the time you save on sampling. The part of the setup that matters is the Acceleration Structure, called a Bounding Volume Hierarchy (BVH). This is basically a way of organizing things so that they're easy to find. You can either have a Static BVH or a Dynamic BVH. A Static BVH takes longer to build, but makes sampling more efficient. The Dynamic BVH doesn't take as long to build, but it doesn't make sampling quite as efficient as Static. The other important difference is that with a Static BVH, nothing can move*. If anything moves, it has to be totally rebuilt. Whereas with a Dynamic BVH, if something moves from one frame to the next, the BVH can be updated much more quickly than with a Static BVH.

IIRC, there are also some features that aren't rendered at all for the viewport. I want to say that SSS, AO, and caustics aren't (or weren't) calculated at all for the viewport render. But I'm not sure what they are.

*To be honest, I'm not quite sure what "nothing can move" means, I just get this from the tooltip. You'd do well to do some research or experimentation. It's possible that a Static BVH can be reused even if objects translate, so long as the mesh doesn't deform. It's also possible that any change of any object from one frame to the next requires a complete Static BVH rebuild. I'm not sure.

I hope that helps!

Improve this answer
$\endgroup$
4
  • $\begingroup$ SSS, AO and caustics are definitely calculated in the viewport. $\endgroup$
    – gandalf3
    Commented Mar 4, 2014 at 18:13
  • $\begingroup$ Thanks, that clears some things up. But is there anything I can do to speed it up? Because in one case I'm working on which is basically just a camera flying over a very a simple plane with a very detailed image texture, rendering only takes 30 sec, while building up the scene takes about as long. It seems to reload all my huge image textures for each frame and a lot of other stuff that probably isn't necessary. $\endgroup$
    – cybrbeast
    Commented Mar 6, 2014 at 7:33
  • $\begingroup$ I'm afraid I can't give you much advice without knowing exactly what's going on with your scene. In general, there are some things that always affect speed: # of polygons, # of objects, # of instanced objects, # of textures, size of textures. You might try experimenting with the texture cache settings in the preferences menu. The absolute best advice I can give, though, is pretty tedious: benchmark, benchmark, benchmark. Compare render times with and w/o any textures. Compare render times between the two BVH types. Compare render times with and w/o a ground plane. Rinse & repeat. $\endgroup$
    – Matt
    Commented Mar 7, 2014 at 19:47
  • $\begingroup$ Two things to look closely at, though, are "multiple-importance sample" and tile settings. The tooltip for multi-importance sample will be helpful, but you'll need to experiment. Also, tile sizes that are square, and are a power of two tend to be faster. I've noticed 128x128, 256x256, & 512x512 are most efficient. That being said, tile order (top to bottom, left to right, etc) can have an impact, if you're using multi-core rendering. E.g. your render might be waiting on one last tile that's just taking a long time, while all the others have already finished. $\endgroup$
    – Matt
    Commented Mar 7, 2014 at 19:48
8
$\begingroup$

BVH

As mentioned previously in Matt's answer, BVH revers to Bounding Volume Hierarchy.

The settings related to BVH building are as follows:

  • Static/Dynamic BVH:

    • Static BVH needs to be rebuilt after any object modification, however it provides faster render times

    • Dynamic BVH allows objects to be rebuilt individually, so that BVH rebuilding times will be much lower at the cost of longer render time.

    • Note: The final render always uses Static BVH, while the viewport render uses the settings in Properties > Render > Performance > Viewport.

  • Cache BVH: When enabled, Blender saves the BVH to the hard drive and re-uses it if no geometry had been modified. According to the wiki this will slow down the render if geometry is modified.

  • Use Spatial Splits: According to the tooltip, enabling this makes building slower and rendering faster. However, according to the wiki BVH building without spatial splits is optimized (multithreaded) and building with spatial splits is not (yet), so leaving this disabled might be faster overall for now.

Improve this answer
$\endgroup$
-2
$\begingroup$

I've had the same problem i searched it but got no clues and then i figured it out by myself here is what i was going through.

As the purpose of BVH is already mentioned above and i was making it slow by increasing the preview of multiresolution 6 x for sculpting and when i reduced it to 5x BVH started working fine .

Note: This totaly depends upon the system you are using those who have a good system with a good graphic card might not face this problem.

Hope this help.

Improve this answer
$\endgroup$
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .