I’m using Rhino (and Grasshopper) to generate some geometry. However some operations in that process are apparently running into a known problem area related to the intersection of two surfaces. Brian in tech support has given me a workaround that involves ever so slightly resizing one of the surfaces temporarily so that the intersection and subsequent split will succeed. While the workaround he’s suggested is sufficient to allow to me get the results I need in the test case that I’ve submitted, that case is just one possible scenario. My intention in using GH is to create tools that allow me to “sling geometry” around to allow various shapes to emerge from the ether. In response to his help in finding a generalized workaround, he suggested that I post in this discussion describing the limitation in the surface intersection operation in the hopes that somebody might know how to program around the bug.

One of the GH-based tools I’m playing with is one that allows me to position various synthesized surfaces so that they interact spatially. When an interesting interaction between the two surfaces is found the tool can create a single surface having the texture of the original input surfaces. (Visualize two waves interacting on the surface of a body of water.)

The algorithm I intended to use to produce a single surface from the two inputs was to use the intersection operation to generate the series of curves where the surfaces meet. I would then apply these cutting curves to a split operation on each input surface. I would programmatically cull the set of brep’s from the split operations, removing all those that aren’t on the face of the target surface. Finally, I would join all the remaining prep’s into a synthesized surface that reflects the interactions of the originals.

The bug that I’m encountering relates to the set of curves generated by the brep intersection operation being incomplete. These flawed curves can’t be used by the next step in my GH script to properly split the input surfaces so that their “backs” can be culled.

To demonstrate the problem, I’ve enclosed a 3dm file that contains 2 circular, wavy surfaces (see the first 2 screenshots) positioned with a common center point so that they interlace to form a diamond-like outer texture. (See the third screenshot.) The base geometry of these input surfaces are such that the interlaced set of surfaces have internal closed “pockets” on the back. (See the fourth screenshot.) In order to create a single surface that reflects the outward-facing geometry, the tool must remove these pockets from the inside wall of the combined geometry.

As shown in the fourth screenshot, only a small portion of the network of curves from the intersect operation are the “checkerboard” pattern I expected. The rest are simply fragments of the expected curves. Brian says that this is because the intersect operation is unsure about where the two surfaces intersect. So it simply punts and adds nothing to the curve network. His workaround involves ever so slightly rescaling one of the surfaces temporarily, performing the intersection and the split, then rescaling back to the original size.

Brian demurred when asked if this rescaling can be used as a generalized workaround. Remembering that my intention is to develop a tool that I and my collaborators can use to discover interesting textures, the need to hand tweak every possible interlacing combination fatally defeats the usefulness of the tool.

I’m writing to ask whether anybody in this discussion can suggest a generalized solution to this Rhino limitation. I’ve enclosed both the 3dm file, with the 2 surfaces baked into the 3dm. I’d appreciate any input you might have on what I’m doing wrong or a workaround should this in fact be a bug.

Thanks for any help,

- Bob

16.08.27 Surface1.3dm (995.0 KB)