Page MenuHome

Subdivision surface settings part of the Mesh
Confirmed, NormalPublicTO DO

Tokens
"Love" token, awarded by xrg."Love" token, awarded by andruxa696."Love" token, awarded by billreynish."Love" token, awarded by anaho."Love" token, awarded by Peps."Love" token, awarded by daven."Yellow Medal" token, awarded by amonpaike."Love" token, awarded by juang3d."Love" token, awarded by bnzs.
Assigned To
None
Authored By

Description

We want to make subdivision surfaces a property of the Mesh datablock. The modifier would be left as a less commonly used option

There are a few reasons for this:

  • OpenSubdiv GPU acceleration in the viewport and adaptive subdivision in Cycles need the modifier to be last in the stack. The available settings, behavior and implementation would be more clear if this was controlled outside of the modifier stack.
  • When we add modifier nodes support, the concept of a last modifier in the stack becomes fuzzy. Being able to pass along a subdivision surface Mesh to another node without actually subdividing is important for performance and to leave subdivision to the renderer.
  • For best performance with GPU acceleration, we don't want Blender to also subdivide the mesh on the CPU at all. But operations like hair positioning, particle emission and snapping still need to take into account the subdivision surface. If the Mesh datablock contains all the subdivision surface information, these could potentially work on the limit surface without subdividing the mesh on the CPU.
  • Simpler smooth normals handling, see T68893: Smooth shading usabilty.

Event Timeline

Dalai Felinto (dfelinto) lowered the priority of this task from 90 to Normal.Aug 20 2019, 8:06 PM
Dalai Felinto (dfelinto) created this task.

Hi.

Can I ask about the rationale for this? Is there is any advantage moving subsurf out of the modifiers would bring (ie. performance)?

Brecht Van Lommel (brecht) renamed this task from Per-Mesh Subsurf with OpenSubdiv to Subdivision surface settings part of the Mesh.Aug 21 2019, 6:14 PM
Brecht Van Lommel (brecht) updated the task description. (Show Details)
Juan Gea (juang3d) rescinded a token.
Juan Gea (juang3d) awarded a token.

Hi.
Can I ask about the rationale for this? Is there is any advantage moving subsurf out of the modifiers would bring (ie. performance)?

Also interested in use cases.
Subd modifier is nice for usability - multiple objects control, scene rendering setup and during complex organic modeling (mesh display modes).
Subd as mesh data seems to be mostly a display perfomance issue solution, depending on realization.

The rationale is in the task description.

For example, Subd can only be handled by GPU (OpenSubdiv) if in the bottom most part of the modifier stack. To have it as a mesh option allows users to more clearly benefit from OpenSubdiv without needing this technical understanding.

Thank you for response) This seems to be useful for characters displaying / animations.
Can be doubtable for parametric/mechanical modeling (subd before bevel or bevel before subd example)

The modifier would be left as a less commonly used option

Is it planned to move modifier's infrastructure to mesh implementation (Ctrl+1,2,0 shortcuts, mesh editing display modes, render/view values, options) to make it main?

Our current game project applies bevels and weighted normals after subdivision, and this gives us the kind of geometry we need in the game engine. If OpenSubdivs are removed from the modifier stack, we may lose necessary control over the quality of the final export geometry.

Our current game project applies bevels and weighted normals after subdivision, and this gives us the kind of geometry we need in the game engine. If OpenSubdivs are removed from the modifier stack, we may lose necessary control over the quality of the final export geometry.

Yep, it is mentioned as "Can be doubtable for parametric/mechanical modeling (subd before bevel or bevel before subd example)" in previous post.