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.
Regularizing Orientations Along Contiguous Beveled Edges
(Excerpt from notes page)
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
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.