Modifiers in 2.8

Any idea when any of the modifiers are actually going to work on meshes in 2.8?

(Or am I doing something wrong?)

i.e. if I put a subd modifier on a cube, no subd :frowning:

If I apply the modifier then it’s subdivided, so it’s seems it’s the live preview that is not currently enabled (or coded?)

Modifiers are not hooked up yet, I believe they are pending Dependency Graph updates. No estimate for when they will be active.

The last Monday Meeting indicates that the tool/operator hookups will probably begin next week (as key pieces of the depsgraph get finished). In this case, it’s probable that modifiers will start to work before the end of the year.

Sweet, can’t wait to use eevee for everything :slight_smile:

I don’t think that’s the same thing as far as I know. I think we’re waiting for “Copy On Write” for modifiers to work.

We can test Copy On Write by launching blender2.8 with --enable-copy-on-write command option.

At that moment, some modifiers are reacting in Viewport. But with the option enabled, 2.8 is unusable.
Armature are invisible. 3D Cursor position is updated with a delay. And any attempt to switch from object mode to another one will instantly crash blender.

If you take a look to the roadmap, you can see that what was expected to be done in October will be done next week.
https://wiki.blender.org/index.php/Dev:2.8/Source/Depsgraph/Planning-October2017#Rough_Planning
So, if we are optimistic, we can hope modifiers working in February.
If we are pessimistic, we could wait until April.

The roadmap shows that the first modifiers are already in the process of being ported, but there’s a lot of modifiers so it will take a while.

Depsgraph work in general is firing on all cylinders now, with both 2.8 and master seeing a fairly decent number of commits in that area.

Does the 2.8 dependecy graph expect to fix blender’s poor animation performance, or is there anything being developed/planned to improve that?

Blender can move around over 750k faces with 30fps+ no problem, but the reason it drops to less than 15fps with far less polies, is because of (excluding a heavy rig) the armature deform modifier. (also why posing on a single frame can lag)

I’ve been looking forward to 2.8 for eevee (with animation) but it’s occurred to me that the only talk of animation I can recall is just supporting modifiers. Well, since the new depsgraph is taking so much effort to do, and the modifiers are disabled to get them working with it, I’m hoping that the new system would also include better performance.

Anyone has any information on this (goal), or is viewport performance expected to be the same throughout?

Source: https://wiki.blender.org/index.php/Dev:2.8/Source/Depsgraph

Main goal of dependency graph is to make sure scene data is properly updated after any change in a most efficient way. This means, dependency graph only updates what was dependent on the modified value and will not update anything which was not changed. This way artists always have the scene in a relevant state with maximum update frame rate possible.

It is impossible to predict what the impact of the viewport and depencency graph improvements is going to be on specific cases like yours. But if I remember correctly, the Blender Institute artists mentioned in a podcast that they hope it won’t be necessary anymore in 2.8 to animate with a proxy mesh, but to use the actual character mesh. I guess it is not unreasonable to look forward to improvements overall.

Mmmm…well, someone moved my post here.
I appreciate the reply, but to you (and the mod), I’m not asking about “modifiers”.

Unless the singular “armature” is going to get lumped in. I only specify that because that’s the biggest lag.

I’m asking about viewport/animation performance, and suggested depsgraph because it’s the only thing related that I’ve heard of.

My reply was not about modifiers, so it does not really change.

Developers should take a look of the competition so Blender don’t get left behind,

this automodeler from Max is insane for example: :eek:

http://www.scriptspot.com/3ds-max/plugins/automodeller-pro

A cool feature or plugin is never a reason to ignore basic functionality like modifiers.

I agree, developers should take a look at other software so that max does not get left behind…yes I said max.

…it’s plain stupid to copy what is already being done…that is the opposite of future proof and just asking to play catch up…the only way forward is innovation.

In what way modifiers in Blender will change? Will there be a possibility to write own modifier and choose it from modifier list like in max? This would be essential for and very versatile.
If not is there a forum where we can suggest additional modifiers.
For me Blender is missing this future at first (compared to 3ds max):
-Uvw modifier
-Symmetry,
-Sweep (very powerful)
Regards Martin

You have that tools actually in modifiers or other way.

I’m just making a guess here but custom modifiers in max are likely written by using c/c++ API so in a sense the same could already be done in blender simply by the very nature of blender being open source. People have been asking about python modifiers and the answer to that seems to be no - too unpractical.

The problem of that is that devs don’t have time to review, or they don’t want to add new modifier that need to be maintained or they don’t like the modifier, or think that it is not necessary… so people don’t write any modifier. You can see that in the last three years how many new modifier have you seen out of GSOC or main developers? zero?

that’s wrong. surface deform modifier was added recently and it is pretty useful :slight_smile:

No, I agree with DcV on this. Surface deform is more the exception than the rule at this point. There is another side to this however. The idea is to develop a small modifier that can be used along other modifiers in any order to solve multitude of different problems where most would likely want to develop a big monolithic modifier to solve a few very specialized problems. Those patches wont get included.

There is also a problem with number of included modifiers, but that is more of a UI/UX problem and can be solved easily enough by introducing 1 extra drop-down menu for node category.