This is a toned down version but it gets my point across. If I select the same face (the top of a rectangular column) with two different methods, I’m getting two totally different batches of information. I have a script that works perfectly until I and the Data Shape interface. My reinforcing comes in 300’ away. I have found that this is only an issue when a coordinate system is assigned to the project. Just not sure how to adjust for it.
Not an answer, just another question:
What is the element ID of the face you get from the “lower” method in your graph?
Can you use a method (such as “Equals” node) to compare if you are actually selecting the same face?
If I add an == to compare the two surfaces, it states it’s false. Not sure how that’s possible.
I am not familiar with Data Shapes, but I would expand the output portion of all the node (or add watch nodes) to see what is coming into and out of each node so we can compare with a little more insight.
I have to say that I have not tried to run a single script with multiple selected inputs. (I know that is not your eventual intent, and this is just a demonstration of the two methods.)
As you’ve noticed, geometry values are relative to the internal origin and do not reflect their position within the project coordinate system. Without digging into Mostafa’s code, I’m guessing he just takes care of the translation for you. Data-Shapes is returning the location within the project coordinate system so you don’t have to do that step manually.
If you open the Data-Shapes node and check out the logic, you should be able to confirm this is the case.
I would have thought that as well. Per Joe’s request, I’ve expanded all of the panels. I’m just selecting the top face of a rectangular column and getting different results. You can see the column selected and the top face without Data Shapes. Then you can see only the face on the left out in space.
Actually you don’t see it in the graph. Sorry.
I find the == doesn’t compare quite a lot of stuff so I translate it into something else, usually a string and compare.
Geometry is not comparable so that doesn’t really matter. You’d have to somehow tie the geometry back to the element to “prove” it’s the same face.
Just check to see if the translation is equal to the coordinate offset. If it is, you know it’s just the translation. If it’s not, then we have a different problem.
I’m sorry for being difficult, but what do you mean by translation?
Geometry comparison is not an exact science. For points and lines it’s easy enough, but for anything beyond that you’re going to vary quite a bit on things which to you me and a 3D printer will all be the same. The difference is in how they are defined. Say you have 3 surfaces built by patching rectangles composed of the following points:
And then you move each rectangle by the following vectors:
The resulting surfaces will all look exactly the same. However if you test the translated rectangles against the originals you will find none of them are the same, even though the first two rectangles were not moved by the zero length vectors. And further if you compare the translated rectangles to each other none of the two are the same - even though rectangle 1 and 3 have the same corners points in the exact same order.
This is because the equality test is only capable of asking ‘is this the same thing we had before’. As soon as you put any modifier on it, the geometry is an alteration, and therefore not the same.
So if you want to test if geometry A is the same as geometry B we can use Geometry.IsAlmostEqualTo in place of the == node and get better results, with the translated shapes all being equal to each other:
And so if your test is ==, then it’s likely that two ‘select face’ nodes will return ‘false’ even if you select the same face with each node, as == isn’t built for this type of comparison:
But if you Geometry.AlmostEqualTo you will sometimes get better results:
But as geometry comparison isn’t an exact science, you also will sometimes not get what you’re after:
The take away: Don’t assume you’re working with the same object when you’re not dealing with references to the object in question (this is why Revit’s dimensioning is done the way it is). And so that is where conversion to a stable reference comes into play - something we can look at and known for certainty that this is within N degrees of each other. String.FromObject will sometimes work, but ToSolidDef (or if you’re in Dynamo 3.0 or later a stringified json object):
No worries. You probably already know a lot of this, but I’ll try to lay everything out for clarity’s sake.
Revit has multiple coordinate systems: the internal coordinate system (referenced by the internal origin), the shared coordinate system (referenced by the survey point), and the local/project coordinate system (referenced by the project base point). The project base point is mostly just so we have nice, neat numbers to work with. The other two systems actually define spatial relationships across files and model content.
Geometry is built off the internal coordinate system. Any translation (offset or rotation) to the Revit model or linked files by a shared coordinate system is then applied to all objects at the project level. This is easier to understand with links, as any instance of a link will be defined by the same geometry and coordinates but can be placed at any location or rotation within a model for a different, project specific “location”. Both of those coordinate systems then define exactly where any given element is located within a project’s coordinate systems.
In your case, Dynamo is returning the geometry’s location, which uses internal coordinates. The issue here is that the element’s location is also being affected by the project’s shared coordinate system. So in order to get the geometry’s location relative to where it’s located within the project, you need to apply the same (inverse) translation to the geometry as the shared coordinate system is applying to the object.
Thanks for the information Jacob! It’s obviously not the same face that’s being selected. Just when I thought I was understanding Dynamo.
Nick, I truly appreciate you education today! What would that look like from a node standpoint?
I’m pretty sure there are some custom nodes that can get you the translation directly, but there are a handful of ways to go about “calculating” it.
You should be able to find some examples in the forum. This is the first one I found after a quick search. You’re essentially just getting the location of the survey point and using that (or its inverse) to get the vector to (or from) the translation.
That being said, depending on what you’re trying to do with your graph, you may not need to do any of this. The Data-Shapes output is likely the format you want if you’re trying to relate this surface to its location within the project coordinates.
