Page MenuHome

Subdivision Surface modifier performance issues
Confirmed, NormalPublicBUG

Assigned To
None
Authored By
Midge Sinnaeve (mantissa)
Nov 29 2018, 10:05 PM
Tokens
"Like" token, awarded by mantissa."Love" token, awarded by juicebops."100" token, awarded by Frozen_Death_Knight."Like" token, awarded by bobalazek."Love" token, awarded by mysticfall."Like" token, awarded by anako."100" token, awarded by rotoglup."Love" token, awarded by stark."Like" token, awarded by RafaCM."Love" token, awarded by Krayzmond.

Description

System Information
Operating system: Xubuntu 18.04
Graphics card: Nvidia Titan X (Pascal)

Blender Version
Broken: 2.80 26d5a3625ed
Worked: Before the new "Quality" setting was introduced in the Subdivision Surface modifier

Short description of error
The Subdivision surface modifier has slowed down significantly, especially noticable with multiple Subdivision Surface modifiers on the same object.
Creating the same setup in the builds before the new setting is as fast as 2.79.

Exact steps for others to reproduce the error

  • Create Monkey object
  • Add Subdivision Surface modifier
  • Add Wireframe Modifier
  • Add second Subdivision Surface modifer

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I've elaborated a bit more on this issue in a devtalk post, as not to clutter the bug tracker too much.
Here's the full post for anyone interested: https://devtalk.blender.org/t/opensubdiv-issues-with-large-and-complex-meshes/5534

Could be this task change to high priority? actually any workflow that implies subdivision is nearly dead.

System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: GeForce GT 650M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 416.16

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-03 03:57, hash: rB8ab6ef30ab28

I'm new to Blender and I'm also stumbling on this issue while using adaptative subdivision for displacement map rendering using Blender 2.81 beta - FWIW a few precisions for my case :

  • I apply a SUBSURF modifier using the following code on my objects with a displacement material
mod = obj.modifiers.new(name="Displacement subdiv", type='SUBSURF')
mod.subdivision_type = 'SIMPLE'
mod.show_viewport = False
obj.cycles.use_adaptive_subdivision = True
  • I start a rendering with F12
  • the render image popup shows empty, with no progression message
    • Blender tries to consume a lot of RAM, eventually dies
  • after some 'long' time, the render image go alive
    • during the render init, the phases Updating mesh | Tesselating XXX are also 'long'
    • then phases Computing Displacement XXX are also 'long'

'long' means, for a minimal scene with *only one* object :

  • render time *without* modifier : 0.70 sec., peak mem 23Mb
  • render time *with* modifier : 24.00 sec, peak mem 817Mb (most time spent in init)
  • one mesh : 74k vert, 134k tris
  • if I apply a "Tris to Quads" on the mesh, the render time drops to 03.54 sec, peak mem 156Mb

With my full scene, the rendering crashes even with a beefier machine.

Would my repro test scene be of interest for you ?

(edited) to add mention of "Tris to Quads"

Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Bug".Feb 11 2020, 9:25 AM

These issues should not be closed.

The reason is that if this is not solved, then 2.8 will not be a new era of Blender, it will be the beginning of a decline that ends either with Blender being forked or with its inclusion in the FOSS graveyard.

This is a major issue with FOSS productivity software in general, performance is considered a "nice to have" rather than a central pillar, the fact that this isn't a priority indicates the BF risking the impression that it has learned little from NaN's bankruptcy. The team can talk about how Autodesk screws over the artist, but they at least know performance and work to fix any issue.

Fix the performance issues or there will be yet more reports from users. Pros can't use the software for any serious character work, so I propose that all Open Movie Projects are stopped immediately until subdivision speed matches or exceeds Blender 2.79. Please show that the BF has indeed become serious about pros using Blender as seen with the attention on UI, usability, and standards. If you guys are enjoying that million dollar dev. fund, then keeping performance on the back-burner will be the fastest way to shrink it to pre 2.8 levels.

@Adam Friesen (ace_dragon) the issue is NOT closed. Bug reports get merged if they are duplicates. If the main report is still Confirmed, then the bug is still open.

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 780/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: rB77d23b0bd76f
Worked: 2.79b

Short description of error
Blender is freezing deeply when you are trying to add Subdivision Surface modifier on complex object. Other modeling programs and Blender 2.79b work without any lags.

Exact steps for others to reproduce the error

  1. Open subdiv_performance.blend{F8368874}
  2. Select the only object in the scene
  3. Add Subdivision Surface from the modifiers stack
  4. Wait

Download subdiv_performance.blend

Hello. I began to discover the Blender 2.8 (used 2.7 sometime before). And get in stuck with this problem. My geometry, a little bit more complex than simple, give me 120 seconds to wait when I put a modifier on it.
I don't know. I think this more than normal priority to fix.
What we have for real. We can not do any high poly modelling now. Right?
Maybe we can see the previous version of this modifier if it is so hard to make it quick with new?

Same problem here, this is a major limitation, when we will see any update? Thanks!

I'm a bit confused on why this is a problem in the first place. I'm currently taking a Blender course on Udemy and I contacted one of the admins on the course, sent my file that has the same SUBSURF lag problem, and got feedback but surprisingly this admin didn't come across the same issue when he took a look at it after I sent him the file. Apparently this is a problem only some of us are having. Does the Quality value have something to do with it? Because all of us who are familiar with the 2.7 series are familiar and can recall that the SUBSURF modifier didn't have a quality value. What is the purpose of the Quality value? I've never really noticed anything better about it compared to when Blender didn't have it.

When I'm working with a model that a bit complexer with a subdivision modifier, the editing becomes slow. This bothers me a lot because this is a very common situation. I think this performance issue should have a higher priority to solve.

I am a little bit baffled this is an issue, I am considering making a jump to Blender, but this is, for me, a core issue, without it, not much else is useful, if we cant model without slowing it down.
But I also know that some people are not experiencing this... if we could at least discover what could be causing it?
Im on Windows 10 i7, 2 GTX 1080 GPU.

YAFU (YAFU) added a comment.EditedJun 4 2020, 11:25 PM

I'm not sure if I should open a new report with this .blend file:

You press M > Collapse, then Blender hangs for a long time, a simple CPU thread process is working. I must kill blender process. The same happens if you delete the subsurf modifier, collapse the edge loop, and then add subsurf modifier.
The problem occurs in Blender 2.8x and 2.90. The problem does not occur in Blender 2.7x
Using Kubuntu Linux