the bevel and it’s relationship with seams on apply has always been “bumpy”. When the bevel is applied the new faces have a notched connection with other islands. This has been a bane of high poly bevel uv workflows forever. It can be mitigated with an additional segment but this also changes the form since the goal is to work with 1 segment or 3. These sort of disconnected notches happen all over the place. It’s not able to easily be exploited on a cube but with something more complex it happens.
Is there any way to ease the notching with applying bevels on models that are uv’ed as we work? Because since they are so variable it affects the baking and thus the texturing. Love the work so far! 2019 is the year of the bevel!
Yes, it has been on my TODO list to try to improve things here for a while. I’ve lately been trying to sprint on my major fix to Boolean, so the bevel TODO list has languished, sorry.
This particular problem is not easy: when you have an odd number of segments, how do you decide which side to put the middle segments on? The algorithms I thought of were pretty complicated. Someone had the idea: just materials to break the tie. That is, if there are different materials on either side of a beveled edge, put the middle segments on the side with the lower material index number. Do you think such a solution would work for you?
Currently uv islands are always placed like in -1 material example. It would be nice if material setting dictated location of new islands or there was extra setting in bevel modifier:
that’s great if you have multiple materials, but the example @mx2 gave is just a single material. to answer the question of ‘which side does the UV go on’ I would say consistency is far better than accuracy in this case. I’d rather the algorithm flipped a coin and picked a side to be on and then just stuck with it throughout that particular loop so the seam is a consistent loop of edges. It’s easy enough to rip/sew things where they need to go if they’re all easily selectable, much harder to go ‘easter egg hunting’ for the random missing faces.
True, consistency is more important than control here, also it’s hard to think of situations where user wants island placements like in -1 example instead of 0 or 1.
Chipping in here, the issue @mx2 showed was/is a real world issue i had with game assets.
I think the material solution would be a last resort fix, atleast in my user case scenario.
You almost never assign separate materials in gamedev assets, especially not in the same watertight mesh.
From my point of view it doesnt really matter which side the the segments would be placed on, just that they are consistently placed along one of them.
Spitballing solutions that might not be feasible.
-Base it on UV mass?, Ie the bigger UV island gets the segments
-Base it on tricount within a seam area
-Move the seam to center-line of the bevel after application
-Flip a coin. Pick a side:D
yep this. For these cases when u work with game assets that dont bake down (this particular asset used weighted normals combined with a trim sheet) the importance is not so much where the bevels end up. Just that they end up at the same place:)
Thanks for the feedback. I was hoping the material thing would solve the problem because that would be relatively easy to program. I had started earlier on trying to figure out the algorithm for “just pick one side and stick with it” but it turned out to be pretty complicated. So it is gong to take me longer to come up with that solution, but I can see now that it is necessary to do so.
i think even the material idea can be worked around and be used as a jumping off point. If it has the -1 or +1 it would definitely be a plus but any improvement for this would be a leap forward towards texturing from b3d and bevel in the mid- range workflow.
Why not just let the user choose? As it happens with particles where a menu let’s you choos ewhat material to apply to hairs, we could have a menu to choose what material has to be applied to the new geometry
lsscpp: there already is an option to say what material to apply to newly created geometry. That’s not the problem here. The problem here is to figure out which uv island to put the center segment of a bevel on when the beveled edge is a seam. The last time I looked at this problem I wrote myself 14 pages of notes and was developing quite a complicated algorithm that looked like a lot of work to write and get right, so I postponed working on it, hoping a better/simpler idea would arise. The material-tie-breaking rule was one such simpler idea.
How much UV island information does Blender store? A per-island dilate/erode flag is the first thing that comes to mind for something like this, but I’d be worried about the overhead (especially if there’s any kind of weighting/relative priority involved).
Blender doesn’t store any UV island stuff explicitly. All it stores is UV values per Loop, from which a program that manipulates UVs needs to use to discover where the islands are. The algorithm I will probably use will be: calculate the islands, use some rule to set a priority order among islands, and then use that to break ties. The reason I wrote 14 pages of notes on what seems like a conceptually simple algorithm is that I was trying to solve some other issues with the widths of the things after bevel in UV space. Too hard to explain shortly here why this gets complicated.
Hi Howard, not sure if this idea is helpful for you and perhaps I still got your problem wrong, the information I’ve read over is quite limited and I understand that it easily gets hard to give a short description, but as you said you don’t have permanent island information stored and as you have thought about that material idea being valid, why don’t you calculate a hash value from an islands faceIDs set you discovered. The one with the lower hashvalue gets the center face associated. Neighboring org-edges between two islands would always produce the same hashvalue and should give you always the same side, or did you try to skip your island detection?
I was hoping to skip island detection (with the material index hack) but this thread has shown me I do indeed have to do that. And some solution like you say will be what I do, though rather than a hash, I can just keep track of which island each face is part of and store a priority order index in some structure associated with each island (structure only kept around for the duration of bevel).
Also, most of my notes to myself were trying to fix stuff related to not-greatness with how I make the vertex polygons in UV space. E.g., if we have a long box and unwrap it so that the top and two ends are in one island, and the bottom and two sides are in the other:
current bevel after a bevel with one segment does this:
and a user would prefer this:
which I agree looks much better. By detecting a prioritizing islands, I can get all the long segments and triangles to go onto the lower island. But I was also trying to fix the triangles that you see in the current bevel output case – why do they have a point half-way along an edge? It gets deeply into the current algorithm for how to interpolate in UV space after a bevel, and fixing that took me off on a long tangent that I didn’t fully resolve. I should just treat that as a separate problem; doing the island priority thing will at least make things better than where they are today.
One thing I thought of though: what if a UV seam goes between different parts of the same island? E.g., a mesh that looks like this, with the orange line showing a seam.
In a case like this, one will just have to make an arbitrary choice of which side to put the bevel segment on in UV space. I guess this is OK, and probably a rare case anyway.
I fully agree with you. Storing the islands temporarily is much easier and has less computational overhead. I wasn’t sure if you meant you even don’t want to store islands temporarily, that way the hash would have still allowed to give you a consistent answer with the limited information of 2 islands only.
But in that case,I’d say we have no “side” to choose as it should stay inside the given space, right? Wouldn’t that be a case where the area occupied by the new faces should be taking it from both adjacent faces equally?
Or did I get you wrong, not sure if the image is meant to be the uv or the mesh representation or somehow both.
If it’s about keeping connectivity consistent ( shared verts ) and not placement your case could be still have some problems if the seam is spanning across multiple faces in an island.
I meant it to be the mesh representation, with the UV representation not shown somehow putting a gap where the seam is (not essential, I know, but in other cases like the mesh have turns in 3d space maybe the natural UV representation would be to somehow unfold the shown ring to a straightish line).
You make a good point that things will look ragged in this case if there are multiple edges across that seam and I choose the side arbitrarily for each individually. Let’s hope this case is rare because it would be annoying (though not impossible) to handle such a case consistently.
Yeah, I see what you mean. Perhaps a solution like choosing sides based on the existing uv coordinates of the adjacent faces might be a heuristic to get rid of that problem to a certain level.
