Coordinate System

1

Hello,
I am trying to get a face on a family instance of structural column category. I can get it through the method of (GetGeometryObjectFromReference). I then get the face perimeter with the method (GetEdgesAsCurveLoops). It appears that the curves are not in the correct place because of the family coordinate system. When I make the transform to fix this, everything goes very well unless my family instance column is cut by a floor or a wall. In case the column is cut, it gives the curves in the wrong locations. I then can get the correct locations only without the coordinate system transform. Does anyone have an explanation?
Please see the video in the link for more details. I create walls depending on the selected face.
Thank you.

2

Another way to ask, how can I check whether the geometry I get from the family instance is transformed or not. Anyone?

3

how about this from GeniusLoci?
by checking the Origin from the transform you got?

image
image800Ă—428 68.5 KB

1 Like
4

Unfortunately, It is only for Linked Elements. I have checked the transform’s origin with another node but it gives the family instance current origin. So, It makes no difference.

6

Use BimorphNodes LinkElements. Problem solved.

2 Likes
8

That isn’t correct. There are major differences if you use BimorphNodes LinkElements relating to performance, stability and memory allocation:

Dynamo’s geometry engine is extremely inefficient. The user could be waiting for potentially hours while Dynamo:

  1. Extracts, converts (creates) and stores the extracted element geometry on memory, and
  2. Duplicates it to the transformed location, consuming double the memory.

The above memory allocation then persists throughout the lifetime of the application - you cant dispose of the geometry from step 1 since the graph needs it for step 2. Couple this with the myriad of other memory demands a script will invariably need, and the differences becomes more stark.

In addition, due to the high memory demands, there is a risk the application will crash beyond a certain limit of elements, and that limit isn’t very large for the reason mentioned above.

In contrast:

  1. BimorphNodes LinkElements only use Revit API calls to perform the solid transformation and the Revit API is written in C++ so its extremely performant, plus it manages memory intensive objects like solids more efficiently than Dynamo’s ProtoGeometry library. The comparison in performance for this one step alone is significant; seconds in the Revit API vs hours (or a crash?) using the ProtoGeometry + RevitNodes APIs.
  2. Dynamo geometry creation of the extracted element geometry is only performed once, not twice, as it doesn’t need to be transformed, so the memory footprint is halved.
  3. The transformed Revit API solids are disposed once geometry conversion is completed, freeing up more memory.
  4. The potential for crashes is significantly reduced and a much higher number of elements can be converted due to the more efficient memory management.
1 Like
10

Of course; I’m indifferent to what packages people use. To me it really isn’t a competition (I actually couldn’t care less to be quite frank!). I was answering the OPs question with a concise solution that’s purpose-built for the problem, with none of the drawbacks that come with trying to solve it using only Dynamo geometry/nodes.