Strokes: can't fill an L shape when drawing stroke perpendicular to the selection

[jfranmatheu]

The only issue I can find is that adjacent faces aren't detected in this scenario: https://cl.ly/tKmX

Indeed, this is still an issue in RF v3.4.4.

2025-01-16.17-04-55.mp4

Originally posted by @jfranmatheu in #530

[jlampel]

I do agree the example above seems like it should fill the shape and that it would be intuitive in this case, but it other cases it's a lot less obvious how it should work.

You can already fill the same shape by drawing the stroke parallel to the selection and connecting it to the top vert:

Since it is already possible to get the same result, I will put this as a low priority.

The key difference being that the current method attaches to a specific vertex while the proposed action leaves it ambiguous. In the case of a square, it looks obvious how it should attach, but what about other shapes? Should this one even attach at all?

A simple approach, which would probably be good enough, could be to take just these two sets of edges (highlighted below) and do a merge by distance with a big enough size, say half the size of the span, and then restore the previous selection. That could lead to the wrong verts getting merged if the count does not match, but it could be left up to the user to scroll the count until it matches or draw the stroke so that it lines up better.

This approach could also help solve other cases like this: #1421

[jfranmatheu]

Thanks for the valuable input @jlampel !

I pulled this issue out from a nested report inside an old bug report.

You are right that it is somewhat ambiguous whether it should merge or not both strokes, because user might just want to extrude the stroke without auto-merging to adjacent strokes. Distance checks may help, but even that could bring unwanted results in closer situations as well as the extrude is not visible until you've done it so you might encounter a surprise afterwards which can cause UX issues.

My guess now, with all your provided input, is that a new 'glue' action or tool should be done so that once you've done the stroke/s you can select a couple of strokes (adjacent one in this case) and join them. That should fix the other named issue (#1421) as well. What do you think about this? (i know it could be outside the scope of v3 tho, but seems interesting for v4 at least)

[jlampel]

An easy way to join sets of edges would be really nice! I've had a new tool for merging in my notes for some time, and also want to introduce a general-purpose cleanup operator (#1395) that users can run after doing messy or non-RF operations.

For this specifically though, I would like to minimize extra clicks, and I think we could actually solve this pretty well in a general way and without too much overhead by treating it like a zipper. Let's say we start at one corner of the newly created patch. Both the newly created edges and the existing edges we want to merge with are now part of the same edge loop, so go one vertex away from the corner along that loop and check the distance. If it's within the distance, merge to the previously existing vert and continue up to the next pair of verts. Once the two verts are not within the range, break. Do that for all four corners.

I think something like that should minimize unwanted merges since it's only comparing two verts at a time, and it shouldn't impact performance much since it breaks right away if there is no merging to be done.

Does that sound feasible? For v4 though, I don't think we would need to backport this to v3.

[jfranmatheu]

Yes, it sounds really feasible. I was thinking in a more general purpose approach, but the 'zipper' like concept sounds like a simple but straightforward method for this issue, without any over complications or side effects I can think of. Really nice idea, thanks!