I am trying to use a Georeferenced OBJ prepared from an external source.
I import the OBJ file into the prepared Rhino setup file (created by Proving Ground App plugin) This works fine, and the OBJ in Rhino is in its correct world coordinates based on the correct coordinate system.
I have tried two methods to get this OBJ mesh to Revit, one using DirectShape from the Rhino.Inside plugin, and also from the Conveyor V4 plugin.
Using direct shape, the world coordinates are preserved and the mesh inserts in Revit in the correct coordinates, however the mesh is unusable and looksâŚâvoxelised?â or at least it is very cubic and not at all usable. I have tried many operations to smooth and repair the mesh but it remains unusable in RevitâŚthe only thing is that the coordinates are maintained.
Using Conveyor mesh to revit, the mesh is perfect, I mean its beautifulâŚbut the world coordinates are just ignored and the mesh inserts based on the center of the mesh object (or possibly the file extents midpoint) and that midpoint or center of the mesh is just dropped onto my Revit Internal Origin point (or Revit 0,0) the Z elevation is maintained however but X,Y are transformed to Revit 0,0.
I am trying to find a workaround for this, but the problem is that the actual OBJ in Rhino is already in the correct location, so there is no point moving it. The transformation of coordinates happens at the actual file insertion.
Iâm hoping there will be a way to fix this but I have not been able to find oneâŚ
The mesh quality in Rhino is actually fine. Its however Revit processes this mesh, I believe that Conveyor leverages OpenNURBS but I dont really know much about how the back end processing into Revit changes it but Conveyor is able to build a very clean mesh in Revit, but direct shape does not.
I have tried cleaning the mesh multiple ways, I tried mesh repair, and also rebuild mesh with grasshopper, The resulting mesh inside of Revit is always bad when using direct shape (or in this case direct mesh)
The first image is the resulting mesh in Revit from Rhino.inside direct mesh, and the second is the exact same mesh coming through Conveyor plugin. You can see in section the second mesh is very clean for cutting sections and working with. The first is just chunky cubes.
when you look at Top view, what are your mesh coordinates values in Rhino?
Please note that Revit only implements a space inside a cube of 10 miles in each direction. If you try to import anything outside this cube, it´ll get constrained as you describe it - center to center. If your data stretch across 10 miles, it´ll probably be refused at import.
In general it´s good practice to set up models so that they sit in the first quadrant (+X/+Y) close to 0,0,0 in Rhino. We move it so that our 0,0,0 point in Rhino represents some nice-looking real-world coordinates. It is also very handy to add some elements (model lines) directly to 0,0,0 point in Rhino that you can always use them as a reference for snapping in Revit.
Autodesk uses shared coordinates for DWG import/export, but that´s not the case for Rhino.Inside.Revit.
Hi Pavel, thanks for your answer.
This is somewhat true, but directshape will in fact throw an element in its correct coordinates even if it is outside of this Revit âradiusâ you will get warnings in Revit but it will do it.
In this case though, I have also tried inheriting coordinates from a georeferenced DWG file in Revit and this sets the internal origin of revit to the correct coordinate system.
You can see in the image below that my 0,0,0 in revit is actually quite close to my final output coordinates which are quite large. But the problem still remains that only conveyor sets the x,y plane to 0,0 and it does at the last step of processing so no amount of manipulating coordinates before processing seems to matter. In rhino my coordinates are correct. In revit the reset to default import 0,0 (elevation is kept at the correct value) only X, Y get reset to 0.
In the image the branch of tunnel (shown twice) should be up in the top part of the image, I have highlighted the project base point which shows that the georeference coordinates are inherited, and all 3 Revit points are on top of each other (Survey point, Project Base Point, and Internal Origin). But the internal origin still reads as (0,0) if I decompose the vector from that point. You can see the branch slapped right in the middle onto that internal origin, which is where Conveyor puts it.
Hi Pavel,
I found a solution to this problem which is just moving the geometry that is created by Conveyor after it is created in the project.
I posted the solution here where I was asking a different but related question.
It has to do with how Rhino sees the points inside of Revit, even though the Revit internal Origin might be moved around to an actual coordinate - which is the case when I use a shared site by acquiring coordinates from a georeferenced site file that has a coordinate system set to it.
So the Revit 0,0,0 might not be a true 0,0,0. The way I dealt with it was to calculate a resulting vector from 2 points by inputting the actual coordinates of the internal origin and creating a reference point on it. It might also be possible to extract these directly from the âpropertiesâ of the base points in revit but I just did it manually by copy pasting the coordinates straight from revit into number inputs to create a point.
Anyhow it took me a while to work out what was going on between the two programs, but yes it seems to me that the internal origin can be at a point that is not actual 0,0,0 but Rhino will see it as 0,0,0
In the end the solution was post-processing the resulting geometry which is annoying but not that complicated.
For the version of RiR, I am not sure how to check it, but this is the .msi file name I used to install
RhinoInside.Revit_1.18.8780.17023
It was only a recent install so I would assume it probably recent enough to cover the changes? looks like 1.18?
As for the mesh, I can share it, do you just want the mesh or the entire script? (I am using some Proving Ground components in the script)
Thanks for taking the time to check the mesh Scott.
Indeed, its been challenging from many angles, and it looks like you have sliced it into a smaller portion to process it, that is also the approach we have taken now, because I mentioned to our team that the file size was too large to deal with in big portions.
Thatâs very interesting, I had not thought about it being a challenge because of Revit.
As I mentioned as for Rhino.inside direct mesh does keep the coordinates in tact, but usually I would create a project file with a georeferenced location in it (which then moves the internal origin) at which point I have a process to bring it to Rhino zero, and then push it back to the correct coordinates which are close to my internal origin of revit.
If I do this directly into Revit with the shared coordinates already inhereted it will push the Rhino form to the same distance from Revit internal origin, as though it considers this internal origin as 0,0,0 (although once shared coordinates are used, this is no longer the case)
What I find odd is that Conveyor processes this well but Rhino makes a mess of it (in R2024)
What is conveyor doing differently that means it processes correctly?
I just tested this out in 2023 on my end, and I am getting similar result however to earlier. Its not really useable and does not resemble what you have there.
Did you bring to rhino zero or something before processing? Iâm wondering if its just a computational issue being so far away from the origin?
I did try moving it to Rhino zero (Still in Revit 2023) and it worked no problem, so part of the problem is 100% computational because of large distance. Next test will be to see if this resolves in 2024 with the same script.
Part 3 - Test the same script in Revit 2024
Yep, as I suspected it works just fine if I push coordinates to 0,0. Exactly same result as part 2 above in the image.
So I suspect how Conveyor is getting around this is by creating the object in a family (which it creates at 0,0 in that family dropping centroid onto the insertion point of the family) So the mesh is NOT being created in the project at this far away distance and so it is not having the same computational issue as direct mesh!
Interesting result, thanks for sending me down this path Scottd. AlthoughâŚIâm not sure exactly how I am going to deal with the coordinates issue, and how this will resolve once I move the Revit internal origin but this is stuff I can test and work around.
So now that I got this to move to the correct position and create the mesh (without turning to poop mesh)
What I wanted to test and manage is the name of the object created.
I can see both times I created the mesh, once with directshape mesh and also directshape geometry worked, AND the naming âworkedâ in that if I mouse over the object it shows me the name, BUT I can not find this name reflected in the actual data of this object at all. Familly name and the Type name do not contain it.
Thanks for that,
So last question and then I will let this thread dieâŚ
Why canât I extract the âactualâ coordinates of the Revit Internal Origin?
Why is there a difference between the extracted built in paramater of the survey point E/W & N/S values
compared to if I just use âBase Pointâ and deconstruct the point? And why canât I access the E/W & N/S values of the internal origin?
Because in the method I have found I am relying on the fact that my survey point and internal origin are in the same place.
Seems like the coordinate issues are starting to be addressed.
The core of the âmesh poopâ problem is one of accuracy of the vertex points in a mesh. Many mesh models are single precision vertex locations. Single Precision numbers can only take 8 or 9 significant digits. Some mesh formats are single and some are double precision.
In this case the imported mesh is so far away from the origin that only single precision mesh location leads to errors in conversion of numbers to the 0s and 1s that a computer uses. This will be true for essentially every CAD program out there, Revit being no exception.
The key is to move the objects closer to 0,0,0, so internally they are actually stored close to the origin point. Then use the Survey Point and Project Base Point in Revit to place items that may seem to be far away.
the reason for different reading in GH panel is probably tolerances, as parameter in Revit is most probably rounded value of the very same coordinates you see when picking point directly and deconstructing XYZ.
As these point coordinates are not exactly the same, they are very close ⌠4.5e-9 is 0.0000000045, that is practically zero, and in Revit - based on project units - the âzeroâ can be even found at 0.0001 m.
The Revit internal origin has always coordinates 0,0,0. No way to change that. Below you can find a bit of explanation.
More can be found at Autodesk help site.
As Scott mentioned, it is very handy to get geometry closer to 0,0,0 point in both Rhino and Revit so that math behind the scene has its life easier.
