Page MenuHome

OpenSubdiv GPU acceleration
Confirmed, NormalPublicTO DO

Tokens
"Burninate" token, awarded by billreynish."Burninate" token, awarded by postrowski."Yellow Medal" token, awarded by epieter."Love" token, awarded by CobraA."Burninate" token, awarded by ogotay."Love" token, awarded by symstract."Burninate" token, awarded by -L0Lock-."Love" token, awarded by mantissa."Pterodactyl" token, awarded by filibis."The World Burns" token, awarded by 1seby."Burninate" token, awarded by codygo."Love" token, awarded by Kickflipkid687."Burninate" token, awarded by Mephisto."The World Burns" token, awarded by Sunbeam."Burninate" token, awarded by madminstrel."Burninate" token, awarded by BlackRainbow."Love" token, awarded by michaelknubben."Burninate" token, awarded by serhatergen."Burninate" token, awarded by czerw."Party Time" token, awarded by szap."Burninate" token, awarded by mazigh."Burninate" token, awarded by 51423benam."Burninate" token, awarded by Astiero."Burninate" token, awarded by Polygreen."Burninate" token, awarded by EAW."Dat Boi" token, awarded by koloved."Love" token, awarded by DaPaulus."Love" token, awarded by Tvartiainen."Burninate" token, awarded by wilsman77."Burninate" token, awarded by reanimate."Love" token, awarded by andruxa696."Love" token, awarded by cruelandunusual."Burninate" token, awarded by Kronk."Love" token, awarded by leonumerique."Burninate" token, awarded by aditiapratama."Evil Spooky Haunted Tree" token, awarded by z01nk."Burninate" token, awarded by Draise."Burninate" token, awarded by 3Rton."Love" token, awarded by snubilo."Love" token, awarded by mistajuliax."100" token, awarded by Zino."Burninate" token, awarded by amonpaike."Love" token, awarded by brilliant_ape."Love" token, awarded by realeyez."Love" token, awarded by lucky3."Love" token, awarded by bnzs."Love" token, awarded by daven."Love" token, awarded by xdanic.
Assigned To
None
Authored By

Description

Status: Needs to be formatted as a project once there is someone to tackle this. Including use cases, milestones, task breakdown, etc.


We want to have a per-object subdivision object that operates on top of the entire stack of transformations. The options would be the same (or very similar) to the existing modifier (when using Catmull-Clark), If the last modifier in the stack is a Subdivision, an heuristic can take care of conciliating both results.

Said subdivision in the viewport is to be performed on the GPU. For rendering it would also use OpenSubdiv but on the CPU.

Event Timeline

Dalai Felinto (dfelinto) lowered the priority of this task from 90 to Normal.Aug 21 2019, 4:22 PM
Dalai Felinto (dfelinto) created this task.
Seby (1seby) added a subscriber: Seby (1seby).

May we please get a status update by a developer on this task? It is my understanding that the two main reasons for implementing OpenSubdiv in Blender were:

  • to enable rendering of SubD models at much higher speed and subdivision levels without the increased memory footprint
  • to add support for proper creasing on SubD models

Of the two points only the second one is implemented - partially. Modelling of SubD assets using OpenSubdiv creases is well supported but the algorithm needs higher subdivision levels to work properly which makes the actual rendering of scenes that contain more than a few of such assets virtually impossible due to the increased memory consumption (also creases do not work properly with adaptive subdivision and vertex creasing is not implemented at all).

I appreciate the work you developers are doing and understand you cannot fix every problem at once. However, this task has been open since last August while the actual problems with the current implementation have been known since before the 2.8 release. Yet it seems like nothing is happening on that front. Could we please get some feedback by a developer on what the current status on fixing this issue is?

Thanks again for all your ongoing work on this great piece of open source software.

The current SubD modifier slows everything down.
In addition to the animation playback (shape and bones), modeling, cloth simulation and shape creation are slowed down, you have to do everything without viewing the SubD in the viewport. With heavy mesh + SubD everything gets jerky. We hope that you can solve at least 2.84 or 2.85, thanks!

lucas veber (lucky3) added a comment.EditedWed, Feb 19, 4:49 PM

Why is it lower priority than T68908?
This would allow realtime playback and realtime posing (a mesh cacher can't do that) of rigged characters with subdivision, which is quite essential when animating facial expressions for example.
Typically, realtime subsurf calculation would avoid mesh caching in many cases, which would be a significant benefit.

Fast SubDiv is a standard that is difficult to give up on.

For 2.81 and 2.82, many users acknowledged that you had a lot of loose ends and technical debt to clean up, so we were patient.

Now, and especially with the tracker curfew completing phase 1, the users want action. On BA, you have users threatening to abandon Blender or consign Blender as an app. with no future. I propose that these regressions get tackled for 2.83, and delay 2.83 itself as long as needed to make sure that it at least has subsurf at 2.79 performance or better. Based on what I've read on this site, the core team knows where the bottlenecks are and what could be causing them, so any inaction here will simply be the result of bad priorities and poor management decisions.

There are no mid-range apps, under active development and the only equivalent apps. cost over 1K with pricey subscriptions, a lot of people have their very ability to work with CGI tied to Blender, please don't let them down.

To be clear, there are multiple performance projects for 2020:

  • Faster high-poly mesh editing
  • Faster animation playback
  • Faster object mode performance

These all have equal priority and will be mostly worked on by different developers in parallel. High-poly mesh editing and animation playback both are affected by subdivision surfaces and performance will be looked at in the context of both.

I'm removing the last line from the description since it only adds confusion and is not accurate in general, it depends on the specific use case. For some heavy rigs subdivision surfaces might not be the first concern, for other rigs it may be what is holding back performance.