- User Since
- May 1 2011, 2:06 PM (407 w, 5 d)
I will fix this by splitting, which will also make it possible to do units right (have already done this splitting in the modifier).
Wed, Feb 20
The merged-in T61709 is a somewhat different problem, but I'll address it as part of this task. In that task, it is just doing an outright wrong UV assignment in the supplied example.
Tue, Feb 19
Sat, Feb 16
Yes, this is for me to fix. I wasn't quite sure of what the 'release confirms' was for, but now I do.
Fri, Feb 15
I found and fixed the problem with the cylinder, with commit rBdd97b09fa8d5 ,
Thu, Feb 14
OK, now I see the problem you are talking about and agree that it isn't what I thought (that you just wanted automatic merging of the verts). I suspect that the problem with the cylinder is that the method I use to calculate the vertex positions is numerically sensitive and misbehaving due to using floats instead of double precision. I will see if that is so, and if so, whether or not I can rearrange the calculation somehow to fix.
Tue, Feb 12
I confirm this and will fix it. Thanks for the report.
Mon, Feb 11
Sun, Feb 10
Fri, Feb 8
Thu, Feb 7
Tue, Feb 5
This is just the way bevel works right now, so you are asking for a new feature.
I could solve this by running a 'remove doubles' automatically after doing bevel, and some have asked for that in the past. But I worry about doing that everywhere on the model as it may merge things that the user didn't intend to get merged.
For now, the workaround for you as a user is to do a 'removed doubles' manually after a bevel like this.
Tue, Jan 29
Mon, Jan 28
Yes, these are limitations of the current algorithm.
Jan 20 2019
Jan 19 2019
Jan 18 2019
Jan 11 2019
Thanks for the patch aiming to improve bevel functionality.
Jan 8 2019
That's a nice idea, Jacques! I could easily implement that, and think I will. Thanks for the suggestion.
This is "working as intended" in that the code doesn't try to be consistent here, and this isn't a regression. It is more like a feature request to come up with a consistency rule.
Jan 7 2019
I fixed this as Brecht suggested, using a separate property for the percentage width offset type.
Jan 4 2019
Jan 3 2019
Dec 21 2018
Dec 20 2018
This fix looks good to me. Can you commit it, or shall I?
Dec 8 2018
Dec 6 2018
Yes, I see the problem. You can work around it by turning off the 'Loop Slide' option.
There's some complicated optimization that goes on to try to even out the loops when loop slide is on, and looks like there might be a bug in that.
Dec 5 2018
Yes, you are correct. I guess the previous CL that I thought fixed things just moved the problem around.
I'll continue to look into this.
This is similar to, probably the same as, the issue discussed in T47129.
Looks like the template has to change to create & copy the CD_BWEIGHT custom data layer. I will look into this.
Dec 4 2018
I put this in my draw_cache_impl_mesh.c so that I could turn on #define of USE_BM_MAPPED_LOOPNORMAL and get it to use custom loop normals properly in display.
Dec 3 2018
Campbell, your recent commit rBff3601b9 seems to have broken some of the code that was written to fix this, or maybe just broke the code that fetches and uses custom normals in shading. Now when autosmooth is on it doesn't seem like the workbench display uses custom normals at all (e.g., trying to modify them with the mesh -> normals -> point normals to target command, using m for mouse -- nothing happens now).
Yes, this seems to have been fixed by commit rB18f0618677 (found by bisecting commits). I'll close this bug.
Dec 2 2018
The main bug (#1) is fixed now, but still have to fix the problem where the bevel operator run from Python cannot harden normals,
Nov 30 2018
Somehow the memory allocator data structures got corrupted so that it returned the same value for both the edge pool and the loop pool allocations (!).
I'll have to did deeper to understand which code is doing the corrupting. I tried Valgrind, but no luck.
The problem is that the BKE_mesh_to_bmesh_ex() appears not to have created a bm->epool with the BLI_MEMPOOL_ALLOW_ITER flag set. I'll dig into why...
Nov 28 2018
The proper thing to do is to share the normal hardening code by putting it in BM_mesh_bevel(), rather than the current strange mix of having some of the work done in that function but most of it done (separately implemented) in the modifier and in the editmesh code that runs after the BMOp bevel runs.
OK, so the crash was because one also needs to do a bmesh.update_edit_mesh(C.object.data) after running the above commands, and it is documented that one needs to do so. It all seems to work fine (though without hardening normals, if that is specified in the arguments) now.
does what is required to prevent the crash and have the new mesh properly displayed.
Crash is an assert in GPU_indexbuf_add_generic_vert, where it is trying to add a vertex to an index buffer that isn't big enough.
Nov 27 2018
The immediate problem was that no verts were in the input geometry, and code assumed that if edges were there then verts were there. The code in the second update added the verts. But I fixed the code to add the verts from all edges explicitly so that this would no longer be necessary.
Nov 16 2018
Indeed, it was a type for Loop variable. Thanks. Fixed now.
I too confirm the crash and will work on fixing it.
Nov 8 2018
This needs to be corrected in the documentation. I will do so.
Nov 7 2018
Nov 5 2018
I'm not sure if this should be assigned to Clement, Campbell, or someone else. Also not sure if this is a bug that is intended to be fixed before the beta.
Oct 29 2018
Thanks for bug and example. I will look at how to fix this.
As mentor for this project, and general Bevel maintainer, I will do this documentation, so you can assign this task to me.
If I understand correctly, 2.8 docs are not yet being committed. If that is right, where should I (right now) write/save the docs that I do for this task?
Oct 27 2018
Sep 13 2018
You are not being a nuisance. I appreciate hearing about the real-world problems people have. This is unfortunately another example of the harder part of your original report -- getting a more global consistency. I have a vague idea of some rules that might help, but have to think through some more.
Sep 7 2018
Thanks for the gif. It helps confirm that I understood what was bothering you, and what would make you happy (or, happier). And it should be easier to fix that than to produce exactly your ideal results.
I've looked at this some now.
There is no quick, easy fix. So this will take some thinking.
The problem is that we have to decide which side of a seam to put the bevel parts on. In the provided example, the side has been chosen consistently so that there is pleasing overall symmetry. I need to see if I can think of an algorithm that has that effect.
In addition, there are the triangular corners that now get mapped to go only halfway across their adjacent edges. I'm not sure why that is. Needs more debugging. Bug also not clear if just having them extend all the way across the adjacent edge would satisfy the bug reporter.
Aug 31 2018
Thanks for the report. Will look at fixing this problem soon,
Aug 22 2018
Aug 15 2018
After talking with Campbell, have decided to close this one for now. If we can reproduce that second issue in 2.8, then can reopen with a repeatable test case (using script or knife project).
There are two things going on here and I am not sure which you are trying to report.
Aug 13 2018
Aug 9 2018
Jun 15 2018
May 29 2018
May 25 2018
May 14 2018
As a further note, this problem also appears to be in the 2.8 branch (using F6 to bring up tool settings after an initial bevel with control-B, and trying to change segments, on the example pp.blend file).