What's with the new fuse/snap SOPs?

   1454   19   3
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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 …
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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.

Attachments:
g_to_g.jpg (846.6 KB)
g_to_tg.jpg (833.7 KB)

User Avatar
Staff
39 posts
Joined: Jan. 2012
Offline
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
Product Specialist
Side Effects Software
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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.
User Avatar
Member
4005 posts
Joined: June 2012
Offline
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’.
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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.
User Avatar
Staff
1737 posts
Joined: March 2012
Offline
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.
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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.
User Avatar
Member
2 posts
Joined: May 2016
Offline
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
Edited by Irinel - May 16, 2019 05:07:56
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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.
User Avatar
Staff
1737 posts
Joined: March 2012
Offline
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.
User Avatar
Staff
1737 posts
Joined: March 2012
Offline
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!
Edited by ndickson - May 16, 2019 11:23:57
User Avatar
Member
1642 posts
Joined: March 2014
Offline
Ah, OK. I'm on the prod. build .229
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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.
User Avatar
Member
4174 posts
Joined: July 2007
Online
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
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Staff
1737 posts
Joined: March 2012
Offline
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).
User Avatar
Member
1642 posts
Joined: March 2014
Offline
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.
User Avatar
Staff
1737 posts
Joined: March 2012
Offline
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.
User Avatar
Member
2687 posts
Joined: Sept. 2011
Online
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.
User Avatar
Staff
1737 posts
Joined: March 2012
Offline
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.
  • Quick Links