How do I decompose 2 intersecting surfaces then recompose as 1?

One of the GH-based tools I’m developing 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.) But a surface intersection operations is producing unexpected results, putting my entire algorithm at risk of failing.

I’ve enclosed a .GH that has a simplified version of the algorithm I intended to use to produce a single surface from the two input surfaces. How it works is to use the Brep | Brep component to generate a set of curves where the input surfaces meet. I then apply these cutting curves to a Surface Split component on each input surface. I intended to then 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 facial interactions of the originals.

This algorithm is however not completing successfully because the outputs of the Brep | Brep don’t appear to accurately reflect the complete set of curves at the intersections of the 2 faces. I think it’s because of these incomplete set of curves that the Surface Split operations are returning a very incomplete set of sub-surfaces. This sparse set of results don’t allow me to reassemble the sub-surfaces to form a complete synthesized face.

This posting includes the Grasshopper document, as well as a screenshot of the GH code. The GH Intersection and split operations take a long time to complete. So I’ve enclosed Bake’d versions of the important geometries in the layers of the 3dm document as indicated below. But this results in a 12MB document, which is larger than the discussion can handle. But i can be downloaded from here. (my Google drive)

Scaled Waves - Layer 1
Brep | Brep out - Layer 2
top Surface Split out - Layer 3
bot Surface Split out - Layer 4

I think there are problems in Rhino/Grasshopper related to intersections and splits. But I’m also open to somebody suggesting a better way to accomplish my objective — including workarounds.

Thanks for any help,

- Bob

Attachments:

Code.jpg, 52 KB
IntersectProblem.gh, 22 KB

Replies to This Discussion

Permalink Reply by neobobkrause on September 1, 2016 at 9:26am

Tom,

Thanks for bringing your experience and perspective into this situation. As I say in my original posting, the purpose of this tool is to enable designers to discover surface interference patterns that suit their needs. They use the tool to tweak the underlying surfaces and their relative positions. This is the easy part. The hard part seems to be how to merge the 2 input surfaces they're interested in into a single surface to be used as a boundary of a solid. I'll use any algorithm necessary to accomplish this objective while retaining an approachable user-experience for my designer collaborators.

I'm a little unclear about what you're saying in your reply. You say, "Trash in, trash out." When you say "horrible contours," are you referring to the exterior face of the interlaced surfaces? What's trash, and how can I evolve what you see as trash into usable gems that lend themselves to the practical realities of GH and Rhino?

Sorry, could you also tell me what you're referring to as 'x-corner'?

Thanks for any insights.

- Bob

Permalink Reply by neobobkrause on September 2, 2016 at 2:46am

Tom,

Thanks so much for this input. Being as new as I am to Grasshopper, I'm drunk on what I've been able to accomplish so far. I wouldn't have thought that isolating those parts of a surface that are unobstructed in the normal direction would be as challenging as it appears to be. I can't really appreciate the difficulties of a B-rep intersection as I've never really looked at the underlying data structures and math. So I bend in your direction. But tell me, do you have a sense about whether the underlying B-rep data structures can support such an operation, or is it just that a Rhino command simply doesn't exist for this operation but that one could in theory be added? Melding two surfaces together seems like such an intrinsic capability.

In the mean time, I'll try to rejigger my toolset to work with the 2 grouped but not-yet-combined surfaces as far as I can.

Thanks again,

- Bob

Permalink Reply by neobobkrause on September 1, 2016 at 1:58pm

The test case that I've presented in the original posting has been greatly simplified to keep the focus on merging 2 surfaces into 1. Tom's suggestion that I create a prototypical cell that is then projected as a repeating pattern into a surface won't work in the real-world scenarios that we aspire to. We intend to use field vectors and other attractor tools to synthesize organic-seeming surfaces. Again, think of multiple ripple waves propagating across a watery surface. The interface where these real world surfaces intersect don't reduce to a set of cells in any meaningful way.

I might also mention that I submitted a Rhino support ticket of this problem that didn't mention Grasshopper. But I was unable to implement the workaround solution they suggested solely using Grasshopper components. The general gist of the workaround was along the lines of...

* ever so slightly rescale 1 of the input surfaces (Scale2D by 0.998)

* Cap both input surfaces to create solids

* BooleanUnion the input solids

* ExtractSrf to remove the caps of the union surface

* Manually cull all remaining top and bottom facing surfaces using extractSrf

But this process can't be translated to a Grasshopper algorithm because GH is not as functionally complete. There is no Extract Surface component, for example.

Though I'm fairly new to the Rhino ecosystem, I have several years experience working with other design tools. While appreciating the mathematical challenges of generating an intersection of 2 surfaces just slightly off pitch from each other, my sense is that my requirements aren't unreasonable, so long as I'm willing to adapt my algorithmic strategy. My challenge at this point is finding a strategy or set of strategies given Rhino/GH's strengths and limitations.

Thanks for any inputs that will help me find a functional solution.

- Bob

Permalink Reply by peter fotiadis on September 2, 2016 at 4:24am

Given the opportunity ... have in mind that doing business with GH is in fact 2 things (unlike Generative Components where (b) is actually the way to work):

(a) working with native components (and/or add on stuff)

(b) working via code (for available Methods see SDK).

In general whilst a lot of things are possible via (a) pretty much anything is possible via (b) [like what you describe, for instance] ... provided that the Method(s) in question exist and is/are carried over in R/GH SDK's. Personally for a vast variety of reasons I work solely via (b).

Note: GH is a-cyclic by nature.

Note: Rhino is NOT a solid modeller nor supports feature modelling. This means that when you arrive in a closed polysurface (a "solid" according Rhino) ... that's pretty much the end of the road whilst in solid modellers is just the start. Each one on his own game, you know.

BTW: By "extract surface" you mean get some underlying BrepFace surface or get some BrepFace out of a Brep? (both easily doable).

Permalink Reply by neobobkrause on September 2, 2016 at 7:32am

Peter,

You suggest that what I'm trying to accomplish is very doable. Can you say more? What approach would you use? Do you see a workable solution in A?

Yes, both (A) and (B) are options. But a few things I need to keep in mind are that, 1) I'm the only tool guy on this project, and 2) I need to generate results in my application domain - and Rhino, Grasshopper and my own code are tools, not results. If I spend all my time developing tools (or learning how to develop tools) then we're never going to get across the finish line. I can perhaps take a longer view on my tool investment once I have the "core" functionality in place. But I'm not there yet.

I've mapped out the various algorithms I would use for each task of the toolset I'm developing. For example merging surfaces was supposed to simply involve intersection/split/cull/join. That intersection operations don't always return complete, accurate and usable results throws my plans into the air. Data flow programming of genetic algorithms fits my background of 30 years programming and 5 years of 3D design. Diving more deeply into the underlying math of B-rep geometry is a rabbit hole I didn't budget falling into.

You bring up other architectures like solid modeling and features. R/GH are just 2 of many, many tools I've looked at to achieve my goals. No single tool or ecosystem looks complete enough to meet all my needs. My prior stop on my quest was OnShape. I found much to appreciate there, but it's still VERY early in their development. (I personally think they are a decade away from having a solution worth investing in.) R/GH seems fairly mature, but I'm already hitting walls like this. There are always struggles and never an ideal solution.

Thanks for your insights,

- Bob

Permalink Reply by peter fotiadis on September 2, 2016 at 8:07am

Bob,

I never said "very doable" ... I said "anything is possible via option (b)".

That said truth of the matter is that regardless of any level of ability (and/or knowledge of coding and/or whatever) IF the platform is "unsuitable" (or there's others more suitable) then disproportional amount of effort is obviously required for the same sort of result (or "similar"). And well ... er ... if the design goal is solid modelling ... chances are that a surface modeller MAY classify as unsuitable (but may not depending on the case).

Given the opportunity: Personal data: strictly AEC sector, AECOSim/Microstation (25 years, main BIM/General CAD purpose app) + various vertical Bentley Systems AEC apps + Generative Components (~10 years, main Parametric app) + CATIA/NX (20 years, main MCAD app) + Quest3D (~10 years, main VR app) + ... + you name it.

UGLY news: I run a practice > this means that I'm used in evaluating/addressing problems having TEAMS in mind, budget, alternatives, deadlines, clients, study guarantees, claims, clauses ... > this means that I'm often very bad/off-topic if an one man show task requires some opinion/solution/workflow.

Anyway ...

... with regard your issue I'll provide an indicative approach after this w/e ... but chances are that would be carried over exclusively without native components.

best, Peter

Permalink Reply by neobobkrause on September 2, 2016 at 12:37pm

I have a Rhino support ticket open on this topic because, just like the Brep | Brep GH component, the Rhino Intersect command returns an incomplete set of curves for those regions where the brep's are close to being coincident. Rhino development engineers are aware of the issue, but have yet to come up with a plan for improving the current flawed implementation.

My beef is that the current process is returning an incomplete set of intersection curves that excludes these ambiguous regions guarantees that the results returned by the Intersect command will be unusable in situations like mine. It seems to me that a new implementation should choose ANY curve through the ambiguous region so long as both endpoints of the chosen curve connect to the curve generated outside the region and that the curve not be kinky. I further suggest that the Intersect command have a NoPunt option that controls whether the results not include curves through ambiguous regions (Punt), or do as I suggest whereby any suitable curve be generated so that the results are always usable (NoPunt).

- Bob

Permalink Reply by peter fotiadis on September 3, 2016 at 12:11am

BTW: Do you have symmetrical stuff in mind? (guide "surface") if yes and since R takes ages to finish (any "solid" opp takes ages to finish) the recommended way is to create a seed "collection" of typical modules > make them instance definitions and "spread" them accordingly. This is especially true if the design is some sort of AEC (an envelope or something similar) where modular objects is the only way to go.

BTW: Is this a decorative object? if yes there's always the danger "getting lost in translation": chasing details that nobody can see/appreciate plus use a surface modeller and attempt to do stuff that clearly fall into the solid modeling territory.

A metaphor (a bit cynical): Imagine the thing in Bilbao and that "unfortunate" Titanium skin. It's probably WOW from a distance but getting closer ... well ... you realize that the best option is to stay away.

Permalink Reply by neobobkrause on September 3, 2016 at 9:16am

Do you have symmetrical stuff in mind?

I understand what you're suggesting. There may well be some surfaces that have symmetric elements. But the overall esthetic we're going for is organic. The toolset that this algorithm is a member of are each designed with Photoshop filters in mind. The goal is to always generate output suitable as input to other tools in the set. A tool that distributes "cells" of prototypical shapes across a surface or volume is interesting. But we also have requirements for this tool I'm currently working on to generate textures synthesized from interference patterns.

The point you're making about unnecessary fidelity is very valid. The fabrication processes only offer so much resolution. Distance from the eye further reduces the need for exactness. Funny, I had the experience you describe when I visited Bilbao a few summers back.

Thanks again Peter for continuing to give this challenge thought.

- Bob

Permalink Reply by peter fotiadis on September 3, 2016 at 11:50am

Well ... it's another Leonidas VS Xerxes case (either way you can't win) therefor ... it's worth ...er ...

1. Lies/Fake promises first (all pros do that Sir): a complete instance definition thingy is ready (i.e. an existed thingy minus sensitive code). This gets Geometry Base type of (rather complex) stuff and makes the modules (a bit useless mind since you are after "organic" shapes [life sucks]):

2. More lies/fake promises: well ... what about using a milling tool (the "negative" of a given module) that removes stuff from a blob instead of creating mini blobs? The advantage is that this can be made even outside GH/R (in an emergency) and then spawn a family of "tools" (say via Morphing Methods [8 available: Maelstrom is the freakiest - see SDK]). And if little details here and there spoil the party ... do the Bilbao thing. And who's gonna notice the little details? And if he does so what? (that was intentional Sir: roughness is our style).

more soon.

Permalink Reply by neobobkrause on September 3, 2016 at 11:30pm

Milling. That did it. Thank you Peter for the suggestion.

I'm enclosing a GH algorithm that takes surfaces an inputs. The first 2 are spatially interlaced. The third is an optional interior surface used to carve out the center volume of the output closed brep with the target exterior texture.

The math for achieving this "milled" result is very straightforward. I'm really quite surprised that Rhino fails so miserably when we try to construct a closed brep using boundary surfaces but works like a dream when milling out a simple bounding box.

- Bob

Attachments:

MilledTexture.gh, 23 KB

Permalink Reply by peter fotiadis on September 4, 2016 at 12:58am

Well ...

That's indeed a far more pragmatic approach... and if this is a decorative object STOP RIGHT NOW > who cares about radii/fillets and all? (not the consumer anyway - don't get lost in the translation [was a nice movie that one]). If on the other hand that was a stadium envelope in Planet Utopia ... well ... a few "changes" in the approach are recommended.

The solution works because doing boolean is one thing whilst making a "stitched" smooth (fillets) closed thing (working in a surface modeller, that is) is a totally different animal. That said when working with solids is highly recommended to try to think the MCAD way (always remove stuff using tmp solids instead of creating stuff).

Anyway if you still want fillets > find a friend who knows a thing or two about CATIA/NX/Microstation > select all the edges to fillet > job done > get the money and run.

Moral: always load your gun with the right size of bullets (and always have a loaded gun ready).