testing for surface curve intersection

Replies to This Discussion

Permalink Reply by Damien Alomar on June 19, 2009 at 10:17pm

All surfaces in Rhino (and therefore grasshopper) are Breps. There are single surface Breps which are what we think of as surfaces and what the surface component allows you to select. For some reason these are always passed to the scripting component as a Brep. My guess is that David has to treat them as Breps in all the rest of the components anyway, so surfaces are always considered internally by GH as breps. The long and short of it is you don't have a choice...you have to deal with them as Breps no matter what they are.

There is a method for intersecting Breps and Curves. Its in the RhUtil Class (which is extremely useful...get familiar with it) and called RhinoCurveBrepIntersect. The good part is that you don't have to deal with OnX_EVENTs. The method just requires that you pass in an array for the created curves and an array for created points. The method itself returns a boolean so that you can tell whether there was an intersection or not without digging through the arrays to find out.

Since you are working with untrimmed surfaces, you *could* "extract" that surface from the brep and use the IntersectSurface method on the curve and question (this is probably the method you were looking to use). A Brep is really just a collection of other objects (2d+3d curves and surfaces) that make up a single object, so if you just extract the first surface of the Brep, you should get what you need for this ( m_S(0) )

An OnX_Event is a special class that is used to describe intersections with curves. In fact its very light because it only contains limited information about the intersection; specifically parameters on the curve(s) in question. When Brep/Brep intersections are calculated, there are a number of potential conditions that could wind up happening, so its easier to deal with the actual objects created. With any sort of curve intersection (either with itself, another curve, or a surface), the resulting intersection can be defined as either a parameter (resulting in a point) on the curve, or a subsection of the curve (represented by a start and end parameter). Therefore, its easier, and much less intensive for Rhino to think of those intersections as just parameters. It can also give some more specific information about the intersection itself.

Working with OnX_Events on a basic level isn't too hard. Basically an OnX_EVENT gets added to an array for each unique intersection. The first thing you might want to do is use the IsPointEvent method just to check that the intersection in question is just a point instead of an overlap. Then you just grab the first parameter in the m_a property and test the original curve (the one you called the method on, not the one supplied as an argument) to see where exactly that point like in 3d space

There's a lot here, so let me know if you have more questions or need some examples. Its not really that hard its just seams cumbersome if you're not familiar with it.

-Damien

Permalink Reply by Gabriel on June 20, 2009 at 12:54pm

thanks. that's very helpful. I typically search within the .NET sdk chm file and I don't always know which way to go with things.

Permalink Reply by Dirk Anderson on June 19, 2009 at 10:50pm

Following on from Damien's reply - the RhUtil.RhinoCurveBrepIntersect(inCrv, inBrep, tolerance, resultCrv, resultPt) may result either in a curve array (if the curve / brep were co-incident) and a point array (if the curve / brep intersect).
here's an example to test the number of intersections - I've had to convert a sphere to a nurbs and then Brep to test but it will give you an indication of the method.



Dim tol As Double = doc.AbsoluteTolerance()

Dim arrPt As New List (Of On3dPoint)
arrPt.Add(New On3dPoint(0, 0, 0))
arrPt.Add(New On3dPoint(0, 10, 0))

Dim nc As New OnNurbsCurve
nc.CreateClampedUniformNurbs(3, 2, arrPt.ToArray())

Dim cenPt As New On3dPoint(1, 5, 0)
Dim tSphere As New OnSphere(cenPt, radius)
Dim tSrf As New OnNurbsSurface
tSphere.GetNurbForm(tSrf)
Dim tBrep As New OnBrep
tSrf.BrepForm(tBrep)

Dim intPt As New On3dPointArray
Dim intCrv(0) As OnCurve
RhUtil.RhinoCurveBrepIntersect(nc, tBrep, tol, intCrv, intPt)
Dim intCount As Int32 = intPt.Count()
If (intCount < 1) Then
Print("No Point Intersections")
Else
Print(intCount & " Point Intersections")
End If

A = intPt
B = intCrv

Permalink Reply by Gabriel on June 20, 2009 at 12:54pm

thanks dirk

Permalink Reply by Gabriel on June 26, 2009 at 11:09am

back at this again after finding that my visual componet methods are not working - here's my mod to your script which is also not returning the right data

For Each srf As onbrep In x
count = 0

For Each crv As oncurve In y
Dim intPt As New On3dPointArray
Dim intCrv(0) As OnCurve

RhUtil.RhinoCurveBrepIntersect(crv, srf, tol, intCrv, intPt)

Dim intCount As Int32 = intPt.Count()
count = count + intCount
Next

ints.Add(count)
Next

anything obviously off? I need to go through a list of curves to make sure that none of them intersect...and I'm using a count int to do this....

Permalink Reply by Gabriel on June 26, 2009 at 1:28pm

here are the files - I have tried both a vb component and gh native components and something funny is going on. I feel like I've tried everything, which probably means it's something really minor that I've overlooked

Attachments:

• trim-problem-02.3dm, 703 KB
• trim-test-05.ghx, 240 KB

Permalink Reply by Gabriel on June 26, 2009 at 2:04pm

ok, so I found that i was able to get the vb going when I changed this line:
Dim intCount As Int32 = intPt.Count()
to
Dim intCount As Int32 = intPt.sizeofarray

now, a question has arisen about how to control the ordering of trimed surface that you get when you split a brep in vb....I can't figure this one out...

Permalink Reply by Damien Alomar on June 28, 2009 at 10:56am

The count will always be the physical number of items in the array. Since we humans generally count starting at 1, and arrays start counting at 0, the Count property will always be one more than the index of the last item in the array. Sizeofarray is analogous to the Ubound function in VBscript which gives the largest index in the array.

Anyway, back to your question, there is no control of the order, and you should most certainly not assume one. The best thing to do is have some sort of means of testing which section of the surface in question is the one that you want. So if you have a point that lies on the section of the surface you want to keep, you can test the distance of that point to the closest point for each split surface. The surface which yields a distance of 0 (or something very very small), then you can assume that that part of the surface is the one you want to keep. There are a few other ways of doing this, but that's one of the more straight forward ones.

-Damien

Permalink Reply by Gabriel on June 28, 2009 at 2:15pm

Hey Damien

I am still struggling - I thought I solved the problem, my solution working on a simplified version of the design problem but moving to the real scenario, things break down. Intersections don't seem to be occurring where they should and my guess is that it may have something to do with the surface and the curve not lying on the same plane. I tried projecting the curve onto the surfaces but that isn't happening either.

Maybe you can suggest something. I have a screen grab of the surface posing the problems and the one that works. Also the definition file and the base file.

As for your idea about how to pick the right portion of the split, I get it in principle, I just have to figure out where the sample point will be on a surface like the one I'm working with...

thanks and hopefully this problem isn't

as daunting for you as it has been to me,...

Attachments:

• trim-test-06c.ghx, 637 KB
• trim-problem-01.3dm, 1.3 MB

Permalink Reply by Damien Alomar on June 28, 2009 at 10:27pm

Its a little late for me, so I'll take a closer look at it tomorrow, but when you're dealing with the SDK you'll have to pay a much closer attention to tolerances than you do when you're working in Rhino. I would actually say that in Rhino the curve probably does lie on the surface, but at a certain tolerance that might not be the case. Plus, kinky curves like the realworld example seams to have will be much less likely to play nice than a single curve will. Again, i'll try and take a look at this tomorrow to get you back some more specific info.

-Damien

Permalink Reply by Gabriel on June 29, 2009 at 11:10am

thanks Damien. I've been hung up on this one for a long time now and it would be good to know whether or not there's something I can do about it...

Permalink Reply by Damien Alomar on July 3, 2009 at 8:53am

Can you explain a little bit more about what you're trying to do with this definition. I assume its a doing some sort of panelized trim from the base surface, correct? I'm looking at you're definition, but I don't think that its organized enough to do this efficiently. I'm reconstructing it so that it's a little more concise, and hopefully a little easier to sort out where the intersections are happening and what might be the issues with trimming them.

At the moment, I think that you may have to take care of the projections and trimming yourself, rather than projecting in GH and using those curves to trim in a VB component later. Organization is a part of this, but also some of the projections aren't showing up and it will should make sorting out which areas of the surface to keep a little bit easier as well.

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page