Solid Intersection (SInt) fail?

Replies to This Discussion

Permalink Reply by Joseph Oster on September 21, 2015 at 5:33am

So...  GH can't measure the displacement of a submarine unless the periscope remains above the surface?

This is INSANE!!!!!  For me, this might be the straw that breaks the camel's back, in terms of taking GH seriously as a programming tool.  It fights back every step of the way, throwing obstacle after obstacle in the path of practical solutions for real world problems.

Permalink Reply by David Rutten on September 21, 2015 at 5:38am

Grasshopper uses Rhino geometry functionality. If you run a BooleanIntersection command on two shapes, one of which is inside the other nothing happens either. I'm not saying that is the best thing for it to do, but that is what happens and if Grasshopper is supposed to act differently then I need to specifically add a bunch of extra code that handles special cases.

Permalink Reply by David Rutten on September 21, 2015 at 5:46am

The attached file has a BooleanIntersection method which -when an intersection fails- determines whether one shape was entirely within the other and then returns the shape instead of null.

Attachments:

• SpecialIntersection.gh, 6 KB

Permalink Reply by Joseph Oster on September 21, 2015 at 7:37am

'SpecialIntersection.gh' works well, thank you very much!  How about replacing the defective 'SInt' with it?

I must say this though...  When I replaced 'SInt' with this new code, the "fast solver" failed all the time.  So I reverted to 'SInt' and it still failed all the time!  So I went back to your original version of the solver code and it still failed all the time!!  Finally, I tried the version of the demo I shared with you via DropBox.  That works.  The new 'SpecialIntersection' code fixes the problem of sinking the boat.  Thank you again VERY MUCH!

But I have no idea why one copy works and one copy fails.  No way to compare source code, no clue where the difference is.  Code rot.  It's what happens when flailing around helplessly, trying every wild and crazy work around to what should have worked properly in the first place ('SInt').  And it's not just the code that suffers, the brain rots too when faced with irrational results.

Continued...  When I modified the full version of my hydrostatics code to use this new, better version of 'SInt', it failed.  At first, it was because I renamed the 'A' output to 'belowSrfc' - oops, fixed that.  So now it fails in a different way.  And I have NO CLUE why it fails.  This is a programmer's nightmare.

Permalink Reply by Joseph Oster on September 21, 2015 at 7:57am

P.S.  There is a difference in the tree data structure output that breaks 'PathMapper' (though I'm not sure yet if that explains the fast solver failure):

Permalink Reply by Joseph Oster on September 21, 2015 at 5:54am

I noticed that Rhino fails at this intersection as well.  While that may take the heat off of GH as the culprit, this kind of thing happens over and over and over...  A ridiculous amount of effort required to create widgets and tools that fail so many ways they are useless to anyone but their creator.  FRUSTRATED!!!  Weeks of time lost to the simplest things.

Thanks for 'SpecialIntersection.gh', I'll check it out.

Permalink Reply by Pieter Segeren on September 21, 2015 at 6:13am

If the submarine is fully submerged you can get its volume, right?

Permalink Reply by Joseph Oster on September 21, 2015 at 6:19am

How am I supposed to know it's fully submerged?

This came up when using David's "fast solver" code, which works GREAT until it tries a Z-offset value that "sinks the boat", at which point the results make no sense so the solver fails.

Much easier, and more correct (?) to fix the Rhino intersection failure.  It's a bug!

Permalink Reply by David Rutten on September 21, 2015 at 8:06am

I think it does indeed make more sense to return the inner object when a Solid Intersection fails to return a result. That is more consistent with the mathematical idea of a solid intersection. I can see why Rhino itself would treat this as a null-result, since it's less confusing for nothing to happen rather than for the outer shape to disappear if one invokes this functionality manually. But from a programming point of view it is not consistent, and without consistency it's very difficult to design algorithms.

Permalink Reply by David Rutten on September 21, 2015 at 8:28am

I just modified the code for Grasshopper 1.0 in Rhino WIP so that the intersection behaviour is as discussed. Doesn't help you right now, but if you are subscribed to the WIP then the next update (this week probably?) will feature the new functionality. This is technically a breaking change for Grasshopper, so let's hope the different behaviour doesn't screw anyone over.

Permalink Reply by Joseph Oster on September 21, 2015 at 8:52am

Awesome!  As noted, the difference in data tree output(?) will break subsequent code that expected the old...  When I fixed that in my code, all the cases that previously broke the "fast solver" now work!!

Oh, there was one exception due to a different bug noted here recently:

Wrong result from Bounding Box

When I added some pitch along with roll, this error caused the new intersection code to fail (and probably the old 'SInt' as well).  To deal with this, I added an arbitrary 10 units to X, Y and Z of the 'BBox' bottom corner and to X and Y of its diagonal opposite at the top, expanding the 'Volume' box in all directions except the water's surface.

Extraordinary measures for something so basic and simple, in concept at least.

Permalink Reply by Joseph Oster on September 21, 2015 at 9:12am

Data tree output that will break subsequent code ("{0}" vs. "{0;0}"):

Attachments:

• sint_2015_Sep21b.gh, 11 KB

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