Page MenuHome

Subdivision surface settings part of the Mesh
Confirmed, NormalPublicTO DO

Authored By
Dalai Felinto (dfelinto)
Aug 20 2019, 8:06 PM
Tokens
"Love" token, awarded by Blendork."Love" token, awarded by SteffenD."Love" token, awarded by HEYPictures."Love" token, awarded by PiloeGAO."Love" token, awarded by Nominous."Love" token, awarded by Shimoon."Burninate" token, awarded by BlackRainbow."Love" token, awarded by pierogo."Love" token, awarded by Zino."100" token, awarded by Frozen_Death_Knight."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.

Description

Description

We want to make subdivision surfaces a property of the Mesh datablock. The modifier would remain, but would likely be used less.

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.
  • File formats like USD have native subdivision surface primitives. By making it part of the mesh, we are more compatible with such file formats.

TODOs

  • Modeling
    • conjugate the presence of a subdivision surface modifier with the mesh settings if it is the last in the stack
    • ensure creases survive the modifier stack (unless consumed by a subsurf modifier)
    • (follow up to D10145: Subdivision: add support for vertex creasing) move edge crease to a custom data layer
  • Cycles/EEVEE
    • detect subdivision using the mesh settings instead of the modifier
  • Normals (work on some aspects of T68893: Smooth shading usabilty)
    • remove autosmooth and custom normals options if the mesh is a subdivision surface
    • always render with smooth normals (flat areas can also be defined trough creasing)
  • Alembic/USD
    • set mesh settings during imports
    • export as SubD Object when subdivision is used
  • Workflow
    • option to set the subdivision settings when creating a mesh, or add a sub-menu with meshes with subdivision enabled
    • shortcuts to subdivide (?)
    • script/addon to update old files to replace last subdivision modifier in the stack with mesh settings (doing this in version code might have undesirable side effects)
  • Other
    • Update test files

Event Timeline

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

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.

What about a shader to do this?

Vertex transform feedback?
So it still fits in the stack?

Gpu is idle at this point of render anyway? (asking I don't know)

I am not sure how exactly "less commonly used" is counted.

The ability to place subd in a stack to control behavior and result by its order is definitely workflow dependent feature, so it will be less commonly used by someone like character animators only, not modelers for example.

What about getting rid of modifiers and instead writing vertex shader nodes capable of doing skinning and subdivision?

Also has transform feedback for data for nex frame etc?
(pass out particles it emitted etc)

What about getting rid of modifiers and instead writing vertex shader nodes capable of doing skinning and subdivision?

It will have the same lack of flexibility issue, but you can already write any vertex shader you want and then just commit it as a shader. Just like bevel shader some time ago.

A quick stupid question.
Coming from Maya i always was able to have smooth preview with subdivisons on instanced meshes(duplicated linked) but in Blender since you have to use the subdiv modifier, then the linked duplicated meshes don't "instance that modifier", so you only have the preview on the original mesh until you enter edit mode.

So we'll be able to have this functionality when Subdivision is part of the Mesh or we would need a way to link the modifier with the duplicated linked meshes?

Coming from Maya i always was able to have smooth preview with subdivisons on instanced meshes(duplicated linked)

Can you, please, post a couple of screenshots (object mode / edit mode) with instances from Maya to clarify the issue?

Zino Guerr (Zino) added a comment.EditedFeb 21 2020, 2:59 PM

Coming from Maya i always was able to have smooth preview with subdivisons on instanced meshes(duplicated linked)

Can you, please, post a couple of screenshots (object mode / edit mode) with instances from Maya to clarify the issue?

I can do that but the last time i tried Brecht said it's not okay to make such posts.
I don't want to put the Devs in uncomfortable situation where they have to delete our comments, But i can show you with Blender.

Here i have a cube instanced 4x times put a Subdiv modifier on one, can easily modify them in edit mode but once i go to object mode then the modifier is only used on one object and can't be applied.

The only trick i know is you have to join them with the last selected object that has the modifier, apply it then separate them again.

While in Maya it's simpler, Instance, smooth preivew, model then convert those instances to objects.

Can you, please, post a couple of screenshots (object mode / edit mode) with instances from Maya to clarify the issue?

I can do that but the last time i tried Brecht said it's not okay to make such posts

Well, okay then. Thank you for GIF.

The only trick i know is you have to join them with the last selected object that has the modifier, apply it then separate them again.

EDITED
Yes, the ability to set subd directly on mesh level should make subd inherit through all instances.
Seems you are using 2.81, such weird modified instances behavior was fixed in 2.82.

Can you, please, post a couple of screenshots (object mode / edit mode) with instances from Maya to clarify the issue?

I can do that but the last time i tried Brecht said it's not okay to make such posts

Well, okay then. Thank you for GIF.

The only trick i know is you have to join them with the last selected object that has the modifier, apply it then separate them again.

EDITED
Yes, the ability to set subd directly on mesh level should make subd inherit through all instances.
Seems you are using 2.81, such weird modified instances behavior was fixed in 2.82.

I am using 2.82 and it seems we might have found a bug, i tried 2.81 and it's different.
I'll report it.

If OpenSubdivs are removed from the modifier stack, we may lose necessary control over the quality of the final export geometry.

The subdivision surface modifier is not proposed to be removed from the stack. But if you are doing subdivision surface followed by bevel, you will not be able to benefit from OpenSubdiv GPU acceleration, since the library does not support that.

A quick stupid question.
Coming from Maya i always was able to have smooth preview with subdivisons on instanced meshes(duplicated linked) but in Blender since you have to use the subdiv modifier, then the linked duplicated meshes don't "instance that modifier", so you only have the preview on the original mesh until you enter edit mode.

So we'll be able to have this functionality when Subdivision is part of the Mesh or we would need a way to link the modifier with the duplicated linked meshes?

You will be able to have this functionality. The proposal is to not require a modifier to be present to create subdivision surfaces, so there is no modifier to link.

I am using 2.82 and it seems we might have found a bug, i tried 2.81 and it's different.
I'll report it.

That's actually strange. I've contacted our team and we figured that official 2.82 doesnot share modifiers to instances in edit mode by default on multiple computers.
That's proper behaviour, otherwize editing single instance with subd, placed close to camera, will inherit subd to other instances, that will drop down viewport perfomance for every editing session.
That issue was fixed.

The subdivision surface modifier is not proposed to be removed from the stack.

That's great! Thank you for the answer.

You will be able to have this functionality. The proposal is to not require a modifier to be present to create subdivision surfaces, so there is no modifier to link.

There was also a question of infrastructure. We are wondering if hotkeys for modifier will be changed, because for multiple objects subd modifier can be placed to a different level, so it is nice to control it with Ctrl+1, 2, 0 shortcuts.
Will it be possible to assign mesh datablock subd level to something like Alt+Shift+1, 2, 0, keeping subd modifier shortcuts?

There was also a question of infrastructure. We are wondering if hotkeys for modifier will be changed, because for multiple objects subd modifier can be placed to a different level, so it is nice to control it with Ctrl+1, 2, 0 shortcuts.
Will it be possible to assign mesh datablock subd level to something like Alt+Shift+1, 2, 0, keeping subd modifier shortcuts?

It's too early to make decisions on that. There are many design details to work out once work actually starts on this.

It's too early to make decisions on that. There are many design details to work out once work actually starts on this.

For sure. Thank you for the answer.

Claiming this task since I started looking into this for my GPU subdivision work, as not worrying about modifiers kinda simplifies detecting whether subdivision should be used (which is also noted in the task description). Maybe we could format this as a project, to note exactly what change is needed, areas to improve/look at, etc?

As it stands, simply storing the parameters in the Mesh data-block solves the issue reported by @Zino Guerr (Zino) in T68891#877510 since linked duplicates share subdivision data, which is not really doable with modifiers (first part of the video is with modifiers, second part is using the Mesh setting):

(This also solves the issue of Cycles receiving an already subdivided mesh from the modifier when adaptive subdivision is used, by simply not requiring a modifier.)

@Kévin Dietrich (kevindietrich) not sure what exactly you mean by formatting this as a project. But feel free to edit the task description, with more specific plans and todo items.

As it stands, simply storing the parameters in the Mesh data-block solves the issue reported by @Zino Guerr (Zino) in T68891#877510 since linked duplicates share subdivision data, which is not really doable with modifiers (first part of the video is with modifiers, second part is using the Mesh setting):

Yes!
And subd modifier solves another widespread usecase - when you don't need to share subdivision data between instances, which is not really doable with mesh data.
That is the point of a subd modeling workflow - to obtain a model that have subd levels that can be used as LODs.
For example, as a result of subd modeling you can subd only those decor object that is close to the camera, or what you need to modify/edit at some point to check its subd curvature without overwhelming viewport with subdivision of all its instances.

It is workflow dependent.

I don't want to poke the bear here, but it would seem

LOD/tesselate, displace, animate should all be done on the GPU and 'gathered' by the logic somehow

so I think this is a great start !

also game engines use a 'blend' between LOD levels using a stable alpha hash *

I want to clarify that modifier and mesh subd realizations have different scopes.

  • Modifier subd stands for flexibility (modifiers stack positioning) and linked data objects (instances) independency - which is suitable for modeling workflows, while
  • Mesh subd stands for GPU acceleration and linked data objects uniformity - which is suitable for visualization and animation workflows.

So I am asking if it is possible to change the description of the task from

We want to make subdivision surfaces a property of the Mesh datablock. The modifier would remain, but would likely be used less.

to something like

We want to make subdivision surfaces a property of the Mesh datablock which is very useful for visualization and animation workflows.

We want to make subdivision surfaces a property of the Mesh datablock. The modifier would remain, but would likely be used less for animation and visualization workflows.

We want to make subdivision surfaces a property of the Mesh datablock. The modifier would remain for modeling workflows.

to avoid confusion.

Our modellers tried to imagine how they can probably use subd modifier "less" with the proposed solution and failed at it, since subd modifier is a primary tool for different types of modeling workflows)

The current description is fine, let's not assume your preferred workflows apply to everyone or that you can predict how it would be used by others.

Indeed, it may look like I am trying to push some preferred workflow, while situation is quite opposite - if you need stack position flexibility, you have to use subd modifier, and when you need faster GPU and instances dependency you have to use mesh subd. There can't be a preferred option.

I want to point out that in current form description assumes that subd modifier will be used less, this can be interpreted as if mesh subd is a true substitution for subd modifier and is preferable option, which is not true for workflows where stack flexibility is needed.
How about to point it directly, something like:

The modifier would remain for cases when modifier stack position flexibility is needed.

The current description is fine

Let's take a look.

The modifier would remain, but would likely be used less.

The very first question - less than what?

Less than mesh subd? Both realizations are needed for their own workflow-depenent usecases which are not mutually exclusive.
Less than usual? Generally unprovable because of the same reason.
Less than average? What kind of average, and how to estimate it.

So many questions out of the blue.