Subdivision surface settings part of the Mesh #68891

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 #68893 (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 #68893 (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

**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 #68893 (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) - [x] (follow up to [D10145: Subdivision: add support for vertex creasing](https://archive.blender.org/developer/D10145)) move edge crease to a custom data layer - Cycles/EEVEE - [x] detect subdivision using the mesh settings instead of the modifier - Normals (work on some aspects of #68893 (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

Added subscriber: @dfelinto

Added subscriber: @SergienkoEugene

Added subscriber: @Ace_Dragon

Hi.

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

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

Added subscriber: @JasonClarke

Added subscriber: @lemenicier_julien

Added subscriber: @BrianSavery

Removed subscriber: @BrianSavery

Added subscriber: @giuseppebufalo

Added subscriber: @1D_Inc

In #68891#757468, @Ace_Dragon wrote:
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.

> In #68891#757468, @Ace_Dragon wrote: > 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.

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?

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?

Added subscriber: @zaster

Added subscriber: @Frand

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.

In #68891#797249, @Frand wrote:
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.

> In #68891#797249, @Frand wrote: > 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.

Added subscriber: @rotoglup

Added subscriber: @LucasVeber

Added subscriber: @EAW

Added subscriber: @Andruxa696

Added subscriber: @JacobMerrill-1

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)

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.

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? Also has transform feedback for data for nex frame etc? (pass out particles it emitted etc)

In #68891#875961, @JacobMerrill-1 wrote:
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.

> In #68891#875961, @JacobMerrill-1 wrote: > 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.

Added subscriber: @Znio.G

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?

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?

In #68891#877409, @Znio.G wrote:
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?

> In #68891#877409, @Znio.G wrote: > 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?

In #68891#877468, @1D_Inc wrote:

In #68891#877409, @Znio.G wrote:
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.

> In #68891#877468, @1D_Inc wrote: >> In #68891#877409, @Znio.G wrote: >> 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. ![Link.gif](https://archive.blender.org/developer/F8357456/Link.gif)

In #68891#877510, @Znio.G wrote:

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.

> In #68891#877510, @Znio.G wrote: >> 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.

In #68891#877586, @1D_Inc wrote:

In #68891#877510, @Znio.G wrote:

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.

> In #68891#877586, @1D_Inc wrote: >> In #68891#877510, @Znio.G wrote: >>> 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.

Added subscriber: @brecht

In #68891#797249, @Frand wrote:
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.

In #68891#877409, @Znio.G wrote:
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.

> In #68891#797249, @Frand wrote: > 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. > In #68891#877409, @Znio.G wrote: > 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.

Thank you @brecht for the answer.

In #68891#877712, @Znio.G wrote:

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.

> In #68891#877712, @Znio.G wrote: > 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.

In #68891#877717, @brecht wrote:

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?

> In #68891#877717, @brecht wrote: > 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?

In #68891#877758, @1D_Inc wrote:
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.

> In #68891#877758, @1D_Inc wrote: > 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.

In #68891#879652, @brecht wrote:
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.

> In #68891#879652, @brecht wrote: > 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.

Added subscriber: @Russ1642

Added subscriber: @ostry

Added subscriber: @MichaelHermann

Added subscriber: @jakaboxjumping-2

Added subscriber: @Nominous

Added subscriber: @kevindietrich

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 @Znio.G in #68891#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):

subdiv_linked_duplicates_2.mp4

(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.)

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 @Znio.G in #68891#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): [subdiv_linked_duplicates_2.mp4](https://archive.blender.org/developer/F10162036/subdiv_linked_duplicates_2.mp4) (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.)

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

Removed subscriber: @giuseppebufalo

In #68891#1173244, @kevindietrich wrote:
As it stands, simply storing the parameters in the Mesh data-block solves the issue reported by @Znio.G in #68891#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.

> In #68891#1173244, @kevindietrich wrote: > As it stands, simply storing the parameters in the Mesh data-block solves the issue reported by @Znio.G in #68891#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 ](https://youtu.be/Xdwvl9JFr2M) 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 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)

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.

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.

In #68891#1174570, @brecht wrote:
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.

> In #68891#1174570, @brecht wrote: > 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.

Added subscriber: @TheRedWaxPolice

Added subscriber: @heini

Added subscriber: @SteffenD

Added subscriber: @Garek

Added subscriber: @dursunumit

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Labels Milestones

Subdivision surface settings part of the Mesh #68891