Creating DirectShapes while Skipping Problematic Geometry

Thank you Scott for the explanation! The scale of the elements in the file I shared should be that each frame is around 9 feet by 9 feet. I tested moving frames closer to the origin and that does help - thank you for the tip.

I’m having some trouble with some additional geometry though even when it is close to the origin. You can see in the below, I have 3 frames (each frame is around 9 feet x 9 feet) at the intended size and then the same 3 frames scaled up x10. As you can see in the screenshot once imported, the large frames are missing a face in the below:

and the small frames have all the faces but more are triangulated:

I’ve attached the files for reference. The screenshots are taken with Revit 2019.2 and Rhino WIP 7.0.20238.17095, 08/25/2020
I would have guessed that the scaled up frame would perform better than the smaller frame if there were tolerance issues at fault but I’m surprised that a face is missing. Do you have ideas as to why this might be?
200901_MH_HELP.3dm (649.0 KB) (298.7 KB)

Additionally, it would be great if there was some way to identify which frames had issues (missing faces, triangulated faces, etc) so that I could easily identify the elements in GH after they are created and not have to search manually pan around the Revit model looking through the thousands of frames.

We will need to take a look at this one. We continue to find and try to tune up the transfer tools. There are a lot of geometries that Revit is not accepting of.

I would think a tools that looks for the meshes after the translation would be the best way to find them. I wonder if that is possible thru the Revit API?

No need for the API, the Direct Shape Element Geometry will tell you right away, giving lots of potential workflows.



We could create a scraper here that collects the geometry that does not come across onto a specific layer in Rhino. Perhaps we can find some patterns?

1 Like

So something like this can identify the elements and bake them back into Rhino:

Find failing (12.9 KB)


Thank you both! This is perfect :slight_smile: And a clever way to determine the geometry that had trouble.

1 Like

Hi everyone,

I had a problem that I think is related to the matter of passing geometry directly to Revit.

Both using the Add Brep DirectShape component as well as the Add Geometry Direct shape.

The geometries are all closed solid polysurfaces, however, when passed to Revit, it generates different types of geometries, Open Brep, Untrimed Surface, Trimed surface, Invalid Brep, Closed Brep and Mesh…

Is there a way to fix this?

Breps to (9.3 MB)

I finally got a chance to look at this. There is a problem we have to look at. It has been reported here:

I can tell part of the problem may be scale and how far the object is from 0,0,0. But even after that is still fails in places.

Thank you very much,

I will be attentive to the advances in this regard.

Best regards,

I am having the exact same issue with very simple extruded geometry, right on top of the origin.
Is there an option to roll back to the previous WIP build? It worked fine before.

Can you post a file with a few of the troubling objects and the Grasshopper def? I think @kike will need to look at it.

We have made changes, but they were supposed to help.

Rhino to Revit exporter Debug.3dm (854.0 KB) (16.4 KB)

Thanks for the reply Scott. Please see the attached files.
One group is for translating blocks into Revit geometry (Human Components), the other group is a more straight forward approach for translating simple polysurfaces.

Quick update…
If I deconstruct and re join that geometry, the Add Direct Geometry component suddenly works properly. Perhaps this can shed light on the issue.

I will have more time to look at this tomorrow. But it strikes me if Blocks and Blocks instances are being used in Rhino, would it make sense to make a Component Family out of the block and then insert a type instance in Revit at the locations of the Rhino Block instances? Then the model logic in Rhino would be mirrored in Revit.

The simple Brep translation makes total sense. I like how names-index and materials are also being translated.

That would normally point to a tolerance that was too big when joined. When Tolerance is changed, not all the Breps are updated. But Exploding and rejoining will test for the new tolerance.

Your test here does let me know exactly where to look ato see if it is tolerance. Thank you.

Thanks Scott!
Regarding your note on blocks, I don’t suppose you have a good lead on a tutorial for translating blocks into families do you? Eventually, it would be good to be able to make this work for full assemblies (blocks within blocks).
I’ll stay tuned.

I will try to get to this later today. I am interested myself on the details.

We do not support assemblies in Revit yet. They are less like blocks and more like groups. But we are planning to add them.

The only way I know how to do this is to either us multiple types inserted at the same place, or use subcategories for various parts in an complex family. Here is a process to think about: There is use two families in the “assembly”.

If you want to send in a block or two you are using and the definition to break them down using Human, I can pick it up from there. We can see what we come up with together.

5 posts were split to a new topic: Rhino Blocks to Revit Family Types

4 posts were split to a new topic: Rotate Families in 3d