Viewport playback is fast, but rendering viewport to frames is slow #60847

New Issue

Andrew Price · 2019-01-25T07:38:40+01:00

Andrew Price commented

2019-01-25 07:38:40 +01:00

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

Open any .blend, or this attached: dumb_cube_anim.blend
Hit spacebar to play the animation
You should see it plays at 30FPS
Then in 3d viewport, click View>Viewport Render Animation
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.

**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: [dumb_cube_anim.blend](https://archive.blender.org/developer/F6397269/dumb_cube_anim.blend) 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 ](https://twitter.com/andrewpprice/status/1085401702092734465) 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.

Andrew Price commented

2019-01-25 07:38:40 +01:00

Added subscriber: @AndrewPrice

Bent Hillerkus commented

2019-01-25 08:39:00 +01:00

Added subscriber: @bent

Olivier Amrein commented

2019-01-25 08:44:59 +01:00

Added subscriber: @oenvoyage

Jacques Lucke commented

2019-01-25 11:52:18 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2019-01-25 11:52:18 +01:00

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.

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.

Fabio Rodrigo Raitz commented

2019-01-25 14:04:55 +01:00

Added subscriber: @raitz-4

Ovionis commented

2019-01-27 00:21:05 +01:00

Added subscriber: @Phigon

msalv commented

2019-01-27 14:23:43 +01:00

Added subscriber: @moisessalvador

msalv commented

2019-01-27 14:23:43 +01:00

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?

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?

Troy Sobotka commented

2019-01-27 20:43:42 +01:00

Added subscriber: @troy_s

Troy Sobotka commented

2019-01-27 20:43:42 +01:00

OCIO has two paths:

GPU
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.

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.

Bent Hillerkus commented

2019-01-27 21:07:34 +01:00

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

Sebastian Parborg commented

2019-01-28 16:00:35 +01:00

Added subscriber: @ZedDB

Brecht Van Lommel was assigned by Sebastian Parborg

2019-01-28 16:00:35 +01:00

Sebastian Parborg commented

2019-01-28 16:00:35 +01:00

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

Marcus Papathoma commented

2019-02-18 12:56:13 +01:00

Added subscriber: @machieb

Bent Hillerkus commented

2019-04-23 21:33:49 +02:00

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.

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.

Brecht Van Lommel commented

2019-04-23 22:09:36 +02:00

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

Paul Kotelevets commented

2019-04-23 23:21:07 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2019-04-23 23:21:07 +02:00

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

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

msalv commented

2019-04-23 23:33:50 +02:00

Removed subscriber: @moisessalvador

MartinR commented

2019-04-27 20:11:38 +02:00

Added subscriber: @mares-1

Brecht Van Lommel removed their assignment 2019-04-30 15:09:02 +02:00

Jeroen Bakker was assigned by Brecht Van Lommel

2019-04-30 15:09:02 +02:00

Brecht Van Lommel commented

2019-04-30 15:09:02 +02:00

Added subscriber: @brecht

Jeroen Bakker removed their assignment 2019-04-30 15:34:08 +02:00

Brecht Van Lommel was assigned by Jeroen Bakker

2019-04-30 15:34:08 +02:00

Jeroen Bakker commented

2019-04-30 15:34:08 +02:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2019-04-30 15:34:08 +02:00

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

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

Brecht Van Lommel was unassigned by Jeroen Bakker

2019-04-30 15:34:38 +02:00

Jeroen Bakker self-assigned this 2019-04-30 15:34:38 +02:00

Jeroen Bakker commented

2019-04-30 16:26:33 +02:00

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)

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`)

Ovionis commented

2019-05-01 09:16:59 +02:00

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.

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.

Jeroen Bakker commented

2019-05-01 11:53:50 +02:00

@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.

@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.

Paul Kotelevets commented

2019-05-01 13:07:43 +02:00

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

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

Bent Hillerkus commented

2019-05-02 15:50:43 +02:00

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

Jeroen Bakker commented

2019-05-07 09:30:42 +02:00

Changed status from 'Open' to: 'Resolved'

Jeroen Bakker closed this issue

2019-05-07 09:30:42 +02:00

Christoph Werner commented

2019-08-01 10:35:24 +02:00

Added subscriber: @ChristophWerner

Christoph Werner commented

2019-08-01 10:35:24 +02:00

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

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

Paul Kotelevets commented

2019-08-01 23:52:59 +02:00

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?

Christoph Werner commented

2019-08-02 09:47:32 +02:00

In #60847#742716, @1D_Inc wrote:
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 #60847#742716, @1D_Inc wrote: > 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.

Paul Kotelevets commented

2019-08-02 13:04:14 +02:00

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

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

Christoph Werner commented

2019-08-02 14:31:32 +02:00

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.

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.

Troy Sobotka commented

2019-08-02 15:31:46 +02:00

Removed subscriber: @troy_s

alastair-hearsum commented

2024-01-03 23:59:44 +01:00

Blender 4 still has this issue. As an animator I want to fast feedback of the motion. Maya, Houdini, Softimage all have stable fast capturing of the viewport for rapid evaluation. I'm really puzzled how "viewport render animation" even in wireframe display can be 10 times slower than simply viewing it in the viewport. Am I missing something?

👍 2

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Viewport playback is fast, but rendering viewport to frames is slow #60847