I’m attempting to implement Campbell’s suggestion in Blender Archive - developer.blender.org and have re-worked things a bit but I’m running into some issues as I don’t know the blender API very well.
Implementation
Patch: Blender Archive - developer.blender.org
* Gather information about each object (multi-object support); namely how many faces/tris are in each object
* Create the bvhtree
* Iterate across each object, triangulating each object’s faces, and storing them into the bvhtree with a unique ID
* Detect the overlaps
* Process the overlaps, skipping combinations that have already been processed and other directly degenerate cases
Problems
The bvhtree detects everything, not just truly overlapping faces… it includes any face combination which shares verts.
How should I go about filtering out these non-overlapping faces from true overlaps?
Here are my test UV maps I’m using to help validate the design – Red ‘O’ text indicates the faces which should be selected in each situation:
1 object, 1 island, no-overlap:
Yeah, I’d like to complete this as well, but no dev has responded to the patch and my questions yet :-/ For instance, a prior edit to this same topic before I changed the summary was asking if this should only do island-to-island overlaps or all the way down to faces. I got no response, even from the community as we see here, changed the summary, and went with faces in the initial implementation try…
It’s too late for inclusion in 2.80 but if I have time in the following weeks I may attempt another go at it, and at least bump the patch in phabricator in hopes someone will offer some advice.
Island to island would be useful for packing, and per-face would be useful for finding degenerated UVs. So both. But if there was ItoI you wouldn’t have to check face to other island’s face.
I’m aware of at least 3 add-ons that implement overlap checking (textools and paid: shotpacker and packmaster), so I guess urge from community is not as high as it would be without them.
Textools only does island bounding-box checks. That means it would flag overlaps incorrectly like in my 4th picture above labeled “1 object, 2 island, no-overlap” since the 2 bounding-boxes for those islands overlap.
But yeah, I believe the paid addons do a proper check, mostly because they’re the ones doing the actual packing in the first place.
The issue is that the BVH is detecting overlaps for faces that have shared vertices, i.e. adjacent ones. The patch has a TODO in the place where I think I need to account for this, but I’m unsure of the best approach.
I know the patch is assigned to you but I’ve been hesitant to ping since you’re hands have been very, very full
You can store the If you store BMLoop triplets, like: BMEditMesh.looptris - all you need to do is access both triangles and check if they share any vertices.
Once thats working, check those vertices have matching UV’s - only ignoring pairs that do, since it’s possible the UV’s will be disconnected even if the verts are shared so you will want those to show up as overlapping.
I’m afraid I don’t follow. Are you suggesting I store the mesh vertices or the UV triangle vertices for later reference?
Take for instance my 4th image above titled “1 object, 2 island, no-overlap”. In this case the bvhtree gets me to the point where it says UV Face 0 (the bottom quad) and UV Face 2 (the 5 sided ngon) are overlapping - a false positive. It correctly does not detect UV Face 1 (the floating triangle).
Now let’s say I stored the coords for the 2 UV triangles of UV Face 0 and the 3 UV triangles of UV Face 2 as what I think you’re suggesting. How would that help without then doing a full tri-tri overlap test?
More generally though, any connected mesh (like say my 1st image above which generates 8 pairs of overlaps currently - all false positives) becomes a degenerate case where the bvhtree is of no help.
Any news on this? I’d love to have this available natively.
Particularly overlapping in a single island, which can be very hard to find on dense, complex meshes, where I often only find out once I’ve started texturing!
Abandoned my first patch above as it was very broken
I figured out most of my issues/questions and I’ve reworked the patch (works correctly across a small handful of real files and tests I put together)
I’ll submit a new patch and see how things go for 2.81
Progress pics:
Here’s a screenshot that shows how it properly detects overlaps. It’s across 4 objects (multi-object editing supported). I’ve tried with some personal scenes as well as the 2.80 splash screen (which found a legit overlap :))
There are still pending workflow / design open issues though:
This selects overlapping faces. Is this actually useful in your workflow? Some software will just “highlight” the overlap (almost like an overlay) but the current code is designed more for Operator runs
UDIM support, once enabled will need to be accounted for here. Whoever loses the race for checkin gets to fix things up; and I’m currently losing
Selecting - yes its useful to have select overlapping operator. If it was only an overlay sometimes small overlaps could be sneak under the radar.
But since you brought that up, there could be additionally a overlapping overlay.
Overlay is better, selection is gone when you start to fix the problems making you constantly click again “select overlapping” because you dont remember their locations. Overlay would highlight overlapping islands all the time unless you move them apart each other fixing the issue.
Maybe even overlay for flipped uv island too if that is possible in blender.
Did this overlay ever get implemented? I don’t see it in 2.93, and I would love to have a way to visualize the overlap without having to select faces each time.
Hi, no, it is just an operator right now to be invoked manually. It’s not particularly well suited to run continuously as an overlay although I still think that would be a neat feature.
Someone else can take up the task though if they feel capable. It would probably need a different algorithm and mechanism to detect the overlap in realtime - perhaps using some kind of feedback from the GPU for what is basically detection of “overdraw”.
