"Display the image in Stereo 3d" may increase render time drastically
Closed, ResolvedPublic


System Information
Windows 10 Home (10.0.14393)
GeForce 980 GTX (376.53)
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, 3601 MHz, Rdzenie: 4, Procesory logiczne: 8

Blender Version

Short description of error
While "Display the image in Stereo 3d" is enable during rendering it can affect render time a lot.
It can be bearly visible with small render resolutions, but larger resolutions causes that render time can be few times longer.
On my PC it noticable occurs for resolution larger than 2048*2048

For instance, simple scene with "Suzanne" (attached) while "Display the image in Stereo 3d" is:

  • ON - takes 103 sec.
  • OFF - takes 40 sec.

Render results are identical.
Notice that this is a very simple scene, while scene is complicated (more materials, textures) differencers are much more noticible.

Exact steps for others to reproduce the error

  1. Launch Blender and set render resolution at least 2048x2048
  2. In "Render Layer" tab select Views checkbox
  3. Render the scene
  4. Remember render time
  5. Deselect "Display the image in Stereo 3d" in render view
  6. Compare new render time to the one from 4.



Is this a bug or simply the fact that "Display image in Stereo 3d" is computationally expensive?

I don't have knowledge to give you proper answer. All I know is that when this options is active render time is much longer, but result is exectly the same.
In my opinion it would be good practice to switch this option off during rendering process.

Sergey Sharybin (sergey) triaged this task as Normal priority.May 29 2017, 4:05 PM

Stereo 3d will surely require some extra processing on the image, so technically it's not a bug but some possible optimizaiton.

@Dalai Felinto (dfelinto), one possible trick to do is similar to what we do for scopes: skip updates during rendering. So what you can do, is to ignore show_stereo3d during rendering.

Dalai Felinto (dfelinto) closed this task as Resolved.May 29 2017, 4:53 PM

This is a limitation of the original implementation. This was refactored for 2.8, and it has the same render time in both cases. So closing this for now. Thanks for the report.