Sorry about that. Now I have added documentation for those two commands to modeling/meshes/editing/normals
Tue, Jul 9
Wed, Jul 3
I looked at the screw modifier code, and noted that it had code to handle this properly -- it just has to be enabled by enabling the 'Calc order' option in the modifier. So this resolves the problem reported in this bug.
(There remains the similar problem with Extrude, but since that likely needs code like 'calc order' stuff in the screw modifier, which is a fairly extensive change, I will leave that as a future TODO.)
This is working as intended right now (except maybe a problem with clamp overlap -- see below), so I am closing this bug as invalid.
This is a problem with the screw modifier, not bevel.
Edges don't have normals, so this is not a matter of bevel somehow changing the normals of edges.
What does change is the ordering of the vertex indices. This should not matter to the screw modifier -- it should try to make consistent normals no matter what the ordering of the vertices, and it would be too hard a constraint on tools like bevel to try to maintain a consistent vertex ordering (because, for instance, two new vertices are created here), and in general, other tools and modifiers should be made to work despite the internal vertex index ordering.
I will note that a similar problem happens if instead of using a screw modifier, one does an extrude on this line of vertices after beveling a vertex in the middle.
Sun, Jun 30
It is a limitation that I don't know how to fix right now. I'm open to ideas. So this is the best I can do.
Sat, Jun 29
Yes, the custom normal tools need updating to handle multi-object editing. I'll see if I can do that.
Tue, Jun 18
Jun 14 2019
I confirm this. It appears that the mirror modifier is not properly copying the values of the custom split normals.
I will look into this.
Jun 12 2019
Jun 11 2019
Jun 1 2019
Campbell, your fix of putting
layout.operator_context = ‘INVOKE_DEFAULT'
in front of the rotate normals menu entry appears not to work (or at least, work well) when the menu is entered via the Mesh > Normals > Rotate Normals entry.
What happens is that the dotted line that joins the mouse to the cursor is not shown, and the mouse movement causes very limited change in the rotation angle, such that it is hard to even notice that the normals are being rotated.
May 30 2019
Is that something settable in the keymap editor? Haven't looked, but will. About to get on a plane for a vacation...
Campbell: When the "Rotate Normals" menu is selected from the Mesh > Normals submenu, it gets a context that has INVOKE in it whereas if it is selected via the same submenu when it pops up after hitting Alt-n (to which it is mapped), it gets a context that has EXEC in it.
This means that the operator is INVOKED when you select it from the header menu, but EXECED when you select it from the shortcutted popup menu. Is this intended? It means that the modal operation doesn't happen when selected from the Alt-n menu, rendering this particular operation useless.
May 29 2019
Yes, it is not just that the UI doesn't show the connection lines, but that in fact the Rotate option of the menu doesn't work at all -- I guess the modal operation finishes immediately. As a workaround until I fix this, you can use the r shortcut followed by n to rotate the selected normal(s). Or it also works to do an F3 search for Rotate Normals and select that.
But i will work on trying to get the menu method to work. Thanks for the report.
Sorry, there are way too many places in the bevel code where the face normals matter. Now that you bring this up, it is not clear to me that this is necessary, but at some point I thought it was. Since so much other stuff in Blender will not work well if the normals are wonky, it seems like a bit of a fools errand to make bevel work in this case when you are likely to have to fix this anyway later (when texturing & rendering). So for now I am calling the current bevel behavior "working as intended". I may consider trying to undo all the normal assumptions at some point in the future, but this is not an active bug right now.
May 28 2019
May 26 2019
I confirm this bug. Will work on it.
May 25 2019
May 22 2019
Thanks for the report. I will look into this soon.
May 21 2019
May 20 2019
I think that this task is complete for now. We should start a new task for a real tool in the toolbar for a 2.81 or later. Since such tools are typically interactive, some possibilities would be:
- the modal "point normals at" command (maybe with custom gizmo to help)
- the modal "rotate normals" command (currently pretty hidden under rotate transform with n typed afterwards)
- a new modal "set face strength" command, to let you select and set multiple faces' strengths in sequence; ideally combined with custom drawing to show which faces have which strength
- maybe a way to display the numeric values (vector) of selected normals (like a 'measureit' for normals)?
May 16 2019
Thanks Philipp for doing such a nice job of isolating the problem. I confirm this problem and am working on it,
May 15 2019
Currently the normals menu commands all have a poll that tests for autosmooth being on. That poll should be removed and the code should just test and turn it on if not already on when those menu items are invoked. I looked once at doing this automatically in the bevel modifier when harden normals was chosen but it was annoying to do because the bevel code is all in a file that only operates on BMesh and there is no autosmooth option recorded in BMesh that could be set and propagated back to the Mesh in the modifier code. This could be corrected, of course.
May 10 2019
One question about the idea of making the normal vector in the transform tools item panel be a live reflection of the current selection: this is a not-inexpensive operation (see BM_loop_normal_editdata_array_init in bmesh_mesh.c: it allocates several #loop-length things and iterates over all the loops of the mesh). Even if we only do this if there are custom normals, is there any concern about doing this every time a selection changes? I don't think so, but wonder what others think before going down this coding path.
May 8 2019
@William Reynish (billreynish) Yes, I can see that (the copy/paste buffer being elsewhere and hidden).
What were the thoughts about Add/Multiply? Dump them?
I agree with most of this, and have been working on it. With changes I made to the normal menu, I can now remove Face Strength from the Normals panel in Tool properties.
May 7 2019
Thanks for the fix. I will apply and commit this shortly.
May 1 2019
Apr 30 2019
This looks good now. I agree with you that the weight <=0 case cannot occur at that point in the code.
I've submitted these changes now, with rB3e780507bd6 .
Thanks for your help on this!
Apr 29 2019
Why did you move the weight transfer stuff for vertex_only down? It seems that it now moves it past the point where the BM_ELEM tags were needed and set/unset.
Apr 26 2019
This looks good. Thanks for doing this. The solution for what to do about 'width' seems like the best approximate solution to a somewhat undefined problem.
Apr 25 2019
One things that changes everywhere in the manual are the parts where it lists where various buttons and other UI live. E.g., most things that were on the tool shelf are listed as being on Panel Tool Shelf > Tools.
Apr 20 2019
This is somewhere between a bug and a feature request. The width type was intended for, and explained by, its effect on the amount an edge is beveled. But I can try to think of what to do for vertex. Seems reasonably clear for depth type but less clear for width type.
Apr 18 2019
I can't reproduce this. I've been updating bevel_regression.blend pretty regularly (last time Feb 11) and it passes for me.
This is what I do on MacOs:
(with Debug build)
build with lastest master
test with latest svn revision of tests
in the build directory run:
ctest -C Debug -R bevel
and it runs that bevel test and shows it passing.
Similarly if I "make test" on Linux.
Apr 15 2019
p.s., I realize that the stack trace in the intial report is during the heart of bevel. My crash happens much earlier, as the previous note said. Perhaps because it is a Debug build? My stack trace:
This happens at the very beginning of the bevel modifier's applyModifier function, before bevel actually does anything, when it is trying to do BKE_mesh_to_bmesh_ex() to convert the input into a BMesh. So I don't think this has anything to do with Bevel, but rather some kind of corruption in the input file or something gone wrong in the generic mesh to bmesh conversion procedure. I can look into this further but not right away. Is there someone better than me to look at this?
Apr 4 2019
Apr 3 2019
Apr 2 2019
The problem is not with bevel, really. It is that right-click to cancel extrude doesn't cancel it -- it just sets extrude amount to 0. So we end up with two faces on top connected with zero-length edges. This is not a situation for which bevel is intended to work well.
Apr 1 2019
This was not really releated to harden_normals, but rather that the algorithm used when loop slide was enabled could give different results from run-to-run. I fixed that.
Mar 22 2019
OK, I finally found time to look at this. Unfortunately, I am going to close this as "working as intended". The workaround cited above (turn off Loop Slide) should be satisfactory in cases like this.
I take it you are interested in making a proposal for the exporter idea for GSoC '19?
I will try this out soon. Am very interested in what the speed comparisons are so far with this vs Python export. Did you do any measurements of that yet?
Mar 21 2019
Improvements to the profile=1 case have fixed this, so closing this bug.
Rohan's GSoC fix did indeed fix this particular case and is now in master, so closing this bug.
Clearing out old bugs. Clamping is currently working as intended, even if not ideal. The long term fix is to actually have the geometry merge and/or otherwise do intelligent things when collision happens, and then remove 'Clamp' completely. I hope to get to that as my next big bevel improvement project, though it is some time off.
Closing this now that Bevel has a user editable keymap, so users can map spacebar to confirm if that's what they want.
Mar 19 2019
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.
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).
Mar 18 2019
Even though the behavior is surprising, even to me, I am closing this bug for now as "working as intended", since the semantics of vertex groups and weights being interpolated is indeed as intended. I will add a point in my general bevel improvements request bug, T48583, to eventually fix this.
Mar 17 2019
Added Campbell to get his opinion too on how to solve this problem with vertex groups being used for membership and interpolation.
OK, this was mysterious, but I understand the problem now. It is that vertex groups are getting mixed up in a way that is likely unexpected to users: there are weights associated with each vertex in a group and the bevel modifier considers each vertex to be part of the bevel if the weight is >= 0.5.
I confirm too for 2.8. Oddly, it only happens for the modifier, not the tool (oddly because the code for the core bevel is the same). And the second bevel doesn't have to have 0.5 width -- any width will show the problem as long as the first one had width 0.5. I will investigate further.
Mar 15 2019
Mar 8 2019
Mar 6 2019
I am not sure whether I did anything in particular to fix the mouse sensitivity to percent, but it seems fine to me. Maybe this also had to do with the scale issue that my commit did fix. If the original reporter of this bug thinks it is still not ok for percent, please give more details (a .blend, and details about what you did -- I'm assuming adjusting by mouse movement, but maybe that was a wrong assumption).
I fixed this with rB208fafb