I'm selecting two points, call a fuse sop from shelf (via hotkey), and the node created ignores my selection.
Is this a bug or an intended workflow? I hope it's a bug, but the “group” and “target group” presence with an arrow selector makes me believe it's intended.
Another kick in the viewport-friendly modeling workflow's …

I understand the need to have the “group” and “target group” distinction and it does confer procedural power to the new SOP. I want that and I need it.
So in order to not give only flak, here's some constructive suggestions on how to not totally ignore the viewport functionality needed in direct modeling.
So, “group”(G) acts as both “target” and “source” when “target group”(TG) is disabled (default). So having points designated only to G (TG off) will produce something based on w/e is set by “output positions” (default - average value), like here:




When the latter is enabled, w/e is in G it will snap/fuse to TG. This makes “output positions” rule obsolete, since G will snap/fuse to TG, for the case in which TG has only one point.



For TG with multiple points, each G point will look for the nearest TG point and as the “snap distace” increases, they will ultimetely collapse into a single TG point. This is harder to show in images, but you can surely test it out.

With these in mind, perhaps having a selection prompt, as many other shelf tools have, is the best way to deal with these:
- select one or a few points, call Fuse SOP and auto-assign that to G
- press enter (i still don't know why Return is still used for these instead of shift+RMB, or any thing else that doesn't require moving the hand from one side of the kb to the other) to select TG, if any
- enter again to commit on G selection only
I might haven't thought this through very thoroughly, so issues could exist with this, but it's no excuse to be left with the current abysmal snap/fuse workflow in the viewport.

McNistor
I understand the need to have the “group” and “target group” distinction and it does confer procedural power to the new SOP. I want that and I need it.
So in order to not give only flak, here's some constructive suggestions on how to not totally ignore the viewport functionality needed in direct modeling.
So, “group”(G) acts as both “target” and “source” when “target group”(TG) is disabled (default). So having points designated only to G (TG off) will produce something based on w/e is set by “output positions” (default - average value), like here:

Image Not Found

When the latter is enabled, w/e is in G it will snap/fuse to TG. This makes “output positions” rule obsolete, since G will snap/fuse to TG, for the case in which TG has only one point.

Image Not Found

For TG with multiple points, each G point will look for the nearest TG point and as the “snap distace” increases, they will ultimetely collapse into a single TG point. This is harder to show in images, but you can surely test it out.

With these in mind, perhaps having a selection prompt, as many other shelf tools have, is the best way to deal with these:
- select one or a few points, call Fuse SOP and auto-assign that to G
- press enter (i still don't know why Return is still used for these instead of shift+RMB, or any thing else that doesn't require moving the hand from one side of the kb to the other) to select TG, if any
- enter again to commit on G selection only
I might haven't thought this through very thoroughly, so issues could exist with this, but it's no excuse to be left with the current abysmal snap/fuse workflow in the viewport.

Yup, very reasonable. If you haven't created an RFE, please do.

Cheers,
Scott

Hi Scott,
Will definitely do that.
One nagging question keeps rattling through the back of my mind, specifically, why we're in this situation to begin with after a new modeling SOP's out, but that is fraught with nonconstructive jabber, albeit conducive to informing SESI and not only, about a few things related to the current info gathering and testing in the prior to “release the hounds” stage.

McNistor
- press enter (i still don't know why Return is still used for these instead of shift+RMB, or any thing else that doesn't require moving the hand from one side of the kb to the other) to select TG, if any

The RMB menu has ‘Accept Selection’.

goat

McNistor
- press enter (i still don't know why Return is still used for these instead of shift+RMB, or any thing else that doesn't require moving the hand from one side of the kb to the other) to select TG, if any

The RMB menu has ‘Accept Selection’.

Better yet, I've discovered that actually shift+RMB works for accepting selection as well, not only for finishing a drawing session, like a curve or bone chain.
So the take home here is that, another version was released, one that supposedly addressed the less than optimal old fuse workflow and we still don't have a fuse workflow that works well in viewport.
Hopefully H18 will solve this and add a few crucial features, missed by many, like editing multiple objects simultaneously, proper local transformations for components, with a global control toggle, to centroid snapping and centroid transformation, save prefs for snap options, etc. At least these mentioned here and I'd be a happy hippo, such that I might actually start modeling in H.

Sorry. I fixed the issue reported at the top a month ago, but forgot to backport the fix to the public build. It should be fixed in 17.5.200.

Target Group is not used by default, so that the behaviour is similar to the previous behaviour. If you would like an option to select both, that may be possible with a separate shelf tool, but I don't know immediately, so please submit an RFE.

Cool!
Not sure why another shelf-tool is necessary (a third?) if the behavior I've proposed above is implemented, but at this point I'm happy it's going to be fixed, even if partially, sooner than H18.

Hey fellas, since this seems to be the right thread I actually have a question regarding the new fuse SOP. Whats happening with the “unique” function? Was very usefull. Is there anywhere else a new tab for that, or how I can get unique and seperated line segments? Thanks alot in advanced
Cheers

UPDATE:
Okay, I think with “convert line” and a “facet” node I can get the same result. But anyways, was cool to do that task in one node. So If that option is still in the new “fuse” node I would appreciate that a lot if anybody could point me to it.
Thanks

Best to file a RFE. This would be a good candidate for a separate “Make Unique” shelftool.

As a side note, is the Snap shelftool broken? Selecting two points does nothing for Snap, however if I select Fuse and uncheck “Fuse Snapped Points”, it works as expected.

Irinel
Okay, I think with “convert line” and a “facet” node I can get the same result. But anyways, was cool to do that task in one node.

A Facet node's Unique Points option should do the same thing as the Unique option on the previous Fuse SOP; it will leave primitives unchanged and just create new points where points were previously shared, rewiring existing vertices to them. Convert Line creates a separate polygon curve primitive for each edge in the input.

McNistor
As a side note, is the Snap shelftool broken? Selecting two points does nothing for Snap, however if I select Fuse and uncheck “Fuse Snapped Points”, it works as expected.

This was hopefully fixed in 17.5.253:

Fixed a bug where the Fuse SOP wasn't always recooking correctly when fusing is off, i.e. just snapping points.

If it's not fixed, it'd be helpful if you could file a bug for it. Thanks!

Ah, OK. I'm on the prod. build .229

ndickson
A Facet node's Unique Points option should do the same thing as the Unique option on the previous Fuse SOP;

Not sure if I'm missing something, but doesn't this node operate on polys only? If that's the case, then splitting a single point is not an option. The minimum of points split would be of those belonging to a triangle poly.
And for lines there's edge cusp, but currently nothing for points if my assumption above is correct.

McNistor
If that's the case, then splitting a single point is not an option. The minimum of points split would be of those belonging to a triangle poly.

this is true, however rather than having splitting functionality in Fuse SOP I'd vote for Point Split SOP, as it would nicely complement Primitive Split, Vertex Split and Edge Cusp

McNistor
Not sure if I'm missing something, but doesn't this node operate on polys only?

The Unique Points option will work on primitives of any types. Also, Facet in 17.5 can accept a point group, in which case any points in the group with multiple vertices on them will be duplicated.

tamte
I'd vote for Point Split SOP

A Point Split SOP would be clearer than Facet, and it could replace Primitive Split and Vertex Split if it had an optional primitive or vertex attribute pattern to split by, (defaulting to splitting all points in the group, if the attribute pattern is not enabled).

Yes, but calling a Facet from shelf when having a point selected does nothing. You have to manually lay down the Facet node and define a point group prior to that. Not exactly modeler friendly. You're most likely aware of this, reason for which I'm hopeful we're going to get an improved workflow.

McNistor
and define a point group prior to that

The group select button next to the group parameter should work too, but yes, it's not ideal. In tomorrow's build, Houdini 17.5.260 the Facet SOP selector should support points; it was a bug on my part that it didn't, since the selector should normally correspond with what the group supports. It's still not ideal, because of discoverability and Unique Points being off by default, as people have pointed out, but hopefully it helps.

McNistor
You're most likely aware of this, reason for which I'm hopeful we're going to get an improved workflow.

Thank-you for the vote of confidence.

ndickson
The group select button next to the group parameter should work too, but yes, it's not ideal. In tomorrow's build, Houdini 17.5.260 the Facet SOP selector should support points; it was a bug on my part that it didn't, since the selector should normally correspond with what the group supports. It's still not ideal, because of discoverability and Unique Points being off by default, as people have pointed out, but hopefully it helps.

Is it possible to specify individual vertices to be unshared in this way? Selecting a point would create new points for all vertices at that point, rather than specific ones.

jsmack
Is it possible to specify individual vertices to be unshared in this way? Selecting a point would create new points for all vertices at that point, rather than specific ones.

Please feel free to submit an RFE for it.