@Andrew Zhou (dodeqaa) for every constructive modifier it's currently converting all data to BMesh and back - even if all of the modifier's in the stack operate on BMesh data types.

In D4530#104032, @Campbell Barton (campbellbarton) wrote:

Before getting into code review or looking into details I'd like to see example uses cases for this modifier.

Otherwise we could:

• Postpone until nodal modifiers are supported.
• Make this an optional post-process for the decimate modifier.

---

All BMesh operators _could_ be made into modifiers, however the modifier system isn't designed for constructive modelling (at least not with many fine grained operations).

Hi to All:

Modifier nodes are planned, I'd rather postpone this modifier until the new system is implemented.

In D4530#104032, @Campbell Barton (campbellbarton) wrote:

Before getting into code review or looking into details I'd like to see example uses cases for this modifier.

Otherwise we could:

• Postpone until nodal modifiers are supported.
• Make this an optional post-process for the decimate modifier.

---

All BMesh operators _could_ be made into modifiers, however the modifier system isn't designed for constructive modelling (at least not with many fine grained operations).

Apparently just broken recently, bisecting... (assume rB64c8d72ef1a?)
good rBb936d
bad rB17c15

Can confirm.

Afaics you dont really have a deforming modifier preceeding the cloth modifier.
So you would have to make sure e.g. the skirt is deformed first, then cloth sim will work correctly after.
Since we dont have the original armature for the character at hand anymore [everything has been baked to mdd], we need a relationship between the mdd cache and the skirt.

Or maybe it is possible to force to go in object mode before rendering

This concerns only cycles.

This has been reported before, the issue is curve scan-fill creates zero area faces that give bad normals for solidify to operate on.

Can confirm the issue.

Before getting into code review or looking into details I'd like to see more example uses cases for this modifier.

• fix compilation issue with collada and alembic

removing merge conflicts from recent commit to triangulate modifier

• add vertex group support

@Brecht Van Lommel (brecht), should this be merged, or do we come back to this patch when Blender 2.8 is released?

In D4530#103737, @Nabil Adel (mywa880) wrote:

How feasible is it to add a tick box to stop re-evaluating the base
mesh after the evaluated mesh has been generated and cached,
that way the modifier can still work with animation without beeing applied?

In D4530#103731, @Adam Friesen (ace_dragon) wrote:

In D4530#102964, @Campbell Barton (campbellbarton) wrote:

If this is used in animations the tri to quad conversion will 'pop' on deformation.

Can you point to where this was requested? Were example use cases given?

Why does it have to be useful in animation, why can't we users have more ways to just model various pieces of content non-destructively (like a remove-doubles modifier which would be useful with boolean operations)?

How feasible is it to add a tick box to stop re-evaluating the base
mesh after the evaluated mesh has been generated and cached,
that way the modifier can still work with animation without beeing applied?

In D4530#102964, @Campbell Barton (campbellbarton) wrote:

If this is used in animations the tri to quad conversion will 'pop' on deformation.

Can you point to where this was requested? Were example use cases given?

Yes, this is indeed a chicken & egg issue (and yes, it also happens in 2.7x). Guess we can close that as known limitation for now, then.

But same happens in 2.7?
This sounds like a feedback loop between rigid body simulation which needs geometry for the collisions, but geometry needs transform for modifier stack. While we can avoid some dependency cycles here, the order of updates might be wrong from users perspective. And the only user-controllable solution here would be to go node based.

Deg warning about DEG_OB_COMP_GEOMETRY relation is now fixed, but the rigid body simulation remains completely broken in 2.8 currently here (neither of the two displace modifiers work, only really moving red object works currently).

Using an empty (or center point of any object) is a valid usecase of this modifier, will check on those relations tagging.

The issue in code i saw was related on a fake dependency cycle, which is now fixed in rB099a4104788.
Now i can open the file and there is a playback going on.

Any news about this patch?

In D4530#103129, @cédric lepiller (pitiwazou) wrote:

Or the triangulate on Ngons, this is just an option to add to the triangulate modifier and it would help a lot!!!!!!

In D4530#102964, @Campbell Barton (campbellbarton) wrote:

If this is used in animations the tri to quad conversion will 'pop' on deformation.

Hi, It would be very useful for me to have the vertex group or any other way, to affect bevel size per vertice, something like this:

Thank you,
that is sad for me unfortunately since there is no other way to do this in blender without just working on geometry and loosing editability :( this was a great feature for me, on this project and other stuff ive used it before (RIP).

Sorry, I am closing this as "working as intended" because the code is doing what I intended: that is, it is choosing to keep widths even along their edges as a higher priority than trying to half-way meet an unmeetable set of width constraints.

+1 Great work... I hope to see this make the cut.

The behavior in 2.79 is not really intended -- it is more an accidental consequence of a choice made to solve conflicting specifications.
What the specifications say is that one edge is supposed to have one particular bevel width all the way along it, and the other edge (with the adjusting weight) is supposed to have another weight all the way along it. Where they meet is a conflict. The conflict used to be solved by taking an average, which gave the smooth tapering effect you saw. But for other cases (especially when there are loops) that is not nearly good enough, so I switched to using a least-squares optimization some time in the 2.79 series (I see that you note that this was working for a while in 2.79 and then stopped working, so maybe that was when I made this switch).

I can reproduce the difference in behavior here.

In D4530#102964, @Campbell Barton (campbellbarton) wrote:

If this is used in animations the tri to quad conversion will 'pop' on deformation.

Can you point to where this was requested? Were example use cases given?

In D4530#102964, @Campbell Barton (campbellbarton) wrote:

If this is used in animations the tri to quad conversion will 'pop' on deformation.

Can you point to where this was requested? Were example use cases given?

Thank you Ish for your hard work!

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.