- 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?
Would like to see practical use cases for this.
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?
Thu, Mar 21
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.
Wed, Mar 20
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.
Tue, Mar 19
Any news about this patch?
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:
I added the image to the right click select post too, please let me know if it is not ok here, thanks!
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.
Mon, Mar 18
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.
If this is used in animations the tri to quad conversion will 'pop' on deformation.
Sat, Mar 16
Fri, Mar 15
same happens with no ngons
Just insert the subdiv. on this model ( low poly )
Wed, Mar 13
Sat, Mar 2
Thu, Feb 28
Wed, Feb 27
I see. Thanks for the explanation. Then I don't think there is much to do here in this regard either.
@Sebastian Parborg (zeddb), i would not consider difference in behavior a bug, and would not expose that option. The drawbacks are much more serious than one might think:
The issue here is that the new subdiv code uses the limit surface (the surface of the cube is you subdivide it an infinite amount of times) to place the verts.
Tue, Feb 26
I believe that export, operator and modifier all share the same base code. I'll get the modifier working first and we can go from there.