I believe this issue was also filed as a bug yesterday. I have a fix for it which should show up in the nightly builds by tomorrow. If you want a workaround, the cause of the crash is the constant zero uv values on your geometry that goes into the polybevel. The bug is in handling degenerate uv maps.

Are you on Windows by any chance? What result do you get when you set “Detriangulate” to “No Polygons”? I can't seem to be able to reproduce this on Mac. There is an outstanding bug with similar circumstances that only surfaces on Windows, but I have only a single example of. The huge overhead of tracking this on Windows (need to have Windows dev setup and compare against another platform side-by-side) under the current development load has kept me from investigating it in absence of more failure cases.

As a side note, normals have nothing to do with Boolean's output. The winding of the polygons determine inside and outside but reversing polygons should only fix problems if you have made a mistake about the semantics of the operation. Most importantly, perturbation of the input should never be required or be a workaround. Please report failures to us through the bug database and preferably lock the inputs to the problematic boolean node in your submitted hip files.

I noticed in fact that Boolean may report non-manifold edges, even when you can't find them in your input geometry, and it's not a mistake. I hadn't considered this before. If you look at the picture here, from the same geometry as above, you can hopefully see that the two highlighted points are both incident to two quads which happen to share yet a third point. Geometrically, this should only happen if the two quads are perfectly coplanar. In practice, however, there's nothing to force a quad to be a planar polygon. A nonplanar quad is in reality the merging of two triangles defined by one of the diagonals of the quad, without specifying which. It is therefore up to the Boolean sop to resolve the ambiguity as a preprocessing step and triangulate all input polygons pretty much the same way the Divide sop would do. In the example in the figure, the diagonal in questions connects the highlighted points and this creates an edge incident to three triangles, namely the one shared by both quads, and the two remaining ones, one from each quad. This would be a non-manifold edge created in preprocessing of the geometry!

gswartz
So, is there a way that I can get a view of which edges they are so I can adjust the input geometry?

Unfortunately, we don't have a very good way of visualizing bad topology. People tend to use “Divide” sop's “Remove Shared Edges” to inspect boundary edges that may look like interior ones (not applicable in this case). For non-manifold edges (those incident to 3 or more polygons), your best bet may be to use PolyDoctor's (disable everything in the first tab right away) “Visualize Maximal Manifolds” under the “Topology” tab. This will colour your polygons. The bad edges are where two different colours meet. You can also visualize inconsistently wound polygons by unchecking “Ignore Winding of Input Polygons” in the same tab. Your geometry doesn't have this issue would also be something quite detrimental to passing a geometry as a solid. If your input is a connected manifold you should get a single colour for the whole thing. The problem is of course that you may fail to see very small things, as is the case with your geometry. I spotted two problem areas (see the screenshots). If you enable “Create Manifold Number Attribute” and check the geometry spreadsheet you can see that your geometry has has 12 maximal manifolds, numbered 0 to 11. You need to have one, or generally, as many as the number of connected components of your geometry. If I wanted to guess, I'd say you have used the Fuse SOP somewhere higher in the chain?

gswartz
As for the rest of your explanation, I'm assuming that I need to define B as a surface instead of a solid?

Yes, if you are cutting A with B, generating only pieces of A, then you'd always be better off marking B as surface.

McNistor
Instead of, or in addition to, making comparisons between various s/w modeling capabilities and other theorizations, we'd all be better off if at least one more user would file a RFE to see squashed a rather long in tooth bevel* bug that dashes around with impunity for at least a few builds now since I found it.

*bevel bug:
- create a primitive
- select a few polys
- apply polybevel op
- check “ignore shared edge”
- lose

This should be fixed in tomorrow's build.

Way to find a connection to the subject at hand! Touché.

Your object A doesn't qualify as a proper solid. Boolean does warn about multiple non-manifold edges. In the list of offending issues of a geometry to pass as a solid, non-manifold edges are on the very top; they pretty much kill any chance of a proper solid interpretation.

Since you're shattering A by B, it doesn't matter whether B is solid or not (although you may get warned about B's solidity issues if you don't pass it as surface). If you were doing any other operation, your input B would also make up for a poor choice of a solid, even though it doesn't have non-manifold edges. That's because its boundary edges are being crossed (by self or opposite geometry). Even if this wasn't the case, describing a collection of open surfaces as a solid leaves it up to the sop to arbitrarily interpret the nesting of the solids. So, if you have 2 disjoint grids representing a solid, it's perfectly possible for one of them to be seen contained inside (the solid volume defined as a half-space by) the other. Under this interpretation the union of this solid with anything else would completely drop the grid seen as contained by the other.

This must be fixed in today's build.

The boolean example does show a bug. I'll post here when it's fixed.

It's probably because you're describing your input B (the grids) as solid. Objects representing solids are OK to have boundaries (as grids do) so long as those boundaries do not come in intersection with the solid itself or the opposing geometry passed to Boolean. In other words, surfaces with boundaries can be treated like pieces of a solid parts of which is unknown, but only as long as the unknown parts (which start at the boundaries) are kept out of the operation.
However, in the case of the shatter operation, when generating only pieces of A, the result is the same whether B is marked a solid or a surface. If you change B to a surface, the warnings should likely go away.

powerstroke3000
Modeling with these curve tools is really great!

I'm glad you think that. Polygon curve bevelling wasn't originally intended to be done as part of the new polybevel node and was only implemented at the end by somewhat of a hack that piggy-backs the regular point bevelling. The corner curves therefore are not exactly circular arcs and there's no stoppage points. I intend to take a stab at redoing the curve bevelling since it should be fairly straight forward to do independently but it's not currently our highest priority.

This should be fixed in tomorrow's build.

You cannot expect to bevel beyond the ring of polygons incident to edges being bevelled. PolyBevel doesn't check for passing beyond those but it does check for internal collapses that are often related to those limits. With the number of columns on your tubes there's very little room left for bevelling. This is not even a Houdini limitation, no tool out there bevels beyond the immediate ring of polygons. Doing that would easily as difficult of the boolean if not harder. Your old PolyBevel result should also be broken if you inspect it over the top of the lower tube in the picture. You should find some inverted faces there.

This is a known issue. I'll post here when it's fixed.

There are two separate issues here:

1. The crash is due to bug that is fixed in 16.0 but was forgotten to be back-ported to 15.5. I'll take care of that presently.

2. Point bevelling only works on the interior points of the same polygon curve. When you fuse the end points of two distinct primitives, you still have the joint shared by two primitives. As it stands, this is rejected by polybevel. You'll need to use join together with sort (on vertex order) to turn the result into a single curve.

I committed a fix for this. There was indeed an issue that was responsible for this and a couple of other cases. Please take a look at tomorrow's build and let me know if you still see this issue.

That's seems to be a bug in poly bevel's handling of terminal points (points incident to on a single edge to be bevelled). I'm be working on it and should have a fix soon.

By the way, Point Bevelling is now available in 15.5. It also works on open polygon curves.

This should be fixed in 15.0.369.