Page MenuHome

Subdivision Surface Modifier slow when animation started with EEVEE
Confirmed, NormalPublicKNOWN ISSUE


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

  1. Open file
  2. Start playback with Solid Shading and remember the framerate
  3. Go into Material Preview Shading
  4. Reset the timeline with Shift+Left Arrow
  5. Start playback

framerate is only half of the framerate we started with

  1. Go back into Solid Shading
  2. Reset the timeline with Shift+Left Arrow
  3. 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

  1. Stay in Material Preview Shading
  2. Deselect the object
  3. Reset the timeline with Shift+Left Arrow
  4. Start playback and press Ctrl+Z to undo the selection, note that before pressing Ctrl+Z

framerate is what we started with.

Event Timeline

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 26.20.15001.5006

Henrik Dick (weasel) added a comment.EditedApr 13 2020, 4:53 PM

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

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.EditedApr 14 2020, 12:44 PM
Richard Antalik (ISS) updated the task description. (Show Details)

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: rB5cf72833429f

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?

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

My results are:

  1. Open file
  2. Start playback with Solid Shading and remember the framerate

Depsgraph updated in 0.166975 seconds.
Depsgraph evaluation FPS: 5.572114

  1. Go into Material Preview Shading
  2. Reset the timeline with Shift+Left Arrow
  3. Start playback

Depsgraph updated in 0.326814 seconds.
Depsgraph evaluation FPS: 1.242974

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

Clément Foucault (fclem) changed the subtype of this task from "Report" to "Known Issue".