Howdy,
I thought I'd show an example of a real case where Houdini would fall short pretty bad regarding Fuse in a procedural scenario.

In the first image you see that I've started cooking for the first Fuse node. After 5hrs20min I accidentally pressed Esc (did not pay attention which window on which display was active) and the cooking stopped, so I'll never know how long it would have taken. Houdini was not unresponsive, it was crunching numbers.
Now, here's the thing: this was not a setup made to intentionally kneel Houdini, it is part of a scene I'm creating to learn more about Mantra with its shading, balls on a grid can get you so far.

The grid is, granted, pretty big (the “target to copy to” grid is 1000x800 rows/columns) and given the current limitations, more precisely, the fact that some operations are inherently or circumstantially single threaded it is expected to having to wait… as long as it takes.

What I'm not cool with is the user having to go through this cooking twice.

Why twice? Probably some context is necessary: the reason I have to use two Fuse nodes is because “consolidate” and “snap” are two different operations in this node. I don't know why someone thought that it's a good idea to make this differentiation since “consolidate” involves a snap, set by “Distance” param.
“Consolidate” (which is actually “weld” for the odd max/maya/softimage/etc user reading this) could very well be a toggle and then benefit from the “Snap Type” of the Snap operation in the Fuse node which allows you to fuse/collapse/weld/whatever_vernacular_you_prefer midway, instead of the current “consolidate” options of which none is midway.

Here's a simple example similar to the two Fuse Consolidate/Snap nodes, that it takes me 1s in XSI and which in Houdini I have to twiddle for a minute or so with two nodes at best or wait double the who knows how many hrs at worst.
In this particular case in Houdini I should use “point collapse” (which it seems to be absent, there's only an “edge collapse”) instead of Fuse, but that's not the point since this is not applicable in some cases where I need a distance based weld.

Probably should've shown a multiple edge consolidate/weld as well - more relevant to the issue at hand.
Similar to how there's no “point collapse” it seems there's also no “edge fuse”. Is there? I filed RFEs for the others, but not for this last one as I'm not sure whether I'm missing someth8ing or not.

If the geometry is too heavy, just use a shader that does the holes in opacity and a bump map for bevelling.

Maybe this can help you ?

https://vimeo.com/186132998 [vimeo.com]

Konstantin Magnus
If the geometry is too heavy, just use a shader that does the holes in opacity and a bump map for bevelling.

I don't do anything real-time related so I try to avoid bump mapping whenever possible and in fact I don't even remember last time I used it.

dedeks3000
Maybe this can help you ?

https://vimeo.com/186132998 [vimeo.com]

Will check it out, thanks.

Maybe you should try a different workflow then. There was a discussion on a speaker grill a few months ago:
https://www.sidefx.com/forum/topic/46281/ [www.sidefx.com]

It would be nice if there was a really easy quick way to do a fuse like the one in XSI. I really like poly modelling in Houdini now but that seems to be one of the things that always kinda stops the flow.
I do the same thing, one fuse for snap and another for weld.

(5 hours seems like a crazy amount of time to wait though )

@dedeks3000 I've tried the asset and I have not managed to make it work for my mesh. Works well on a simple one, but the lack of control over how the points fuse makes it very situational and certainly not suited for my scope.

@peteski Already have filed a RFE for the two Fuse nodes issue and will file others for (at least seeming) the lack of tools for collapsing points based on picking options and an edge weld. This last one I tried to achieve with the PolyBridge but didn't manage to achieve a weld between edges.
Not sure it's a good idea to cram so many tools into one node because then you'd have to tick/untick way too many options to achieve something instead of calling down a more specialized node, so a separate weld edges node would probably be better than to cram it in the PolyBridge.

Polyknit comes to mind, of which functionality has been wrongfully presumed to be covered by the Topobuild tool and now we still don't have a good poliknit tool, which IMO should've been a different tool because the alternative is to go back to the topobuild node and modify it (see the suggestions discussed in the SI forum thread) so it can successfully be used as a polyknit. It appears that solutions would be rather convoluted, even though they'd work, so IMO smaller, more specialized nodes are better than bloated with tones of functionalities.