DirectShape - slow / weird behavior in latest release

[Matthew_Breau]

We’re experiencing a few interesting issues with the latest Rhino 7 and RhinoInsideRevit, wanted to share in case they are bugs. To troubleshoot, we did a clean re-install of the latest Rhino 7 and RIR.

1st Issue:
The GeoDShape component is having some issues with where it creates geometry in the Revit file. We are trying to move a facade from Rhino into Revit, and 40% of the geometry are appearing 100’ below where they should. The geometry is all “closed solid polysurfaces” and appears to be well-formed (no bad geometry). Exploding the geometry causes it the resulting surfaces to appear in the correct location. Rejoining any of those surfaces causes the resulting polysurfaces to appear at the wrong location again.

2nd Issue:
Previously when we’d used the GDShape component, it was really quick, but in the new release it seems so be very slow. It seems like each shape that is being moved over is getting exported as an .SAT file and saved to a temporary location (as shown). Regardless of whether the geometry is a tree or a list, this is happening one piece of geometry at a time, with each one taking about 5 seconds. With 700 pieces of geometry, it can therefore take 10-15 minutes easily. Each operation is showing up in the Rhino command line as this happens (as shown in the screenshot below). Is this something that can be turned off?

[Matthew_Breau]

It seems like these behaviors may have been caused by the code changes in this commit, going off of the release notes…

Rhino Inside Github - Release notes

Is there a way to download an installer from December 11th, to test?

[scottd (Scott Davidson)]

Can you send us the object that you are trying to move into Revit? Yes, there are a number of changes in the latest build about geometry translation.

[Matthew_Breau]

Thanks Scott, the Rhino file is too large to attach, but I created dropbox link:

201221 RIR Issue

We’re using Revit 2020 (I confirmed this occurs even in a new Revit project). Other than that its just selecting all of the glass in the rhino file, and a bare minimum GH definition. you can see both the .SAT conversion and the position issue in the screenshot below.

[scottd (Scott Davidson)]

I tested this and see the problem, sort of. So I reported it:

This Rhino to Revit Box uses the SAT transfer and not the native transfer

[Rickson]

A component with the previous setup would be welcome.

[Rickson]

Not seeing anything in the latest release. Workaround seems to be to convert all breps to mesh before going to direct shapes.

[scottd (Scott Davidson)]

Because Directshapes are the only elements that can take meshes. So, this only effects Directshapes?

[Rickson]

Yup, The family creation with the same Geometry works with that fails in Geometry Direct Shape.

[kike (Kike Garcia)]

Hi @Rickson,

I’m testing with your sample models and panel 11 to take one that “fails” is using SAT also when using the ‘New Component Family’ component.

Both components use same conversion routines, there are not two diferent ways of convertig BREPs.

The issue with your model is that some breps contain short edges. Rhino.Inside is still not able to clean those edges and in that case it falls back to an old file IO operation through SAT that is much slower but do that cleaning for you.

While we don’t have this automatic cleaning, we decided to add a remark ballon on the component that process geometry like this informing the user we are using SAT and why. I hope this helps.

[Rickson]

Those weren’t my geometries, regardless things are working as expected for me with latest build. Thanks for the efforts.

[kike (Kike Garcia)]

Ups sorry about the confusion @Rickson, and thanks for your help here in the forum.

We are working in something like this.

The idea is try to transfer the geometry as it is, if it fails because the geometry is not as “clean” as Revits needs, the component will show the reason as accurate as we can and will do a SAT export-import operation.

• Issues will be highlighted on the geometry in orange.
• Since the edge is too small it is shown as a point.
• This is part of the component preview, if you turn the component preview off this also goes away from screen.

[kike (Kike Garcia)]

It’s released.

Now components that convert geometry from Brep to Solid may show those warnings.

We also added automatic short-edge transfer but it will show a warning that reads like this:

Geometry contains short edges.
Geometry with short edges may not be as reliable as fully valid geometry.

It’s a warning, the geometry should transfer anyway now if this is the only issue on the geometry.

[Rickson]

Very helpful, thanks.

[odysseas.georgiou (Ody)]

Hi Kike,

following the latest release, elements that get the warning of being “short” or “out of tolerance”, are misplaced in Revit. (Direct Shape preview in Rhino also shows them on a wrong position)

This only seems to happen using a previously generated Revit model (deleting old elements and replacing them with new ones in the same project)

Seems like a bug?

Thanks!

[kike (Kike Garcia)]

Looks like

Could you please share just this stair here?

[odysseas.georgiou (Ody)]

Attached r7 stairs.3dm (223.8 KB)

Thanks!

[odysseas.georgiou (Ody)]

@kike just found out (if it helps) that it somehow conflicts with the level creation inside Rhino. If these are deleted prior to generating the element then it is placed correctly

[Michael_Howard (Michael)]

I posted this in another thread but no one responded so posting my issue here

recently updated RhinoInside Revit and am experincing performance issues. I see that SATs are being used now to convert tricky geometry, and it looks like more geometry is being converted reliably to solids which is great. But I’m also experiencing a huge drop in performance (60x slower) depending on which Revit model I am in.

When I open a blank Revit file, I can import this geometry in about 2.7 minutes - great.

However, when I open up a live BIM 360 model that has lots of other geometry and views set up already, and attempt to import the same geometry with the same script, it takes 2 hours

I don’t know why there is a huge variation in time. When importing the model in the BIM 360 model, I do see the Revit progress bar refreshing fairly slowly generating graphics for 3D views, over and over again, it seems like it might be refreshing every time an SAT file is made?

Any help on this would be really appreciated - thank you!

[scottd (Scott Davidson)]

Yes, this is all related to this whole conversion process.

If Revit rejects the BREPs from Rhino, then we move to use SAT transfer which is slower because it moves thru actual temp files.

I expect the reason the BIM360 is so much slower is the Temp files are being pushed all the way into the BOM360 store. They probably should be in a local temp directory. Kike will need to look at this.

We continue to try and avoid the SAT process because of the speed. This takes time as we improve moving geometry transfer into Revit.