Missing Geometry while Instantiating Families

J_Irawan · November 26, 2019, 4:35pm

Hi McNeel Team and @kike,

Great to see you last week. I’m following up with an issue we encountered in migrating panels from Rhino/GH to Revit. The script is similar to that of those posted to instantiate families in Revit. Screenshot Below:

The workflow we’ve opted out for is to categorise the rhino geometry by its material for revit. This would then be referenced to instantiate a family based on Material in the revit file. While doing this, we noticed that some of the geometry refused to transfer over to the revit space. See examples below:

Could please advise why it might be doing this?

Best Regards,
Jonathan

kike · November 26, 2019, 6:24pm

Hi,

May I have access to this model?
At least part of it just to do some test here.

Thanks,

scottd · November 30, 2019, 11:17pm

Normally the rejected geometry has to do with breps not closing properly. If we can look at the geometry directly we are trying to learn what gets rejected by Revit.

J_Irawan · December 2, 2019, 2:27pm

Sorry for the late reply Kike and Scott,

I did do an initial diagnosis on the model to make sure that all polysrf were closed properly and found no apparent errors.

Please find a wetransfer link to the RhinoWIP file here:

Cheers,
J

scottd · December 2, 2019, 4:45pm

I did an initial run as directshape and I get this:

Let me get a Family definition running on this. Normally the component family approach deals with Geometry just a bit different.

scottd · December 2, 2019, 4:56pm

Can you send me the GH definition you are using. I ran the attached definition and made a big single family Generic Model type and everything came in perfect.

Does the attached definition work for you?

family-demo.gh (66.5 KB)

J_Irawan · December 2, 2019, 5:15pm

Hi @scottd,

Please find the gh def here:
RhinoInside_Workflow.gh (64.6 KB)

I used a very similar definition to the one you’ve provided. Using the new attached definition you’ve sent, i’m still getting the same error. See screenshots here:

You can still see on the top row that the blades are missing. I’ve also tried to just set the missing blade as an individual brep and it seems to recognise it as a normal object.

As a summary - i’m taking the slab geometry and existing facade from revit to give me a position in Rhino. That coordinate is then used to translate the facade modelled in Rhino to then instantiate families in Revit.

Cheers,
J

scottd · December 2, 2019, 5:24pm

Now that I am oriented correctly, I see the fins that are not coming through. I am not exactly sure why.

I was able to fix the blades by explode > Rebuild (4 points degree 3) > then join. You can do them all at once. Now they come in.

We will take a close look at where the confusion is with the original geometry you sent. It has something to do with edge tolerances.

J_Irawan · December 3, 2019, 11:08am

Thanks Scott.
Is it worthwhile implementing a series of components to rebuild the geometry via GH as a standard practice then? Is that a better workflow moving forward?

scottd · December 3, 2019, 3:48pm

We need to look at the specific geometry and see if we can do any adjustments automatically. We are still learning what sets Revit off.

kike · December 3, 2019, 6:35pm

Hi,

If you explode the blade you will found a tiny face in the corner.

If you remove that face Revit will accept that BREP as you see in green.

How do you think we can help to found those little defects?

J_Irawan · December 5, 2019, 10:08am

Hi Kike,

Thanks for spotting this. I’ve spoken to the project team who are mostly doing the modelling in Rhino and they’re now aware of the issue.

The difficulty in finding these faces is that they still count as closed breps even if they exist.

Cheers,
J

scottd · December 8, 2019, 6:41pm

Nice find. This seems like the standard limitation in Revit of edges that cannot be less then 1 mm. I am looking at thread and see if it helps in this case: Zero-Length Edges

scottd · December 8, 2019, 6:53pm

Pascal’s Zero length edge finder from above works to find the edge. We may add it to the utilities we can use to check Breps in the future.