- User Since
- May 1 2011, 2:06 PM (303 w, 2 d)
Jan 13 2017
I have looked a bit, and made a much simpler file that triggers the same assert: armcrash.blend
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
Jun 2 2016
Jun 1 2016
May 25 2016
May 4 2016
I have a fix for this completed but it creates a number of diffs in the regression test that I need to check out. Hopefully can close this out next week.
Apr 18 2016
Yeah, the reason it is taking so long to finish this is that making it work for the "region" case as opposed to the "individually" case is quite a lot harder. I haven't worked on this for a while because there's a crashing blender bug that also needed a complicated fix (almost done with that now, though).
My longer term desire is to incorporate the same algorithms I have in my inset add-on which detects when edges and faces collide / collapse and does the right thing. I've been working on a library that can be used for inset, but that is dragging and anyway it will be non-trivial to adapt to the bevel case.
Mar 23 2016
Sorry, no update. I've been too busy with my day job for the last couple of months. Hope to get back to this soon, though.
Mar 14 2016
I admit to not understanding the design parameters around making something usable on a tablet or with a pen, or a laptop with only a trackpad (which I often am using). I can see that the method proposed here (using motion of the pointing device with modifier keys to adjust different things) works, but like Bastien would like to see this as part of a coherent pattern of how to do things in Blender.
Feb 23 2016
Couldn't reproduce with build from master @ 62b3fdb on MacOSX 10.11.3, Graphics Intel Iris Pro
Feb 5 2016
Just updating this, now that I've investigated it some.
This turns out to expose a bug in the way I've implemented bevel:
in some places, it assumes that the faces around a vertex involved in a bevel all have consistent normal directions; this can't always be true. This shows up when reconstructing the faces that touch such vertices; and also in the calculation of the new bevel polygons.
Fixing this will take some thought and touches a number of places.
It is good that this report made me aware of these deficiencies -- thanks for the report.
Feb 2 2016
Looking. Somehow the bevel has created a face with a duplicate vert and a duplicate edge.
Feb 1 2016
I fixed problem (A) with commit 9fe70215a0a9ec58e338571c029a80a44b075d73.
I also changed the post-operator selection, but not to what you really want, sorry. It now selects all polys newly created, whereas I think you want only the inner ones. I could fix that, but it would take more work and, as I said, I am porting this functionality to C, where I am doing the selection properly.
Jan 28 2016
A) Yes, it is a bug that the original edges are not deleted. That seems like new behavior -- I'll look at it.
Dec 14 2015
Hmm, not sure what the Visual Studio compiler doesn't like about my inline function declaration. This code compiles ok on Mac and Linux. I'll try it on my Windows machine soon (maybe later today).
Dec 13 2015
This patch adds a library function BLI_polyinset3d to blenlib and uses it to do the main functionality of the 'Inset Face' (shortcut 'i') mesh modeling function (but for now, only when 'Individual' is checked in the panel; and it also doesn't work if 'Offset Relative' is checked). I will continue to work on this to handle the non-Individual case if this patch direction looks promising. When 'Fix Overlaps' is not checked, the functionality is meant to be the same as current. But when 'Fix Overlaps' is checked, the inset thickness is clamped to the point of first collision. Collisions happen in two ways during inset:
(1) two of the lines that go inward from the original vertices meet (and are about to cross)
(2) the inset of a reflex angle hits some other inset edge
The code handles these cases, when 'Fix Overlaps' is checked, by in the case of (1), making a vertex for the intersection point; and in the case of (2), splitting the inner polygon in two at the intersection point. And there are many edge cases where many vertices merge into one point and degenerate polygons need to be cleaned up. The code handles these edge cases.
As requested by Bastien, closing this task and redoing it as a differential, https://developer.blender.org/D1669
Eventually this could become a modifier too, and having seen how useful some people find the bevel modifier, I think it makes sense to make this a modifier too. But I prefer putting my energy into getting the collision-aware region functionality in first, and also get some user reaction on what options are needed etc. before doing the work to make it a modifier.
Dec 12 2015
I want to put in the functionality to continue after a collision, and there's one bug I know about that I'd like to fix. After I do that (should only be a day or so), I'll switch to using differential.
[The message the the differential page you linked to implied that this code was better suited to 'Patch task', because it is relatively big and I wanted to have some design discussion; that's why I put it here instead of making a differential diff in the first place.]
Dec 11 2015
Dec 10 2015
Sep 13 2015
Sep 12 2015
Sep 11 2015
Sep 7 2015
Thanks for diagnosing the problem and providing the test file Campbell.
But the fix was simpler. I was intending to use the nearest ("representative") face for each vertex individually in the no-seam case, and forgot to make the code do that.
Sep 3 2015
Aug 31 2015
As suspected, the issue was indeed the same one (line intersection in library said lines were collinear when they weren't), and this has been fixed by Campbells's commit rBe503e37333 .
I confirm that this fixes the bevel problem that was the initial subject of this bug report, so agree that the issue is Resolved.
Aug 28 2015
I'm pretty sure this is the same issue as in https://developer.blender.org/T45919
Thanks Tom for suggesting the possible cause of the problem. That is indeed the change that is causing the problem.
Aug 27 2015
P.S., What I had intended was that one could get the old unrestricted width adjustment path by turning on the 'clamp overlap' option, and indeed that does make for an even bevel here. The problem is that the clamp stops the beveling at a fairly small value and I don't understand why (well, I have a suspicion). Will have to also investigate that.
I can confirm. For reference, here is a model built according to Dave's instructions:
Aug 20 2015
Well, this was a deliberate change, based on strong feedback from users that Blender's bevel should act more like what other 3d software does.
I may eventually add more options for rounding around corners, but for now I'm calling this working as intended, sorry.
Aug 18 2015
I think this may be the kick I need to look at putting my self-intersection-handling code into the hardcoded C inset, and retiring my add-on. I will start to work on this task (but it won't be a quick fix).
Aug 16 2015
Note that I gave up trying to make an algorithm that works well in all cases. I could fix the bug in this report by clamping the amount of width adjustment in the global width adjustment path; but that made one of the regression tests look bad.