testing for surface curve intersection

hi

I'm just trying to test for surface curve intersections and I am coming up against a number of problems.

first, my surfaces, though specified with the hint of OnSurface are still coming in as Breps and I can't seem to find an intersection method for Breps and curves. My surfaces are all untrimmed, separate surfaces

the other problems is what an ArrayOnX_EVENT is and how to test is to see if it recorded any intersections - if I can get past the issue of the brep problem I thought I would have an if this ArrayOnX_EVENT.count is greater than 0, then I know there's an intersection...

any ideas. thanks in advance

Replies to This Discussion

Permalink Reply by Gabriel on July 3, 2009 at 11:37am

hmmm, could there be a cap on the number of levels of response? I could only reply here, the "reply to this" button wasn't there for your message...hopefully you get this

Thanks for having a look. You have the basic gist of what I'm trying to achieve - sorting out which panels lie along the perimeter and are not complete and those that intersect this boundary which should then be trimmed again. I'm not sure I follow about problems with concision and organization but I'm listening...One thing I discovered yesterday was that when I ramp up the number of base panels to check, the intersections improve drastically Still problems, and given the number of panels performance, starts to really suffer.

So I'm hearing that you think I should drop the parametric route for stages of this process - I sort of came to that conclusion on my own as well but it's kind of disappointing - I wanted to be able to quickly test different panel sizes and grid layouts and their effects on panels later on in the pipeline. I'm trying to learn from this whole scenario, about what the limitations of working in this mode really are - please let me know if you discover more precisely where the problem lies with what I was trying to do....

big thanks

Permalink Reply by Damien Alomar on July 3, 2009 at 2:19pm

I ran into there not being a reply thing a little while ago as well, so I guess there would be a cap...Anyway, started anew, so it should be better now.

I shouldn't say that there are problems with your organization. Everyone has their own way of going about things, and I'm not one to say that yours is better or worse than mine. I just found it a little hard to dive it your file and figure out what was going on, so I just started from scratch myself. I'm setting up my file in such a way as to minimize how many surfaces are actually projected to and trying to do things in as "light" (computationally) of a way as possible. Its still taking a while to regenerate (and will take even longer once I get to the trimming), but hopefully it will be a little bit quicker than the test file that you posted.

I don't think you need to be dropping using dynamic parameters, and in fact I do so whenever I get a chance to make sure that my solutions work with as many changes as possible. What I would recommend, especially if you're going to be coding things, is finding a way to "section off" pieces of your solution. Disabling rebuild events is kind of a blunt blow to the head in terms of working with a definition. If you start hooking up smaller sections to boolean values that you can toggle on and off, than you can work on one part of the definition while having another section "off". This is very useful for solutions where you don't need it exactly perfectly regenerated each time.

I'm still working on things, so I'll post once I get farther.

Permalink Reply by Gabriel on July 3, 2009 at 3:05pm

I'm always trying to learn new tricks so I was not opposed to hearing about ways of bettering my organization. The file may have been a bit visually messy due to wracking my brains trying to figure out what was going wrong - I tend to leave dead ends on the screen in theory to show that I have already examined a particular approach - in practice it's hard to actually figure out what I've already done without trying it again...

I like the idea of sectioning off parts of the solution - I had asked for this from David and he suggested that this would be available in the future. I guess in the meantime I need to learn about "disabling rebuild events" - I presume this is something to be implemented in vb.net....

Permalink Reply by Damien Alomar on July 5, 2009 at 10:46am

Okay...I've been working on this for a little while now, but trimming is definitely not a very straightforward operation with the SDK. Anyway, after hashing out a few different attempts, I've got an approach that will hopefully work. There's still the last part of putting it all together, but I figured I'd post my progress so you could play around with it if you wanted. This is kind of a lucky situation since its only single face breps and simple trims that are being worked with.

I've attached 3 definitions to this post. The first is my reorganization of your original definition, which creates the surfaces from the point grid and culls out any surfaces that are not "on" the surface so that we don't have to deal with them later down the line. This is done through a small VB component which determines whether any of the corner points lie on the surface. If it does it keeps the surface, if not, then it doesn't. The only issue with this is that in your example file, there are some surfaces which the corner points do not lie on the surface, yet the surface that they create spans the underlying surface. At this point I'm not worrying about those. You mentioned that you only want the surfaces that lie at the edge...this can be done by testing whether all 4 corner points lie on the trimmed surface or not.

The second definition is a coded version of the project function. In the example it will project to all the breps supplied, yet in the final version this probably won't be desired. Also, the direction (z axis) is hard code...this could be swapped out if desired.

The third definition is an shot at trimming a surface with an input curve (that curve happens to be projected). I tried this many ways, but found that the function RhinoCutUpSurface seamed to work alright. The other attempts at doing this directly with through functions available for OnBrep were unsuccessful and very complex. Luckily because the underlying brep is an single, untrimmed surface this function works well for us, but in situations where we have a trimmed or multiface brep we'd be up a creek with out a paddle. The function creates an array of breps, but in our case it will create essentially the same surface split by our curve and joined together as a single brep with two (possibly more) faces. All we have to do is find out which face we want to keep and duplicate that into a separate brep and pass it out of the component. In the example file I'm determining which on to keep based off of the distance from a test point to the centroid of each face.

The other option here, which would trump the need for projection or trimming, would be to extrude the edge curves through the surface in question, and use the BrepSplit function which requires two breps. There would still be the need to sort out what to keep, but if this approach were used, all the split pieces would be separate breps.

So, all the pieces are pretty much working separately, all that I have left to do is put them all together in the base definition. The only thing that is really the hump with that is determining exactly which face to keep. My idea at the moment is to find out which corner of the surface does not like on the base surface and use that to determine which face will be thrown out. This might be one of the easier ways, but will not be rock solid. The other option is to pull a test point that's on one of the faces to the base surface and the other face, then use the distance from test point to the point on the base surface and the distance to the pulled point on the other face to the base surface to figure out which one to keep.

As to sectioning off parts of the solution, you could do this in a number of ways, but here's two simple ones. In a scripting component just add a boolean value to the inputs and put the whole script inside of an if statement that looks at that boolean value. With components just add a boolean gate or a null pattern componet anywhere you want in the stream. Again, hook in a boolean toggle value, and that will stop the info from going to components that are downstream.

Attachments:

Permalink Reply by Gabriel on July 5, 2009 at 1:20pm

Damien, huge thanks.

I haven't had a chance to check out the files just yet but a couple of comments...

"there are some surfaces which the corner points do not lie on the surface, yet the surface that they create spans the underlying surface." there will also be cases where all four corner points lie inside the trimmed surface but whose entire surface does not. But there are bigger issues I guess so we can overlook these. I was working on something else yesterday and points that should have been discovered as lying within the boundary were not bing discovered - I wonder if there are issues in this area of GH....

Dirk had suggested trying out out the RhinoCutupSurface a little while back but he wasn't sure it would be any better and I was intimidated to figure out how to implement it. Glad it works.

And about the boolean toggles - while I have been using GH extensively some of its underlying processes are sometimes beyond me. In the scenarios you laid out, if I were to "cut off" the flow of data would I get the last stream that flowed through or none at all? And what happens to components processing data further upstream - would a boolean false not simply shut down any definition which was dependent on its contribution? If it could still work with this component not constantly procssing I would be golden - I can't tell you how many definitions I have that are crippled by having to re-process information that really isn't changing....

thanks again.

Permalink Reply by Gabriel on July 6, 2009 at 2:01pm

so I looked at your three stages yesterday. I found it a bit tought to get them going but after grafting the projected curves everything seemed to work, mostly. There were still some panels that should have been split but that's ok. Also, I'm still uncertain about how to get the "full" panels which lie on the surface and do not need to be trimed. I had this working on my test surface a while back by searching for panels with all fourcorners ON and NO intersections - the combination of booleans would produce this list. It worked in the generic condition but not when I moved to the actual surface. I tried again to test for intersection events to cull those surfaces from your list which intersect the trim curves but with no success.

Permalink Reply by Damien Alomar on July 20, 2009 at 9:56pm

Sorry for the super long delay on this...I looked at this for quite a while today and determining which face to keep is turning out to be a lot more complex than I thought it would be.

Just trying to see how far the centroids for each face were was not enough to reliably test. It returned the wrong surface half the time and was horrible for little small trims.

The next attempt was to project the centroid along the same vector as the curves were projected. I have absolutely no idea why this is not working in some cases, since the centroids clearly should project to the base surface, but unfortunately they aren't. At least with this approach it doesn't return any incorrect surfaces. I believe doing the projection process manually (creating a line that goes through the surface from the centroid and intersecting that with the surface) would result in an accurate result.

I still have yet to try the 4 corner testing, which I hope would be accurate enough to get the correct result. I still have to figure out the actual steps, so we'll see how easy that is compared to the other version.

Attached is the progress so far...it gets some of the trims but not all of them.

Attachments:

trimSrTrimPanels_full.ghx, 353 KB

Permalink Reply by Gabriel on July 21, 2009 at 7:52pm

works pretty decently already. Like you said it's missing a few panels here and there but overall looks pretty good.

I mod'ed your initial script to create two lists, one for full panels and the other for the trim panels. I needed the full panels ASAP and I figure it should lighten the load on the trim portion of the second vb...unless there's something I overlooked. But it feels a bit faster now...

Dim cullList, cullList2 As New List(Of Boolean)

For i As Integer=0 To s1.Count - 1
cullList.Add(False)
cullList2.Add(False)
Next

'Find if any of the corners lie on the surface
For i As Integer=0 To s1.Count - 1
If blnPtInclude(s1(i)) And blnPtInclude(s2(i)) And blnPtInclude(s3(i)) And blnPtInclude(s4(i)) Then
cullList2(i) = True
cullList(i) = False
Else If blnPtInclude(s1(i)) Or blnPtInclude(s2(i)) Or blnPtInclude(s3(i)) Or blnPtInclude(s4(i)) Then
cullList(i) = True
cullList2(i) = False
Else
cullList(i) = False
cullList2(i) = False
End If
Next

A = cullList
B = cullList2

Permalink Reply by Gabriel on July 21, 2009 at 8:06pm

oh...i just remembered why we needed to trim all...there are cases where all 4 corners lay inside but whose entire surface does not...strange but the technique of adding booleans works - when it didn't before. in face I can skip your entire first step vb and all by just performing mass addition on each list of booleans...

Permalink Reply by Damien Alomar on July 21, 2009 at 8:17pm

You replied while I was writing mine...:)

An addition of booleans does sound interesting. I didn't really know that you could actually "add" booleans, but when you think about them as 1s and 0s it makes perfect sense....I guess if you keep adding booleans, then a surface to keep would equal 4

Permalink Reply by Damien Alomar on July 21, 2009 at 8:14pm

I figured the "I completely lie on the surface" info would be a useful thing to have, but never wound up worrying about it too much. That code looks like its will work well for getting those surfaces into their own "stream". In the definition I posted it probably is faster since I wouldn't have to worry about projecting to those surfaces.

As a note there is the technical possibility that there will still be the need to trim that surface (ie a trim that comes in between two of the points without any of them lying off the surface), but the likelihood of that is fairly slim. If you want to disregard that possibility than I can't really fault you...I've made a number of the same judgment calls in the code so.... :)

Permalink Reply by Gabriel on July 21, 2009 at 10:28pm

this might sound strange - it may very well be..but in the interim I have opted to go for panels of a diamond like shape made out of two triangles...and it's working more or less with what you got started but it totally coughs on the trim vb part. I didn't know that edge srf were trimmed srf or at least my 3 sided ones are. I have a decent understanding of nurbs surfaces but I still thought you could have a three sided surface...just as you can have a sphere....

anyways, any ideas why this might be a problem? what comes out the tail end of your script are a whole mess of surfaces with more surface than what went in ...weird.