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?
Thanks Scott, the Rhino file is too large to attach, but I created dropbox link:
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.
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.
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.
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)
@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
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?
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.
