MACHIN3 has been working on a really nice bevel after boolean workflow…maybe you guys can combine forces to make this happen in the modifier.
6 Likes
Hi there @Howard_Trickey , I appreciate the hard work you are doing on Blender!
Concerning the Bevel topic I was wondering if there will be a QUAD Chamfer/bevel improvement for insets and extrusions. Currently they give an un-desired shading effect not suitable for Game Art normal maps.
Currently there is a workaround using MESHMachine script but its only a band-aid fix and destructive in nature (have to collapse the bevel modifier first).
Desired Bevel
1 Like
(sorry for double post but it wouldn’t allow me to post 2 images in 1 post)
Current Bevel
1 Like
I can’t predict when, but yes, there will be such an improvement in the built-in bevel with respect to toplogy oprions at vertices. This is now clearly the top requested feature, or maybe it is tied with having bevel “dp the right thing” when overlap occurs (but that’s rather harder to fix, in the general case). I am aware of the various addons that do some of this and will use them for inspiration, but would like to come up with solutions that work in the general case, and pay attention to the hard-to-get right things like what happens to the UV maps, edge data, etc.
16 Likes
If you take a look at this video, it shows a sphere with a chunk booleaned out. The mesh has hard edges where the boolean subtracted and has custom normals to fix shading issues as a result of triangles, ngons and uneven polygon density.
The problem is, the bevel modifier will mess up the custom normals. The only fix right now is to apply the bevel and fix the normals again manualy, on the mesh level.
And so I was wondering if it would be possible for the Bevel mod to use the existing custom normals, if there are any. This would be a live saver and add a lot of flexibility.
Grab the blend file from here. Thanks or your awesome work Howard!
8 Likes
I will look at this. But first I am working on the bug reported above by cgslav.
6 Likes
This, would be amazing for gamedev creation. 50% of my projects nowdays rely on weighted normals (then just normal decals) and being able to keep bevel modifier and still be able to tweak weighted normals would be amazing. Preferably with a value of 1-100 (like the 2.8 normal weight modifier). Or a simpler version like the y.a.v.n.e pluggin where its just a weak/medium/strong value.
There is no reason for that. You don’t want anything less than 100% of the previous, custom defined normals. It’s not about weighting face areas to influence the normal generation, just take the existing ones and set the normals at the bevel periphery accordingly.
1 Like
Hi Howard, thanks for your work, it already already looks amazing !
im not sure it has been mentioned but the bevel behaves a little odd with the mirror.
In 2.79 you could mirror and also bevel in a stack. with mirror first.
In 2.8 it has a stack order issue. If the mirror is first (which helps further booleans connect) there is an issue with the bevel showing up on weight.
I love all the suggestions here so far. If any of these get added the modelling would be light years ahead.
2 Likes
Thanks, mx2. It seems that the mirror modifier in 2.8 does not properly propagate edge bevel weights. There was a big change internally for modifiers, getting rid of the concept of “derived mesh”, and I suspect that that is the reason for this oversight. I hope I can find time to look into this.
2 Likes
Hello, I have always wondered, is it possible to add a “Smart Clamp” check box? So rather than allowing one overlapping vert from stopping the entire bevel, it would instead detect and clamp only that one individual vert, so that way the bevel width can continue while preserving a clean mesh. I’m sure it would be expensive on the CPU when more and more overlapping verts add up, but that would still be something I think generally everyone would find worth the wait.
10 Likes
This would be possible (it would require me to change the code somewhat to keep a per-edge clamp value, rather than the global one I calculate now). One issue I foresee, though, is that if you go all the way to a clamp value then you get zero-length edges, which is not a “clean mesh”. A subsequent “remove doubles” might fix things, but no guarantee. And anyway, clamping anywhere means that there will be beveled edges that are not the bevel width the user really wants, so this isn’t really the right solution. The right solution is to actually change the geometry as the beveled edges sweep over vertices. But this is pretty hard, so I haven’t done it yet.
2 Likes
While I agree it would be better to solve it right, I have to say that I personally turn clamp off very often and honestly, in like 90% of cases the problematic spot isn’t visible (which is the reason why I turn clamp off).
Nathan’s solution would work great I think and I’m surprised I never thought about it. It’s not really about bevel width not being correct but more like bevel width being 90% correct and in the rest of cases at least not creating intersecting mesh or infinite spikes.
If remove doubles is implemented can it be made to really do it only locally on the 2 (or more) beveled vertices and not everywhere? Very often the mesh is split and some vertices share location so doing it globally might cause issues.
Writing all this and thinking about 10k meshes I fear the speed will suffer greatly…
1 Like
Thanks and it actually might not be as CPU intensive as I originally thought since each vert clamped is one less path to calculate, so potentially it could even optimize the bevel modifier. If it turned out to be the worse case scenario it would still be faster than manual, not to mention a 90% fix is typically good enough for 90% of people (especially beginners).
There would be very little effect on CPU time – essentially none – if we were to clamp per-edge.
5 Likes
Well that’s awesome, I imagine the amount of time that would save people would be huge. Though I’m sure coding something like that would also be really time consuming, but still it is fun to imagine, thanks for the info!
cgslav, I just committed a fix to this bevel modifier with hardened normals bug that you reported on Oct 9. Sorry it took so long to fix. Thanks for telling me about it!
11 Likes
I am looking at some buggy behavior with the harden-normals mode for bevel (both the modifier and the tool) as currently implemented in 2.8. And I realize that I don’t know exactly what it should do. I’d like some user input. Consider this diagram:
Now if a user wants to “harden normals”, I believe this means that the “per-vertex-face-normals” (aka “Loop normals”) at a, b, c, d, e, f need to be set according to some rule that in general leaves the big faces like A as looking flat at the junction between those faces and the newly-created bevel geometry. But this leaves some questions about what happens elsewhere in the model.
Here’s what I think the new per-vertex-face-normals should be; in some cases, there are questions. These all assume that the normals have all been “split” so that there are custom normals for each face/vertex pair. (If this isn’t true already, the harden-normal option should cause that as a side effect, do people agree?)
a - pre-existing custom normal (probably A’s face normal, but user might have edited it – if the whole object was desired to be smoothed then it may be the vertex normal at vertex a)
b - pre-existing custom normal? or A’s face normal? or (some kind of) average normal between A and bottom face if pre-existing custom normal was the vertex normal for the original front lower cube vertex? My best guess: if pre-existing custom normal is not A’s face normal then angle-weighted average of the faces around be that are not part of the newly created geometry for edges and vertices.
c, d, e - face normal of A. (But what if original edge that created bevel face A were marked “sharp”? Should we then use D face formal for d and C face normal for E and who knows what for f?)
f - vertex normal of vertex at f (i.e., angle-weighted average of normals of face C and other 3 faces around f)? What if faces are not smooth shaded – should bevels be faceted (that is, should we be using C’s face normal)? My best guess: no.
If the answers to the above questions are clear, then there are too many options for the bevel harden normals right now (e.g., I don’t think the “face strength” and “vertex average vs face mode” of hardening are necessary, nor the “fix shading” mode that frankly I am not sure what it does. If the answers are not clear, what options should there be?
And what if the user wants to have bevel affect “Face Strength” (Weak, Medium, Strong) so that a Weighted Normal Modifier can use it later? Should that be done instead of or in addition to normal adjustments (my best guess: instead of). And would it be sufficient to just set the “Face Strength” of all of the newly created geometry for edges and vertices (highlighted in the diagram above) to get strength “Weak”, or are more options needed?
I realize that in beta we probably shouldn’t be changing much, but I think the current code and options are pretty confusing. What do other users think.