Triangulated Mesh from Isocurves intersection

Replies to This Discussion

Permalink Reply by Luis Fraguada on July 9, 2009 at 10:40am

You might need to cross reference the intersect component. Once you do that, I am not sure what the organization of the points will be...something related to how you have the curves organized. Study this in order to understand how to organize the points for the Srf4Pt component.

Permalink Reply by Damien Alomar on July 9, 2009 at 5:50pm

I would actually advise against working from intersections and curves, since those have a tendency to become unorganized. Since you have the U and V parameters, I would suggest generating the points directly from those. The result will be ordered, and therefore much easier to generate panels from. With some quick list sorting, generating an even pattern of tri-panels is pretty quick. For some more involved patterns you'd have to spend sometime with the list sorting, but as it stands it gets the job done.

Attachments:

• triangulateSrf.ghx, 316 KB

Permalink Reply by Luis Fraguada on July 10, 2009 at 3:51am

Here is a version using the intersection points. In the case here, the intersections do not come back to us in any weird sort of way. Damien's advice is sound. Succumbing to the organization of the intersection component is probably not a great idea, unless you are sure you know how your curves are organized. I plugged in the last part of Damien's definition to show that the points are actually organized in a very similar manner, but again, this is a fairly benign example and his version depends on a lesser number of components which is usually good practice. He also never goes into curves, which memory wise might come into play in giant definitions.

Attachments:

• triSrf_int+Damien.ghx, 325 KB

Permalink Reply by Damien Alomar on July 11, 2009 at 8:01am

Interesting to see the other definition. I actually figured that the intersections would be alright in this case, because of the order and lack of complexity, but if you get burned once.... One thing that I did notice was a very subtle, but pivotal part of the definition was flattening the result from the intersection component. Is it just me or does anyone else find themselves flattening a lot of components in order to get more usable tree structures? Also, it seams creating an individual path for each unique intersection seams rather counter productive. One path with all the intersections from each A curve would make a bit more sense it would seam.

Permalink Reply by Arthur Mamou-Mani on July 10, 2009 at 10:20am

Thanks a lot guys it's very very useful..
Is there a "trim" function in GH that you could apply to the final outcome (so that you don't always end up with rectangular surfaces) ?

Permalink Reply by Damien Alomar on July 11, 2009 at 8:07am

There is no "trim" function, simply because the hardest part of trimming things parametrically is determining which portion to keep and which to throw away. Splitting objects (ie not throwing anything away) is done pretty easy in VB.Net if you have two breps. In this case (an untrimmed, single surface brep), there's a relatively accessible sdk function that can be used if you've got a curve instead of another brep. The output of that function could be modified to return back all the pieces just like split operation. Then you could sort through the pieces yourself.

Permalink Reply by Arthur Mamou-Mani on July 13, 2009 at 7:51am

Thanks Damien,
This must be basic but what is an sdk function?
Splitting doesn't exist on GH and has to be done as VB.net?

Permalink Reply by Damien Alomar on July 13, 2009 at 1:44pm

An SDK function is something that's within the SDK that's "wrapped up" in an easy to use form. For instance lofting has an SDK function, so all you have to do is some setup, pass some information to that function, and you'll get lofted surfaces back. If that didn't exist it wouldn't prevent you from creating a loft, it would just mean you would have to figure out how to do so yourself (which is no trivial task).

The lack of a simple "trim" function doesn't mean that you can't trim, it just means that you have to do a lot of leg work yourself to get it done. It also means that you would have to understand BRep topologies VERY well, and that's something that requires time to understand and master.

Essentially it would all have to be coded through the SDK. Whether that's something that's done within a scripting component or by David, the tool is by in large the same. Obviously David would have many more options in terms of how you would interact with a fully fledged Trim component, but both would have to trim brep A with curve B and using the SDK to do it.

Permalink Reply by Arthur Mamou-Mani on July 15, 2009 at 10:15am

Thanks a lot Damien, it sounds like it might be faster for me to do it manualy for now...
I am trying to mesh the end result of the defintion that you and Luis have compiled and although the resulting surfaces are triangles, when you mesh them, they subdivide into many faces (see image)...

Would you know why this happens and is there a way to get clean triangles as an outcome of this defintion or maybe directly a mesh?

thanks again,

Arthur

Permalink Reply by Stuart Fingerhut on September 29, 2009 at 7:34am

thanks to you both for for the deffs supplied. Damien's first deff turned out to be exactly what i was hoping to accomplish but would have never been able to. many thanks!