Testing for solids with non closed geometric volume

[Anonymous]

I am trying to run a SolidCurveIntersection on a solid and curve of various families. Most everything that I throw at it works well, and I am able to get the results I need from 

solid.IntersectWithCurve(curve, opt);

I quickly realized that solids needed to be closed geometric volumes or you would get an ArgumentException error. To defend against that, I simply avoided sending any solids that did not have a volume greater than 0. And that seemed to work for a while. However, I am now seeing a situation where my input solid has a volume of 15.75. Other than a try/catch statement, is there any way to test ahead of time if my input solid is going to be valid or not? 

Thanks

[jeremytammik]

Dear Pat,

Thank you for your query.

I am not aware of any other way to check the validity of the input solid.

Can you identify any anomaly with it, and special characteristics?

Where does it come from?

Can you simply handle the exception and move on, or does this cause a major disturbance for you?

If it is important for you and you would like to provide a minimal reproducible case, I can pass that on to the development team for closer analysis:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

I hope this helps.

Best regards,

Jeremy

[Anonymous · Accepted solution]

Thanks Jeremy for the fast response. The family is a manufacturer provided mechanical equipment. It is quite complex on the geometry side. It contains various extrusions, and CAD elements with other CAD elements nested within. All in all, while analyzing the geometry it probably contains about 20,000 linear references in the form of either edges, or lines. If I had to guess, the offending solid is probably from one of these CAD imports within the family. I'm happy to attach that family for further study, but it is not necessary to have a resolution on my end. I'm thinking of just making a simple helper method that tries to run a generic SolidCurveIntersection within a try/catch. If an exception is caught, I will not run my more expensive (and real) SolidCurveIntersection method.

Here is that helper method:

private static bool EnsureEnclosedSolid(Solid solid, Curve curve)
        {
            try
            {
                SolidCurveIntersection intersection = solid.IntersectWithCurve(curve, new SolidCurveIntersectionOptions());
            }
            catch { return false; }
            return true;
        }

What do you think about this? I'm not sure it can be improved any, but am open to suggestions.

On the analysis side of things. My method of obtaining the solid is pretty standard as far as I'm concerned. My options class looks like this:

Options opt = new Options()
            {
                ComputeReferences = false,
                IncludeNonVisibleObjects = false,
                View = doc.ActiveView
            };

And I am obtaining the solid either through:

GeometryElement gElem = gi.GetInstanceGeometry();

or from the GeometryObject directly if it happens to be a solid.

I can confirm that the offending solid is coming from the GeometryInstance obtained from :

GeometryElement gElem = gi.GetInstanceGeometry();

I think for my use, this scenario may by be a fringe case. So i'm not too concerned about it. It would be interesting to know why it is happening, but not critical. 

Thanks for your help and input

-Pat

[jeremytammik]

Hi Pat,

Thank you for the explanation and background.

I am glad you can happily work around it.

Your solution looks perfectly OK to me, except for one thing:

Never catch all exceptions!

Just specify the exact exception that you are expecting, and leave all other exceptions alone.

Here is more on that:

http://thebuildingcoder.typepad.com/blog/2017/02/revitlookup-using-reflection-for-cross-version-comp...

Cheers,

Jeremy

[Anonymous]

Great, Thanks Jeremy. I will take your advice and only catch what I am expecting. After reading through your links, it makes perfect sense.