Hi.

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

In T68891#757468, @Adam Friesen (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.

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.

In T68891#797249, @Jani Kahrama (FrandSX) 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.

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)

In T68891#875961, @Jacob Merrill (blueprintrandom) 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.

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 T68891#877409, @Zino Guerr (Zino) 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 T68891#877468, @Paul Kotelevets (1D_Inc) wrote:

In T68891#877409, @Zino Guerr (Zino) 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 T68891#877510, @Zino Guerr (Zino) 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 T68891#877586, @Paul Kotelevets (1D_Inc) wrote:

In T68891#877510, @Zino Guerr (Zino) 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 T68891#797249, @Jani Kahrama (FrandSX) 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 T68891#877409, @Zino Guerr (Zino) 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 Van Lommel (brecht) for the answer.

In T68891#877712, @Zino Guerr (Zino) 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 T68891#877717, @Brecht Van Lommel (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 T68891#877758, @Paul Kotelevets (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 T68891#879652, @Brecht Van Lommel (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.

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

In T68891#1173244, @Kévin Dietrich (kevindietrich) wrote:

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.

In T68891#1174570, @Brecht Van Lommel (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.