Revit API Forum
Welcome to Autodesk’s Revit API Forums. Share your knowledge, ask questions, and explore popular Revit API topics.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

New in-place created family instance has wrong origin (0,0,0) until moved

Message 1 of 9
1731 Views, 8 Replies

New in-place created family instance has wrong origin (0,0,0) until moved



I am experiencing the following strange problem. I am creating an in-place element as described in this article. The element is created far away from the document base point/origin. However, if at this point I run a CustomExporter and I read this element's Transform, it says that it is the Identity transforms, i.e. Origin is (0,0,0) which is not true.


Inspecting the family instance with Revit Lookup shows the same wrong origin (BeforeMove.png)BeforeMove.pngAfterMove.png


After I move the element somewhere, its Origin is now correct, i.e. not zero.


Steps to reproduce:

1. Open the attached InPlaceFamilyWrongOrigin.rvt file

2. Select the only element in the project, i.e. the in-place created element (ElementId: 202108)

3. From Revit Lookup -> Snoop Current Selection -> GetTransform -> Origin: shows (0,0,0), when it is clearly visible that the element is not at the document's origin, i.e. the blue symbol.

4. Slightly move the element with the mouse in any direction.

5. From Revit Lookup -> Snoop Current Selection -> GetTransform -> Origin: shows the correct origin, i.e. different from zero.


We experience the same problem when the user creates an in-place family and then we export data from Revit. All in-place created families which were never moved appear in the document origin, because the Revit API call to GetTransforms always returns the Identity Transform.


Labels (4)
Message 2 of 9

Draw a circle around the internal origin to represent the origin of the in-place family before moved (creation position), move the family and the circle together i.e. 2' east and 2' south. The transform will report the relative movement not the distance between internal origin and the square geometry.


This tells us that no matter where the in-place family is created it's origin at the time of creation will be the internal origin i.e. why are you assuming the origin should be something such as the centroid of the family? If I were placing a table the centroid would be half way up the legs. You need to create the geometry around the internal origin and move it to where it should be if you want the origin of the in place family to mean something (it doesn't have to). You can reset the origin by placing two crossing reference planes in the family and setting their 'Defines Origin' property to true.


As a user in-place families were always a last resort. It's not true to say they don't have an origin. It's just to use it in a meaningful way you likely have to first create the family out of place or redefine the origin with ref planes (not something the average user will be doing).



Message 3 of 9
in reply to: RPTHOMAS108

Should also note that if you reset the origin with refplanes as noted above then the transform origin becomes zero for where it is (perhaps not that useful). The location point property however gives the offset from internal origin.

Message 4 of 9

Actually, I am the developer that does the export from Revit, I am not the actual user. When the user creates, let's say two different family instances in-place and he clearly sees in his Revit Viewport that they are at different places, it is kind of weird that when I start my export (V-Ray for Revit) and I ask Revit about each instance Transform it simply returns the Identity Transform, which is not correct. I can clearly see that the two instances are are at different places.


Take a look at the following picture: TwoInstances.png


This is what I see in the Revit Viewport. One Family is exactly at the document origin and the other is not. Right? When I start to render these two families, i.e. through IExportContext, I receive the Identity Transform for both families and of course I render them both one over another at the origin, while clearly that is not the case. When I move the upper-right family slightly, its Origin becomes correct, i.e. something different than zero. If now I render this scene everything is correct. The origin was zero, I moved the family with 1 pixel to a random direction and suddenly the origin is no longer zero, but the correct value, i.e. (1,2,3), not (0,0,0).


I hope I was able to explain this again.

Message 5 of 9

So you have two instances of the same in-place family one created at origin and one copied from that to a new position. I don't understand how anything you've stated about that arrangement would contradict what I've noted above.


The in-place family is created within the coordinate system of the model so it can have no other relationship to internal origin (unless it's redefined with refplanes after creation). If you want to distinguish between the two items you'll need to look at the location of it's geometry not a fictitious origin point that doesn't exist because it wasn't defined when the family was created. Have a look at the top face of the instance geometry in RevitLookup (second non-empty solid, first face). See how the face origin differs between the two locations. The transform origin defined for this instance geometry is 0 for the original i.e. no translation and non-zero in the relocated version.


Face origin locations:

(2, 3, 1) original
(2.9409954570458, 0.412262493124049, 1) relocated



If you match my second location you'll also see that the transform origin is:

(0.940995457045799, -2.58773750687595, 0)

i.e. the amount I move it from where it started not the distance it is from internal origin.



To state that the origin is correct after movement is probably not the case have you dimensioned that to check? A non zero value alone isn't indicative of a corrected value (in terms of your understanding of what it should mean).

Message 6 of 9

I trust you and I know that what you are saying is correct.


So my problem/question boil down to the followig:


During Revit export, i.e. through the IExportContext, is there any way to determine the location of the family with reference to the project origin, so that I know where to render my element. In the OnInstanceBegin method of the IExportContext I read the transform of the InstanceNode like this: var transform = node.GetTransform(); For all normal elements I receive a meaningful Transform that tells me how far away from the project origin the instance is. Only when the instance is this in-place created family I always receive Transform.Identity.


My question then is simple. Is there a Revit API to read the location of this family as I see it  with my eyes in the Revit  viewport. There either is a way to do this through the API or not and that is what I need to know.


Thanks in advance.

Message 7 of 9

I suppose what I don't understand about your question is where does the geometry coordinate information come from? You have the transform which is identity meaning no transformation (so long as the family hasn't been moved after creation). Therefore knowing that the transform is identity for both locations the coords of the instance geometry must already be relative to the internal point, doesn't need to be transformed and is already not the same. Where are the points for geometry that you transform coming from?


Message 8 of 9



What would you expect the origin of the element to be?

The most lowest X/Y/Z coordinate?, A user family can have a origin far away from any geometry.


If you need to know the position of geometry INSIDE the element, inspect the Geometry...

Geometry Property  And evaluate it's faces, lines etc.


I've never used IExportContext, but in the InstanceNode there's a GetSymbolId method, from which you could inspect the geometry inside the family.



Message 9 of 9

I managed to come with a workaround by reading BoundingBox.Min, if that helps anyone.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Customer Advisory Groups

Rail Community