Subdivision Surface Modifier slow when animation started with EEVEE #75579

New Issue

Henrik D. · 2020-04-10T12:03:50+02:00

Henrik D. commented

2020-04-10 12:03:50 +02:00

System Information
Operating system: Linux (Debian bullseye)
Graphics card: Nvidia Geforce GTX 1070

Blender Version
Broken: 2.80 up to current master (d3cda49d14)
Worked: Never

Short description of error
The performance wildly varies when Workbench shading is used and EEVEE shading is used when the animation starts.
Basically if EEVEE is used and the timeline is reset and played it will have half the framerate than when Workbench is
used when the timeline was reset. I first though this was a problem with EEVEE but as it turns out, when the animation
runs with Workbench and it is switched to EEVEE while it is running it will have the same good performance with EEVEE.
For more testing I included instructions in the blend file to show the problem. Similar to solid viewport shading, undo also
increases performance (see instructions in the blend file).

I file this as a bug even if its about performance because it seems like the limit is not my computing power here.

Exact steps for others to reproduce the error
slow_subdiv.blend

Open file
Start playback with Solid Shading and remember the framerate
Go into Material Preview Shading
Reset the timeline with Shift+Left Arrow

Start playback

framerate is only half of the framerate we started with

Go back into Solid Shading
Reset the timeline with Shift+Left Arrow

Start playback and while running select Material Preview Shading

framerate stays roughly the same, but as soon as it gets to the end frame and loops it will go down again

Stay in Material Preview Shading
Deselect the object
Reset the timeline with Shift+Left Arrow
Start playback and press Ctrl+Z to undo the selection, note that before pressing Ctrl+Z
framerate is what we started with.

**System Information** Operating system: Linux (Debian bullseye) Graphics card: Nvidia Geforce GTX 1070 **Blender Version** Broken: 2.80 up to current master (d3cda49d143) Worked: Never **Short description of error** The performance wildly varies when Workbench shading is used and EEVEE shading is used when the animation starts. Basically if EEVEE is used and the timeline is reset and played it will have half the framerate than when Workbench is used when the timeline was reset. I first though this was a problem with EEVEE but as it turns out, when the animation runs with Workbench and it is switched to EEVEE while it is running it will have the same good performance with EEVEE. For more testing I included instructions in the blend file to show the problem. Similar to solid viewport shading, undo also increases performance (see instructions in the blend file). I file this as a bug even if its about performance because it seems like the limit is not my computing power here. **Exact steps for others to reproduce the error** [slow_subdiv.blend](https://archive.blender.org/developer/F8462564/slow_subdiv.blend) - Open file - Start playback with Solid Shading and remember the framerate - Go into Material Preview Shading - Reset the timeline with Shift+Left Arrow # Start playback framerate is only half of the framerate we started with - Go back into Solid Shading - Reset the timeline with Shift+Left Arrow # Start playback and while running select Material Preview Shading framerate stays roughly the same, but as soon as it gets to the end frame and loops it will go down again - Stay in Material Preview Shading - Deselect the object - Reset the timeline with Shift+Left Arrow - Start playback and press Ctrl+Z to undo the selection, note that before pressing Ctrl+Z framerate is what we started with.

Henrik D. commented

2020-04-10 12:03:50 +02:00

Added subscriber: @HDMaster84

Germano Cavalcante commented

2020-04-13 14:00:24 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-04-13 14:00:24 +02:00

I cannot reproduce the problem. The FPS is pretty much the same here:

Operating system: Windows-10-10.0.18941 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 19.50.01.05 26.20.15001.5006

I cannot reproduce the problem. The FPS is pretty much the same here: **Operating system:** Windows-10-10.0.18941 64 Bits **Graphics card:** Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 19.50.01.05 26.20.15001.5006

Henrik D. commented

2020-04-13 16:53:58 +02:00

Tested on one more device with the same result (half the framerate when playback started with EEVEE shading)

Blender Version: 2.81.16
Operating System: Windows 10 Version 1703
Graphics card: Nvidia Geforce GT 540M Driver Version 21.21.13.7654

Tested on one more device with the same result (half the framerate when playback started with EEVEE shading) **Blender Version:** 2.81.16 **Operating System:** Windows 10 Version 1703 **Graphics card:** Nvidia Geforce GT 540M Driver Version 21.21.13.7654

Richard Antalik commented

2020-04-14 12:46:18 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-04-14 12:46:18 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik commented

2020-04-14 12:46:18 +02:00

I can confirm this, I can also see some difference in profiler. I don't know if this is enough to have even clue what issue may be though.

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Radeon RX550/550 Series ATI Technologies Inc. 4.5.13587 Core Profile Context 20.4.1 26.20.15029.20013
version: 2.83 (sub 13), branch: master, commit date: 2020-04-13 15:15, hash: 5cf7283342

I can confirm this, I can also see some difference in profiler. I don't know if this is enough to have even clue what issue may be though. ![slow.png](https://archive.blender.org/developer/F8469618/slow.png) ![fast.png](https://archive.blender.org/developer/F8469619/fast.png) **System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: Radeon RX550/550 Series ATI Technologies Inc. 4.5.13587 Core Profile Context 20.4.1 26.20.15029.20013 version: 2.83 (sub 13), branch: master, commit date: 2020-04-13 15:15, hash: `5cf7283342`

Sergey Sharybin commented

2020-05-15 16:20:10 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2020-05-15 16:20:10 +02:00

The difference I see is almost at the noise level. It is also easier/more reliable to use --debug-depsgraph-time which will print time of dependency graph evaluation per frame, not some accumulated percentage of application run time.

For me the time is same regardless of shading mode. And FPS in viewport is also the same. So can someone who is able to reproduce the issue see whether --debug-depsgraph-time gives different timing depending on shading mode?

The difference I see is almost at the noise level. It is also easier/more reliable to use `--debug-depsgraph-time` which will print time of dependency graph evaluation per frame, not some accumulated percentage of application run time. For me the time is same regardless of shading mode. And FPS in viewport is also the same. So can someone who is able to reproduce the issue see whether `--debug-depsgraph-time` gives different timing depending on shading mode?

Henrik D. commented

2020-05-15 18:45:37 +02:00

Results from --debug-depsgraph-time is the same. Make sure you follow the steps exactly in that order otherwise the performance could be the same as you said.

Solid Shading:
Depsgraph updated in 0.125152 seconds.
Depsgraph evaluation FPS: 7.345796

Preview Shading:
Depsgraph updated in 0.242872 seconds.
Depsgraph evaluation FPS 4.027414

Results from `--debug-depsgraph-time` is the same. Make sure you follow the steps exactly in that order otherwise the performance could be the same as you said. **Solid Shading:** Depsgraph updated in 0.125152 seconds. Depsgraph evaluation FPS: 7.345796 **Preview Shading:** Depsgraph updated in 0.242872 seconds. Depsgraph evaluation FPS 4.027414

Richard Antalik commented

2020-05-18 09:41:02 +02:00

My results are:

Open file

Start playback with Solid Shading and remember the framerate

Depsgraph updated in 0.166975 seconds.
Depsgraph evaluation FPS: 5.572114

Go into Material Preview Shading

Reset the timeline with Shift+Left Arrow

Start playback

Depsgraph updated in 0.326814 seconds.
Depsgraph evaluation FPS: 1.242974

My results are: > # Open file > # Start playback with Solid Shading and remember the framerate Depsgraph updated in 0.166975 seconds. Depsgraph evaluation FPS: 5.572114 > # Go into Material Preview Shading > # Reset the timeline with Shift+Left Arrow > # Start playback Depsgraph updated in 0.326814 seconds. Depsgraph evaluation FPS: 1.242974

Sergey Sharybin commented

2020-05-18 12:09:27 +02:00

Ok, now I start to see what's going on.

When EEVEE is used as render engine it requests ORCO (ORiginal COordinates, or Generated Coordinates) for shading. This makes it so the subsurf modifier is applied twice: once for geometry output and once for generated texture coordinates.

The slowdown is not limited to subdivision surface modifier, any non-deformation-only modifier will experience the slowdown. This is just part of the current design limitation. Some ideas how to avoid such duplicate modifiers evaluation:

Don't evaluate modifier twice if the set of modifiers used for generated textures coordinates and for geometry mesh output is the same.
Try to look into vertex attribute based approach, so that original coordinates are set as an attribute on vertices and then are interpolated as needed, If there is a way to do so this will be the ultimate solution: there will be never the case when modifier is evaluated twice.

What I am not sure about is why this special steps of re-starting animation is needed. Would imagine that no matter the steps you do performance in material shading will always be lower, and performance in solid mode will always be faster.

So to me this seems more like a current design limitation.

On a related topic, noticed that there is a mistake in code (and/or logic) which does not allow to benefit from OpenSubdiv in this file. The details are reported in #76855.

Ok, now I start to see what's going on. When EEVEE is used as render engine it requests ORCO (ORiginal COordinates, or Generated Coordinates) for shading. This makes it so the subsurf modifier is applied twice: once for geometry output and once for generated texture coordinates. The slowdown is not limited to subdivision surface modifier, any non-deformation-only modifier will experience the slowdown. This is just part of the current design limitation. Some ideas how to avoid such duplicate modifiers evaluation: - Don't evaluate modifier twice if the set of modifiers used for generated textures coordinates and for geometry mesh output is the same. - Try to look into vertex attribute based approach, so that original coordinates are set as an attribute on vertices and then are interpolated as needed, If there is a way to do so this will be the ultimate solution: there will be never the case when modifier is evaluated twice. What I am not sure about is why this special steps of re-starting animation is needed. Would imagine that no matter the steps you do performance in material shading will always be lower, and performance in solid mode will always be faster. So to me this seems more like a current design limitation. --- On a related topic, noticed that there is a mistake in code (and/or logic) which does not allow to benefit from OpenSubdiv in this file. The details are reported in #76855.

Henrik D. commented

2021-08-15 15:51:18 +02:00

In fact a test shows that if I start the animation with solid mode and switch to material shading, the Generated coordinates are not computed correctly.

generated_coordinates.mp4

In fact a test shows that if I start the animation with solid mode and switch to material shading, the Generated coordinates are not computed correctly. [generated_coordinates.mp4](https://archive.blender.org/developer/F10282483/generated_coordinates.mp4)

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Subdivision Surface Modifier slow when animation started with EEVEE #75579

Start playback

Start playback and while running select Material Preview Shading

Open file

Start playback with Solid Shading and remember the framerate

Go into Material Preview Shading

Reset the timeline with Shift+Left Arrow

Start playback