Page MenuHome

Wrong bevel on ngon with hole
Closed, ArchivedPublic


System Information
Windows 7 64 - GTI 660

Blender Version
2.69 10f4c62

Short description of error

The bevel modifier have problems on ngon with holes made by boolean operations : if the edge linking the hole to the boundary of the ngon is too close to the hole boundary, then a bad bevel is produced.
To solve this problem, try to get the boolean modifier to create this kind of linking edge between the two closests vertices between the boundary of the ngon and the boundary of its hole.

Exact steps for others to reproduce the error

Create a boolean with a cylinder inside a cube, and add bevel, see attached blend file{F79131}



Event Timeline

Alexandre Labedade (Alesk) created this task.
Alexandre Labedade (Alesk) raised the priority of this task from to Needs Triage by Developer.
Bastien Montagne (mont29) renamed this task from Wrong bevel on ngon with hole after a boolean difference to Wrong bevel on ngon with hole.Feb 27 2014, 7:54 PM
Bastien Montagne (mont29) triaged this task as Confirmed, Medium priority.

In fact, boolean are not implied… I could reproduce a wrong result with a mere cube with a square hole in ones of its faces, see

. Howard, that’s another one for you.

Yes, it's not a "boolean specific" problem. But if we want to keep the modifiers stack unapplied, we have no solution to fix the edge resulting of the boolean operation...
so if the boolean modifier generate directly a well placed edge, it will solve the problem in this specific case ;)

I confirm this is a bevel bug and will work on it now.

Commit rB1582dd534d7c is a partial fix. It fixes the bevel_bug.blend file from mont29. The original boolean model case still has a problem.

Really, one shouldn't try to bevel those edges that connect the holes to the outside, since they form reflex angles with hole edges and that means that it is impossible to offset on both sides of the line -- distortion will be introduced.

I'll leave this bug open until I can fix the original problem.

Yeah... That's why I suggested to modify the boolean modifier in the first place ;)

Since this edge is generated on the fly by the boolean modifier, the user has no option but apply the modifier to access it and disable the bevel on it.
But if the user wants to keep the boolean modifier, and stack the bevel modifier just after, there is no solution... except having the boolean modifier to provide well positionned edges when a hole is present.

Well the 'angle' limiter on the bevel modifier should exclude the undesired edges from being used; but the result of using it in this case is a bit strange, so something else for me to look into.

Yep, the angle limiter could be a good (and simple) solution... Have fun fixing the wrong result ;)

Some updates on this.
First, the case of 'all edges beveled' on the boolean model is 'working as intended' except that we need much better 'clamping' code that detects more cases where the specified amount of bevel causes the construction to cross other edges of the polygon it is in. Here we have a very small angle and one wants to offset inside it, so the only way to do that is put the start point of the offset far out, where the edges have diverged enough.
Second, the problem with turning on the angle limit is that, even when the connector edge is removed from beveling, the current method of placing an offset point when there is an unbeveled edge between two beveled edges is to move the point along the unbeveled edge. The reason is to try to preserve the shape and angles that the unbeveled edges make (sometimes users want that), but in this case it would be better to ignore that desire and just move point to where the offsets meet.

I don't think I can fix either of these with sufficient testing that it hasn't messed something else up, in time for the 2.70 release. The proper clamping will take a fair amount of code. The other thing may need another option (not sure yet) and too late in the release cycle to add anything affecting UI messages, even if I did know exactly what I wanted here.

Howard Trickey (howardt) closed this task as Archived.Aug 26 2014, 2:01 PM

Closing this for now and moving to the wiki TODO list. Writing better clamping code is a significant effort.

Better clamping code is now in, and the original model in this report is now OK.