I think commands like stitch handily ignore the selection filter IIRC. In mergefaces, this isn’t the case (so if you’re restricted to points, then run mergefaces, you can’t pick anything - although obviously it doesn’t take long to realise why).
Got that, thanks.
RH-63090 MergeFaces: ignore filtering
No problem. I wasn’t sure if this was seen as the way going forward. I did think for a moment that something like Stitch could be handy with consideration of the filter, if you only want verts/edges, not both.
Do you know how long it will be until we get some kind of indicator for coincident edges/vertices, so when cycling through two overlapping points for instance knowing which face they belong to?
Also - I’m beat on this - has there never been a surface edit point on function? Apparently it’s only curves and subds, i could’ve sworn it was possible with surfaces too.
Hello - no - these exist, but are not and never have been, to my knowledge, exposed in the UI. The reason being, if memory serves, that for surfaces, edit points can quickly become ‘squirrely’ and send the surface of in unintended ways.
I must’ve imagined that then. Given it’s possible on subd surfaces, will it ever be possible (in a stable/workable manner) with surfaces? Not key of course, since we still match with the normal surface edges. Or edit curve edit points and match surface edges to those said curves.
In that case, how would you go about the above - matching part of a long surface to the shorter surface? With a long curve and short curve, I can use the edit points on the long curve to match to locations on the shorter to kind o fmake a transition.
I get this would be easier starting from the other way round (make the short surface with a subcrv cross section from the long edge) but just wondering.
Hello - I would say that is pretty hard to do with any real control but you can mess with
HBar' and SoftEditSrf`
Thanks Pascal. I guess the moral is that it’s simply better to break into two surfaces?