Page MenuHome

Viewport playback is fast, but rendering viewport to frames is slow
Closed, ResolvedPublic

Description

System specs
Operating system: Win 10 64bit
Graphics card: 2x GTX 1080ti

Version
Broken: 2.8 - 2019-01-25 00:40
Worked: 2.79b

Short description:
Viewport playback is fast, but rendering an OpenGL playblast or Eevee of that viewport is much, much slower.

Exact steps for others to reproduce the error

  1. Open any .blend, or this attached:
  2. Hit spacebar to play the animation
  3. You should see it plays at 30FPS
  4. Then in 3d viewport, click View>Viewport Render Animation
  5. It will now render the viewport, but at a much slower rate of around 1FPS.

I and other users on twitter have also experienced this while rendering Eevee animations, despite the viewport and render samples being the same. This makes the bug pretty severe as fast animation rendering is almost the sole reason to use Eevee.

PS. I've tried switching the renderer to workbench and doing a direct animation render, but that didn't seem to make much of a difference.

Details

Differential Revisions
D4773: Workbench,EEVEE: Viewport Render Samples
Type
Bug

Event Timeline

It looks like color management slows down the rendering significantly. (~0.5s per frame)
More specifically, this time is spend in IMB_partial_display_buffer_update.

Changing the view transform from Filmic to e.g. Raw results in a noticeable speedup for me.

There's a big difference between times reported and actual times. It renders slower than it says. For example, after the first frame, not counting build time since im rendering a cube, the time reported goes down, but it it's actually the same. Regardless, these are the times on my machine when rendering, but I think they are slower

-The fastest i've made a 4K DCI res render is at 0.11 seconds per frame, using the video sequencer to render a jpeg to jpeg sequence, srgb to srgb. If I use another color management as output it becomes a little bit slower, 0.3 seconds.
-If I use an EXR as input and output in the Sequence editor, the time increases to 0.4 or 0.7 seconds, unless i change the color management of the output to raw, in which case it goes to 0.3 seconds. Using jpg as input but exr as output is 0.1 seconds
-An actual render from eevee, the default cube scene with 1 sample, at the same 4k dci resolution, is about 1 second with filmic, and 0.5 with raw color, regardles of output format. While my viewport in my 4k monitor is realtime and close to 60fps

My takeaway is that the writing is barely an issue, 0.1 seconds per frame at this resolution, regardless of format. But the input, 8bitjpeg vs Full uncompressed EXR/direct render, and the color management, are the slowest parts. The viewport seems to have some kind of real time color management that performs faster

Ideally, there should be unnecesary redundant color management under the hood, like right after rendering but not saving and use the real time color management instead, or when saving to EXR. And for the color management for saved files to be as fast as the one in the viewport. Can that be achieved?

OCIO has two paths:

  1. GPU
  2. CPU

When rendering, the optimal quality is only possible via the CPU path, hence why during offline rendering it needs to be CPU. Online can be GPU.

Not sure it would account for the slowdown being documented here, but it may be a contributing factor. If it is, a "Lower Quality" checkbox could provide an option perhaps, although I strongly suspect there are broken code paths gobbling up many more cycles than OCIO.

But even if the factors colormanagement and writing were 0, it would still be slower than normal playblack in the viewport.

Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.

I'll mark this as confirmed as Jacques already reproduced this.

Brecht Van Lommel (brecht) raised the priority of this task from Confirmed, Medium to Confirmed, High.Apr 1 2019, 2:07 PM

So - will this be tackled in June before the launch of 2.80? I don't want to annoy anyone, but IMO this is the most severe issue rn. Exporting Eevee animations is about 300 times slower than the viewport (60 fps v 6 seconds per frame) with - for me - no observable quality difference. It's a dealbreaker for me and keeps me from using it. I think lots of people will come to 2.8 because of EEVEE and IMO this could lead to lots of bad first impressions.
So, yeah, please consider fixing this before the release of 2.80, even if it's no crash / bug.

High priority means it's planned to be fixed before the 2.80 release.

Got the same issue, failed to get viewport animation in less that 5 secs per frame at any mode, while rendering took 14 sec per frame.

https://www.youtube.com/watch?v=Xdwvl9JFr2M

Here is test file, around 4 sec to render, almost same time for viewport render.
https://www.dropbox.com/s/0ftuo9pd282fyq6/BQ-ER_60F_2019_PART.zip?dl=0

Viewport animation playback:

  • Will only render a single sample. Only when animation is stopped the rest of the samples are calculated (TAA) upto the num of viewport samples.

Viewport Animation Rendering:

  • Will use FSAA and merges the samples on the CPU ED_view3d_draw_offscreen_imbuf. The settings for FSAA can be changed by going to the Film settings of the workbench and disable AA there. When doing the EEVEE render will not render any AA. When doing so it is fast. By default renders 8 frames without limited caching of buffers and heavy CPU<GPU transport.
  • Writes result to disk

Final Rendering

  • Renders a single frame and every render engine decides how the AA is done. For EEVEE it will do the render loop taa_render_sampels time. (default 64). This loop is optimized and reuses geometry buffers from previous samples.
  • Writes result to disk

Conclusion of the discussion so far on blender.chat was to

  • remove FSAA (scene->r.mode & R_OSA)
  • implement a TAA loop for workbench image rendering (similar to EEVEE) make sure both will work. Note check workbench_render code is (partly) there.
  • Add setting to workbench for the number of render samples. (enum with 1, 5, 8, 11, 16, 32 as these are only supported by workbench engine workbench_taa_calculate_num_iterations)

Disabling AA gives a significant boost to rendering speed.
Unfortunately the boosted result isn't as fast as the viewport itself.

It sounds to me that the plan is to "essentially" just switch the Anti-Aliasing options.
I don't know how much that will affect anything, so I have a question about speed:


Will only render a single sample. Only when animation is stopped the rest of the samples are calculated (TAA) upto the num of viewport samples.

You specified this, only for viewport playback.
Is there / Will there be a way to get render playback nearly as fast a viewport?

Like skipping this this part, and adding the "Writes result to disk" part.

So that the only speed difference between viewport playback (frame_skipping disabled), and viewport render,
is the time it takes to write the file to disk and displaying the image in Blender.

@Ovionis (Phigon) There will always be some differences in performance and functionality between rendering in the 3d viewport and using the Viewport Render options (eg color management, Download result and store in Image Editor.

We are currently looking in what can be done in short term keeping in mind the render quality and without introducing new features.
Later we can always add new features to improve blender, but that is a different story.

Viewport rendering is best done as low quality as possible.
If people renders Viewport, they are consigned to the quality of the viewport level.

Yeah, I just don't want to have to screenrecord a real time playback in the viewport anymore 👌

Jeroen Bakker (jbakker) closed this task as Resolved.May 7 2019, 9:30 AM

One question:
Is there a real solution for the slow View->Viewport Render Animation function?

In the current master (Aug. 01, 2019) it's still much slower than the realtime playback in the viewport.
I've a playback rate around 5 f/s and would expect to render the viewport with the same speed. But when I use "Viewport Render Animation" the render speed "feels" like around 0.5 f/s.

Any idea how to render Viewport Animation Previews with the same speed like the viewport playback speed?
As I remember in Blender 2.7x Viewport Animation Rendering was much faster, even when using AA in the viewport.

Any suggestions how to render the Viewport Animations faster in Blender 2.8?

I hope I didn't misunderstand something in the thread before.

Thank you
Chris

No, you didn't.
There were such a problem.
Also, could it be because of long images saving?

No, you didn't.
There were such a problem.
Also, could it be because of long images saving?

The same project is twice as fast in Blender 2.79. There I use viewport AA with 8 samples.
The viewport animation speed is twice as fast and OpenGL Animation Rendering renders twice as fast, too in 2.79.

In what shading mode?
There were problem, that final eevee renderind frame took 14 sec, while OGL animation - never less than 5.

It is in solid mode in Blender 2.8.
Solid and Look Dev are same speed here.

The same project has around 10 f/s animation speed in 2.79, and 5 f/s in Blender 2.8 when I use wireframe mode e.g.