Someone else requested something similar to what you suggest -- just that when some vertices get blocked, they stay there and the unblocked ones continue to move. Maybe this should be the default, but I'd like to get some kind of consensus from artists before changing. As you say, it could be an option, but there is a lot of pushback on Blender devs from Ton not to add too many options to tools, but rather make them smart enough to "do the right thing" without options.

Sorry it took so long to fix. Thanks for the report. It is fixed in the blender-addons-contrib repository.

The problem is that the clamping is very naive right now: just clamps to the min of the half-length of all the edges involved in a vertex bevel. In this case, that means it clamps to the half length of the vertical edge, which doesn't even have advancing vertices on it, and it is a lot shorter than the edge that the vertices move along. It is a TODO to do much smarter clamping, but I'll spend some time now to see if cases like this, at least, can be improved.

This is different from T50994, as it is only about one edge (as reporter notes). It may overlap with one of the problems reported in T50819, premature clamping. I will look into this one now.

Another requested bevel clamping change. See T50994. Requester would like clamp to apply to edges individually rather than globally. Could be consider as breaking backward compatibility for 2.8. Or an option (but we dislike adding too many options).

Sorry, the behavior mentioned here in this bug (T50994) is the intended behavior. The clamp that is calculated is a GLOBAL clamp for the offset amount, calculated as the minimum amount that might cause overlap (approximately -- doing it exactly is hard, and a TODO). The reason for this is so that the bevel looks uniform when done -- that is, the widths all look about the same. In some artistic contexts, it could look strange to have some edges beveled a lot and some edges beveled a little (e.g., you might want all edges of a table beveled approximately the same).

What is the status of this patch? Is it likely to get applied in the 2.8 branch any time soon? Since a GSoC 2017 student that I am mentoring is also doing Vertex Paint improvements, it would be a pity not to be able to build on top of this.

Hi Matthias,

I could not get it to crash with my vs2017 release or debug builds. I did try the buildbot 2015/x64/release build, and it crashed, but I don't know how to get a symbol file for this so couldn't get a meaningful stack trace. I have a strong suspicion that the problem now is not with bevel, but somewhere else.

Thanks. Do you have a stack backtrace? At any rate, I will try with VS2017 which I have at home and see what happens with that.

I cannot reproduce a crash. Maybe I don't have all the same build settings. Can someone who gets a crash paste a stack backtrace? I am wondering if the crash is still in bevel, or whether it is somewhere else now.

Hmm. Can you see if the code you compiled includes commit rB8be9d68dd42d ? (git log in the blender source directory should show it).

Fixed this now. Sorry for the long delay. Fixed in master; the 2.8 branch should update in a day or two when merge from 2.78 to 2.8 happens.

Looking at this again now. For reference, here's a simpler file that causes the assert failure (in mesh_vert_canon):

Yes, it is not good that three of the four seemingly identical bevels have straight profiles while the 4th has curved profiles. I need to look into why.

Thanks for the thoughtful suggestions.

Sorry, I haven't had a chance to look into this yet. The code that prevents overlap is (the 'clamp overlap' option) is only approximately right, since getting it really right is quite hard. But I agree it seems to be failing completely in the case of selecting a whole loop, and hopefully it will be easy to figure out why and correct it.

I have looked a bit, and made a much simpler file that triggers the same assert:

Thanks for the file. I tried importing it, and it did not crash.
Can you please tell me the version of the pdf importer that you have on your computer?
Under binary directory where blender lives, there should be a file like
2.77/scripts/addons_contrib/io_vector/__init__.py

This was a known problem, and there was a known workaround (enable 'clamp overlap'); I made that workaround kick in automatically in clearly problematic cases, like this one.

I'm sorry, I cannot reproduce this problem without a sample .blend file. Please upload the .blend file with the two modifiers, and I will look at it.
I suspect what is happening is that the "clamp overlap" is reducing the width you desire, but that is only a guess without seeing sample .blend file.
Also, is the last picture supposed to be the desired result? If so, could you supply that .blend file too?

Without an example file where this crash happens, I can't fix it. What kind of rights error do you get when trying to add a file? I see that you have been successful uploading files in other bug reports; e.g., T50276

We write our tools under the assumption that the meshes are 'valid'. (If you run the python command mesh.validate(True) it can tell you whether the mesh is valid or not. Rather than try to put all sorts of protective code in all the tools, our policy is to instead make sure no tools produce invalid meshes. At any rate, even if Blender didn't crash, most tools could produce crap results on invalid meshes. Clearly some tool has produced your corrupt mesh -- in the example .blend file that you uploaded -- but without help understanding how that mesh was produced, I'm afraid there's nothing more than can be done here.
Closing this bug, but feel free to open a new bug or reopen this if you can reproduce the mesh corruption (that is, can provide an uncorrupted model and instructions for a next step that causes corruption).
Thanks anyway for the report.

Looking at this now. It seems that the mesh in the test file violates the assumed invariants about BMeshes. If you start blender with --debug, and then toggle into Edit mode, the validation code reports that a particular face has a duplicate vertex and a duplicate edge.

I can confirm this. Will work on fixing it now.

I confirm that this happened in the version of blender cited (commit 3e460b6), but at the latest revision of 2.78 (bd5ae46c) the crash does not happen. I am closing this one. Feel free to reopen if the crash still happens for you. There is another bevel crash bug task that I am going to look at now, so I am not discounting that there may be a bug to fix here. Going to look at that other task now.

Hope to get to this soon.

I suspect this might be similar or the same as the problem in T49467, which I haven't had time to fix yet. I should have time to look at this soon - not next week, but the week after.

The problem appears to be not with a change in the pdf/svg/ai importer (which still works on my test pdf files), but rather that your file uses a PDF feature called 'Cross Reference Streams' (introduced in PDF 1.5) that I did not program for.

I confirm the problem, and will look into it.

OK, I understand now.
Yes, it is a limitation of using Vertex Groups that you cannot precisely specify which edges you want to include. Because, as I explained earlier, all edges that have both ends in the vertex group will be beveled, and for the simple unsubdivided cube case, you cannot select all the vertices and yet only have a subset of the edges beveled. This is a case where it would be good if Blender also had Edge Groups, but it does not. Using Vertex groups to specify edges to bevel was an imperfect workaround to not having edge groups.

I don't understand what behavior you are expected. The example file looks working as expected to me. When you specify "Vertex Group" as the selection method in the Bevel Modifier it works as follows:

• all the given vertices are selected, and then those induce certain edges to be selected (the ones with selected vertices at both ends)
• those edges are beveled

Yes, it is triggering a "shouldn't happen" assert in Bevel. I fixed a similar problem to this recently. Will try to fix this soon.

Another feature request (from bf-funboard mailing list): a different number of segments for preview vs render.

Another feature request: see T49173. The desire is to get inward curving profiles for vertex bevels on convex corners. E.g.

I call this a feature request, not a bug, since the current behavior is working as designed (though not, as this bug shows, as some users would like). Others have asked for this. While it may seem clear what to do in a case as shown (convex corner of a polyhedron), other cases are not so clear. For instance, what to do if the vertex is in a plane? I can see some users preferring the inward curving edges as you request here; some might prefer outward curving ones (to make a kind of circular shape), while still others may prefer the current flat straight line behavior.

Yes, I can fix by initializing BevelData.segments. But I think there is indeed something more to fix here, so I'm not going to close this yet, but I will commit an immediate fix to the uninitialized problem (and the problem of + not having an effect).

Thanks for the report. This is fixed now.

Thanks for the report. This is fixed now.

Unrelated to the strange shading, there is definitely something strange going on with bevel here. Maybe some strange geometry (though I did check for doubles, and there are no doubled vertices at least). I need to find some time to investigate further. Unfortunately, I don't have time right at this instant.

This seems to be a new bevel problem. I will try to fix it soon.

I confirm too. Will have a look soon.

This looks like a bug I want to fix, so we'll leave this report open and I will fix the bug. Glad there's a workaround for now.

With commit rB520691e5912d2eec you can now control segments with mouse after S toggle. And I fixed the problem with resuming changing offset at the last point you left off, after changing segments or profile with the mouse. And I added the ability to set the segments or profile with numeric input when you are in the P or S mode, respectively.

Good idea. I will do that too, I think.

Ah, good point about maintaining the existing width even if the mouse moves to a different place during profile adjustment. I will fix this.

Cédric: yes, it is possible. The 4th bullet point of this design task "more options ..." is intended to explore this. In particular, the "with setbacks" part of that statement would address what you want here, I think.

Cédric: OK, I commited (with commit rBc8e9e6dda0f9) a change to have the P key toggle in and out of 'adjust profile' mode. I decided to use P rather the Ctrl since Ctrl-B enters bevel and maybe people could continue to hold Ctrl. (Maybe not. At any rate, the P key works and has a good mnemonic meaning.) The Shift key decreases the speed, as suggested (and as it does for decreasing speed of offset adjustment, in normal modal use).

Cédric: do you have a suggestion for how to control the profile during modal? I guess maybe some hotkey to hold down to make the mouse movement affect the profile rather than the offset? Any suggestion for which key, if so?

A "Harden Normals" Option

Better handling of profile = 1, profile = 0.25, and implement profile = 0 cases