I’m not sure about this. Blender already has a curve system, both as objects and the curves for color correction. I am planning to add the possibility to systems similar to both of those, so another option might not be necessary. What’s necessary here probably is a quick way to go back and forth between grease pencil stokes and meshes/curves, which might even already exist.
It does exist (Convert to Geometry). GP strokes have some benefits, for example they can be sculpted, in 2.8 they are now objects so they can be thought of as a collection of curves. Or, presets.
Of course you don’t have to add this functionality (it can be done as an addon or whatever anyway) but it would be a good addition.
Hi all! I’m making progress on the weld case where two beveled edges come into the same vertex, and right now the profiles are generated, but with inconsistent orientations. I’ve made a plan to tackle this and I figured I would post it here to see if anyone had thoughts, because it will probably be a large undertaking to solve this.
One of the problems I’m introducing with custom bevel profiles is the orientation of the profile. One of the problems is more normal-- as I modify the way that the profiles get built, I might mistakenly flip the indices of the profile vertices, so the connections to the next profile along the line will be flipped, creating a whole segment of messed up geometry.
The other (possibly more problematic) situation is when the code chooses a different orientation for the profile, so the shape is rotated the other direction compared to another profile. The indices could match up or they couldn’t, either way the connection to the next profile will not be correct. These two situations I described are likely part of the same problem, and the only way to fix it will be to maintain consistent orientation of the profile along contiguous beveled edges.
There are two types of contiguous beveled edges: cycles and chains. I need to write code that travels down beveled edges to find these contiguous sections. As it travels along the edges it will carry over the orientation of the custom profile by making sure it starts at the same side of the bevel, or the new BoundVert that’s linked to the last one with an edge. Here’s the process:
Start at a random BevVert.
Travel along each EdgeHalf connected to the vertex, marking which of the BoundVerts the profile will start at when a new vertex is reached.
Stop when there is no continuation of the beveled edge, or when the next BevVert has already been visited.
As long as there is still another unvisited BevVert, start the process there again, and in the end all of the BevVerts will be visited.
This should give enough information to pick which BoundVert to start building the bevel profile from in build_vmesh. However, I’m not sure how this will interact with intersections of >2 beveled edges. As soon as a beveled edge comes into one of these larger intersections the profile will be messed up to some extent anyway, so maybe I should treat the a >2 way intersection as another stopping point for the travelling code. But then it’s not clear that anything would happen on a shape like a cube where all of the BevVerts have 3 incident beveled edges.
You could indeed stop looking for chains/cycles when you hit a vertex with more than two beveled edges into it. As you say, you are eventually going to have to tackle the hard case of what to do at the vertex for the “vertex mesh” at such a junction of >2 asymmetric profiles. You and others had a bit of discussion about this at the beginning of this topic.
Ideally, you would continue chains/cycles even through vertices that have >2 beveled edges in, so that, say, the top of a building would get a consistent-looking cornice around it even if there are other vertical beveled edges meeting the top (though would a user actually do that? seems an argument for not worrying about this case too much, at least to start). You would need some tie-breaking rule to say which edge to continue a chain along. One would be: minimize the turning angle. Of course this is of no help with a cube, but it would help with a cylinder of > 4 sides. Another tie-breaking rule might be to prefer the top of the profile to be on some axis, say the z axis, so choose the edge that is more perpendicular to the z axis.
Indeed a tricky question. I guess there is no correct solution to this, as some intersections have probably no real solution. Howards notes are on spot, I looked a bit at houdini and it has exactly the same problems with this.
I guess the most important thing is to find long continous bevel chains and try to keep these going.
And for the user it’s always possible to do the bevel in a two step operation, do bevel profile on vert group A, do inverted bevel profile on vert group B.
The usecase for having asymetric profile all over a model isn’t also very clear to me. I can see it being useful for some sort of procedural panel or line inset. I expect this to be used in much more constraint models, like some sort of profile, where the bevel plays a major shape defining role - but thats just my impression, so other useres might have different ideas here…
Thanks for the advice both of you. I have my first results from this today, and it worked surprisingly well! I have a fair amount of testing and fixing still to do, but in general it works for the sort of weld cases I’ve been testing:
The metric I chose to implement for continuing a path’s orientation through a >2-way intersection is to continue the orientation as long as there is a clear choice for the best relative angle through the vertex to the next edge. If the best relative angle is ~10 degrees better than the second best angle, the consistent profile orientation path will continue. If there isn’t one obvious choice for best path, the geometry at the vertex is not going to be clean enough for a continuous profile orientation to matter anyway.
I hope this procedure will enable consistent orientations on something like the top ring of a cylinder. The more parallel ring’s orientation will remain consistent, but the lengthwise edge’s profile’s orientations shouldn’t matter.
seeing this go nicely I wonder how hard would be to implement Custom curves fallofs for the proportional editing. Along with the gradient coloring worked by Benjamin Sauder it can be some of the most robust features blender has to offer , instantly a lot more powerfull to the point it can substitute some deform modifiers for ex.
Would you consider integrating a powerful feature allowing to use Bevel also on FLAT surfaces (bevel weighted edges) with displacement offset as in Houdini. This would enable very powerful workflow for hard surface panels: Note: It’s not same as EdgeSplit+Solidify+Bevel.
Standard polyBevel node with Profile. Profile defines Height (e.g >0.5 raises, <0.5 lowers). Would be useful for architectural work, hard surface (panels), if asymmetry is possible then also potentially cloth seams and work a like. It’s somewhat possible to emulate it in Blender with WeightEdit nodes, but it’s far from real solution.
I agree that this is a cool feature, especially with custom profiles it would be very useful!
If I have extra time at the end of the summer I’ll consider looking into this, but I expect it would be a fairly large undertaking, and there are other things I would probably focus on first, like adding preset selection, so I can’t promise anything.
Testing the terminal edge case (with SSS, bloom, and volumes for fun)
I got the terminal edge case (bottom) to obey the orientation of the profile that I worked on marking out last week. With this and the weld case (on top) mostly complete, the custom profiles are starting to become useful! It’s already a quick way to make some complex geometry. Unfortunately with some memory leaks and loading crashes I can’t really recommend using it for anything but some novelty right now.
Profile Drawing Widget
Currently the widget to enter the profile uses the same CurveMapping widget as all of the color management and falloff curves in Blender, which means that it it can’t display a curve properly if each Y value isn’t a function of X.
It’s frustrating to draw profiles when they aren’t drawn properly, so I need to create another method for drawing filling in the dark area under the profile. Here’s the plan: for every pixel, start from the top by drawing the light color, then travel down, switching between light and dark every time a new line between two points is hit.
At first I planned on implementing this functionality as a special case of the existing code, but eventually I decided to make a new widget. Although most of the UI callbacks are similar, not forcing this new functionality into the existing code will keep both widgets much simpler.
Next
After finishing the new drawing widget, I’ll fix the crashes on loading saved custom profile modifiers and the memory leaks. At that point the feature should be fairly usable, so we’ll probably start to collect custom profiles for presets from the community. Then I’ll get to work on the mesh patterns on >3-way corners.
Why not using a curve object instead ?
Beveled curves are already referring to a Bevel Profile Object.
That would not surprise Blender users to do same thing for meshes.
They probably already have their own custom profile library made of Curve objects.
Not a fan of that idea. Blender, in my opinion, has a bad habit of making you use empties or curves instead of just having a widget it instead. They can kind of “build up”, if you know what I mean. If I use several custom curves for bevel profiles, maybe one for different objects in the same scene, or simply more than one on the same object, all of a sudden there are a bunch of curves hanging around, inevitably to be put into a collection with visibility turned off. It’s just kind of clunky. I’d rather have a widget for sure!
I don’t deny that. I just make the remark that solution could be achieved by having less work to provide.
I prefer having a bevel modifier producing custom profiles with curves objects in official release rather than a bevel modifier limited to GSOC branch, crashing because of unfinished widget or without ability to store presets.
That is not a proposal for ideal solution, but a proposal for a tradeoff, in case, time to achieve a widget under GSOC period will be missing.
There is nothing shameful to start by providing a working solution to user and then, polish workflow and UI.
Ideally I’d like to have that option as well! But when I look at the big picture it’s so clear that a widget is the most user-friendly solution. And as @Bobo_The_Imp said, this seems to be a corner that’s been cut before, so I think it’s important to do it right.
With this ProfileWIdget as separate code, maybe it will be easier to use it elsewhere in Blender down the line.
And I’ll have to think more about the preset library. It would be great if they were stored as curves in the background, but as more details are resolved about the upcoming asset manager I’ll see if there is good way to use it. In the meantime we’ll just have a lot of presets.
Yes. It is sure that when modifier stack will be replaced by nodes that would be useful for a node.
Currently nodes for compositing are using mask. We could imagine a mask used for nodes like a curve can be used by a modifier.
It was just a reminder. If Profile widget is too much time consuming : enable Curve Extra addon, add a Sector, set End angle to 90, type to Poly and try to make Bevel modifier to work with that.
I used the same code that’s used for the “Fill” operator generate indexes for triangles to draw the inside of the profile. Unless clipping is turned off and the points are moved out of the starting limits, the profile will always be a bounded polygon (including the point in the bottom right corner), so this should work very well! And it’s much more efficient than my previous plan.
Making that work is what I had planned for the next week, so I should be able to get to a few other things sooner than expected. Right now I’m implementing a better algorithm for the insertion of new points. It’s pretty frustrating currently because it doesn’t connect the new points to the right neighbors.
I am interested: is it planned so that you use exactly the points that the user draws? Or are you also planning to enable drawing curves (eg bezier), where Blender calculates the points on the curve during bevelling?
