Get RevolvedSurface object in family instance

Hello everyone,

I am trying to get to the RevolvedSurface objects in family instances so that I can access their properties (axis, origin, etc.)

Using Element.Geometry on the FamilyInstance list I get the solids. But I did not find a way to go from a solid to the form generating that solid.

Q1: Do I understand correctly that that’s not possible with Element.Geometry?
Q2: Is there another way to get the RevolvedSurface forms contained in a family?


Q1: You do understand correctly. The geometry is the geometry of the element, not the content which creates the geometry.

Q2: I am not sure this is doable in any environment, but I believe you would have to be in the family environment to get the data which you are after.

Why do you want this data? There may be another way if we have more insight into the reasoning.

First off, congratulations!

The goal for this question is to get the origin and axis of the Revolve form for further processing. Let’s say, for placing some geometry at the origin and orienting it according to the axis.

The family (as opposed to the instance) is accessible in Dynamo. So a relevant question is how to get the Revolve form from the family itself. Looking at the Revit API, GetSubelements seems to be the only candidate for getting the objects out that make up a family. Q3: So I suppose a form (revolve or other) is a Subelement of a family, right? I haven’t found a Dynamo node for doing that though. This post discusses Get subelements, although using Python script. Q4: is there a Dynamo node for getting the subelements of a family?

Jacob, I just looked at your profile - gives me hope that you might be able to help with this :smile:

There is a more complex problem I am trying to solve. This post asks a question about an approach that could help solving that problem. A more complete description of the problem, albeit with a slightly different focus is here. That got zero replies so far - I suppose because the question was to general :wink:

You asked what I wanted with the data from the RevolvedSurface. For processing outside of Revit I need to define a point and a vector for some families and extract that data, e.g. export to csv. The RevolvedSurface contains both (origin, axis) and is a good geometrical way of defining them. I’d also like to use the RevolvedSurface forms (and probably other forms) in the families to implement the rotation rig approach here.

In addition to getting the origin and axis out of the RevolvedSurface forms, there is another critical piece of info I hope I can get out of them. The forms are hosted on some part of the geometry of the family. And some nested family is hosted to a face of the (split) RevolvedSurface forms. For a given RevolvedSurface form, the additional info I hope I can get, is the ID of its host as well as the ID of the element hosted on it. Note that in both cases I need the IDs in the scope of the model, not the family. So somehow a mapping needs to be established between these two scopes. The objective behind this is to define relationships between certain family elements (as explained in my other post) for processing their corresponding instances later on.

So, that’s just for background. I think it makes sense to focus on the specific question in this post and create new posts for other well-defined questions of the overall problem.

If you’re in the family environment you can easily get all revolves using the All Elements Of Type node (and of course the Element Types node set to the correct type).
I‘m not sure there’s a way of getting it in the project environment.


Q3: Forms in families are elements in the family environment, but are all a mess of the same ‘geometry’ instance in the family. Note you can’t tab select a part of family geometry in Revit. Nor can you open said family in the project environment and update the geometry. Two different data structures and two different environments for two very different purposes. System families (walls, parts, multi story stairs, etc) are different as all of the data is stored and originated in the project environment. Note they aren’t after the profile lines which make up the nosings in that post - those would require the family environment.

Q4: Not that I am aware of.

My approach to your overall effort would be a bit different, and would start in not Dynamo. First make a new shared parameter called ‘parent’ for each of the sub families in your nested family editor. This would be driven by a formula that ties it to the mark of the parent family.

Now selecting all nested families would be a breeze - all elements of category - get parameter value for parent mark - List.GroupByKey.

You can then get vectors between each of the location points for the grouped families and compare those. Or the facing orientation of the family to find which way each is pointing and compare those. Or… we’ll im still not sure what you’re actually after, but hopefully this helps.

1 Like

Andreas, I checked and was able to get the element with All Elements of Type using the type "Revolution.

I am somewhat disheartened that you are not sure about whether it get be done in the project environment :frowning: I can very well imagine that there isn’t a Dynamo node for it yet. But I was expecting that it would surely be possible with the API, i.e. calling the GetSubelements method on the family, so perhaps requiring a bit of python. I mean, it is possible to get a reference to families (not only instances) in the project environment. So why should it not be possible to do with those family objects whatever is possible in the API?

ad Q3: understood - but (obviously) you can define families such that when you change their instance parameters, their geometry gets updated according to the family definition. So internally Revit uses the family definition very dynamically. Seems only fair that this should also be possible through the API :wink:

Q4: darn - but as long as the elements are obtainable through the API, a new node could be developed, right?

I’ll need some time to think about your alternative suggestion. I agree that there are other options for encoding the point/vector info into the family and extracting it in the project environment. Regarding the relationships I think there is still a missing piece. I think I understand about the parent parameter. But we also need to be able to define relationships between elements that are not in a parent-child relationship.

We are working on a test project to illustrate what we are after. I’ll post here as soon as it’s available.

Many thanks - really appreciated!

Afaik subelements are only available in certain types like stairs and railings.

1 Like

Then let me rephrase that: There is some data structure inside a family that holds the elements that have been created in that family. My question is how I can access that data structure.It seems that the proper way of adding a Revolve form to a family through code would be to call the NewRevolveForms method on the FamilyItemFactory of the respective family. The documentation reads “This object ensures that the elements created are added to the family document correctly.” That is consistent with “All Elements of Type” returning “All elements from the active document…”.

Now we could put these two posts together:

I haven’t tested it but it looks as if this could take us from a family instance to the document in which the family is defined so that we can obtain its elements.

This all seems quite complicated, so I’m wondering whether there is a much simpler approach. Maybe not and looking at their implementation, many Dynamo nodes are hiding away substantial complexity. So maybe this is just a matter of implementing yet another node.


I like your tenacity :slight_smile: if both AD & JS tell me something, the chances are that they are right!

Just a subtley… needing to be in A family environment is not the same as being in The Family… Orchid has nodes for background family opening and getting nested families, you must be in A family environment but you could run it on simultaneously on 1000s of saved out families…

Apologies if this was obvious or not helpful.


Memes aside, you’re working with data that is structured in VERY different ways. While it could be possible, the effort required would be significant, and it may completely stop working at the next Revit update or version… you’re certainly embarking on a noble quest which will result in many epic battles between good and evil and you’ll likely encounter orcs, trolls, and gobllins. You may even be rescued by the Great Eagles of Manwë who’ll pick you up and fly you to safety… I just wonder, would it not be easier to just have the big birds pick you up at the start and fly you the entire way? I mean they’re fast, and capable of the trip right, or at least the bulk of it?

I’m all for a good story, but why not go the other route and end this story in a few paragraphs instead of 6 books (sold as 3 volumes)?

Once you’re tracking the commonality, for defining the relationships between elements, you can get the location (a point, or a line, or many points) for almost any Revit element, and then create vectors between other elements without too much work. FamilyInstance.FacingOrientation, Vector.ByPoints, Vector.AngleWithVector all help towards this end. I’ve actually built graphs that compare the relationship of plumbing fixtures in a given room to determine how many bathroom types are needed for documentation this way.


Just as a quick update for now that we’ve solved our underlying requirement by adding our own ID parameter to the nested families we want to relate and manually assigned values to them when setting up the families that contain instances of these nested families. We then have dedicated nested families for representing these relationships by entering the before mentioned ID values into two parameters defined for that purpose.

The downside of this approach is that we assign the IDs manually and, consequently, that we need to ensure that they are unique. The reason for my question in this post was specifically that the element IDs of the family instances inside the definition of the family definition of the parent already constitute such unique IDs. We could of course semi-automate the process by running an extra script on the family definition that populates the before mentioned ID fields with the element ID values. Would ensure uniqueness in any case. But not worth the trouble for us at this stage, especially because it is not a really nice solution either.

I’m not sure how far the Tolkien allegory caries, nor how helpful it was. I wasn’t trying to solve a particular practical problem but rather find a generic solution for a general problem.

We may get back to this in the future and if we do I’ll try to update here.