- User Since
- May 1 2011, 2:06 PM (325 w, 3 d)
Mon, Jul 24
Fri, Jun 30
Jun 7 2017
May 31 2017
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.
May 30 2017
Sorry it took so long to fix. Thanks for the report. It is fixed in the blender-addons-contrib repository.
May 29 2017
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.
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).
May 28 2017
May 27 2017
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.
May 25 2017
May 23 2017
May 18 2017
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.
May 17 2017
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.
May 16 2017
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.
May 14 2017
Looking at this again now. For reference, here's a simpler file that causes the assert failure (in mesh_vert_canon):
Mar 11 2017
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.
Mar 7 2017
Mar 6 2017
Thanks for the thoughtful suggestions.
Feb 28 2017
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.
Jan 13 2017
I have looked a bit, and made a much simpler file that triggers the same assert:
It seems to have something to do with the geometry being small, too, as scaling the object up and applying scale makes the problem go away.
Will try to find time to look at this next week.
The bug reporter might want to try loading the file I just uploaded to see if it crashes Blender on their build -- that is, try to see if this assert failure indicates that bevel is the cause of the crash, or whether this is a harmless problem with bevel and the real crash is caused by something else.
Jan 11 2017
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
Dec 28 2016
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?
Dec 21 2016
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
Dec 14 2016
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.
Dec 8 2016
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.
Dec 6 2016
Nov 29 2016
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.
Nov 28 2016
Nov 18 2016
Hope to get to this soon.
Oct 16 2016
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.
Oct 6 2016
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.
Oct 5 2016
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.
Oct 4 2016
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
Sep 28 2016
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.
Sep 12 2016
Sep 7 2016
Another feature request (from bf-funboard mailing list): a different number of segments for preview vs render.
Aug 29 2016
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).
Aug 17 2016
Thanks for the report. This is fixed now.
Thanks for the report. This is fixed now.
Aug 2 2016
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.
Jul 21 2016
Jul 15 2016
I confirm too. Will have a look soon.
Jun 21 2016
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.
Jun 17 2016
Jun 13 2016
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.
Jun 8 2016
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.
Jun 6 2016
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?
Jun 5 2016
A "Harden Normals" Option
Jun 3 2016
Better handling of profile = 1, profile = 0.25, and implement profile = 0 cases