Speed of intersections in GH - optimising solutions

I m running a piece of analysis by way of a GH solution that relies on testing for intersections between elements. It is at this point that i notice the greatest of slowdowns.

Is there any benchmarking or best practice to explain which of the intersection methods is liekly to yield the quickest results?

i.e. vector with BREP faster than line, or line with Brep faster than curve. ....

any thoughts / comments / experience with this?

Replies to This Discussion

Permalink Reply by Luis Fraguada on June 11, 2010 at 4:32am

Mathematical intersections seem to be much faster than Physical ones...

Permalink Reply by David Rutten on June 11, 2010 at 5:46am

Hmm, at the moment I'm 'faking' the mathematical intersections. I'm simply extending the lines through the boundingboxes of the target geometry and then running a physical intersection. Some work is being done on real analytical intersections in Rhino5, so once those functions become available we'll switch behind the scenes.

Mesh intersections can be computed quite quickly, so if you're really strapped for performance, that may prove a fruitful avenue of exploration. The latest Grasshopper has a Mesh-Ray intersection component.

Also, we're hoping to include a threaded, ultra-fast mesh-ray engine into RhinoCommon sometime soon. Steve has been working on this on and off for the past month so hopefully we'll have something to show soon.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Jonathon Broughton on June 11, 2010 at 6:20am

not as a general reply to my own question but ive bent the logic of what i was testing somewhat and combined many lines into closed curves and running tests using those.

intersecting lines with breps is faster than curves with breps by about 20%, but polycurves (closed isn't crucial) with 4 line components joined intersected with breps is almost 350% faster than running all those lines individually.

So even the overhead of the 'decoding' of the results is worth taking the hit on.

For context: I'm intersecting >4000 curves (joined state) with >100 breps at any one time. I'm working out (on paper) a workaround of sequential testing and elimination to see if cumulative tests will result in lower overhead. But its calling for heavy use of path mappers to recombine them all at the end.

RSS