How do I set room height for Room Tag in GF Plan in Revit?



Hi all,

I’m calling all Dynamo and Revit Masters to help me with the Problems I faced from the past 2 years and still haven’t got the answer. And yet I thought I have to thrown this topics to the masteeeeerrrsss.

Can someone advice me if I want to make a ‘script’ in dynamo to make them read the room heights on each level? See below the picture:

Because since 2 years I have to write them down in a parameter that I made, but the problem with this ‘manual system’ is that by any mistakes (when you less concentrate) you would do some mistakes when you’re not double check from section. I would bet with the dynamo script it would minimize the mistakes or even accurately written in the tags.

If some masters of dynamo or some software freaks could help, would meaaaaannsss a lot!
Thank you in advance for any tips!




Hi, you can try with Room.Finishes from Clockwork Package to get the ceiling of the room. Then I projected the room base point to the ceiling, got the distance and used it to set the parameter of the room.

In order to “find” the ceiling, the initial room height must be bigger, otherwise there is no intersection.

Hope to have been helpful!


Room.boundaries and then pull the ceiling and floor elevations, getting the difference (subtract) and taking the absolute value (Math.Absolute) and use that value to set the room height parameter will also work. Minimizing geometry work (ray bounce) will keep the graph running faster.


@JacobSmall with Room.Boundaries you don’t get the ceiling of the room, am I wrong? And even if you manage to get the ceiling for every room, you need to find the bottom elevation.

Anyway I updated the graph for multiple rooms and multiple levels and it works apparently great.


Hi there @JacobSmall
Hi there @lucamanzoni

I am afraid what luca said was right about the Room.Boundaries, unfortunately they don’t get the ceiling of the room, that’s why I said we have to set it manually.

And Luca, thanks for your graph! Will try it immediately and let you know if it works!!

Thank you so much!!!



if you activate volume computations you get this



@m.rijsmus I’m not sure to understand, what exactly do I get?
The strategy is to get the element related to faceType “Top”. In the graph I posted it was a Floor, in yours is a Ceiling.


Thats because in my model there is no Floor :slight_smile:
I just wanted to show how to get the Ceiling as a bounding element


Ok, I see. The graph should work anyway, because the selection is based on faceType Top, whatever is the element that is bounding your room (might be a roof as well) :wink:


Yes, enabling volumetric room calculations will give you the floors and ceiling elements which bind the room. Adding each elements level elevation and offset distance will then give you the elevation. Then use a list.minimumitem and a list.maximumitem and subtract the two, and you have the room’s height.

May have an issue of you have a floor as an upper boundary, in which case you would have to subtract the floor’s thickness of the ceiling wasn’t the upper level.

Sounds like a lot of work but avoiding geometry work can save a lot of time. Keeping the data types simple this way will make your graphs run faster long term.


as a side note

i set my room heights level to level so electical fixtures lights and stuff above the ceiling will report in the room


@JacobSmall I see your point and you are correct, but actually it’s not so easy.
Let’s say we want the free height (and not the level to level height):

  • If you have only floors, you can directly use “Elevation at Bottom”, but it doesn’t work with ceilings.
  • If you have only floors and ceilings, you can use “Height offset from Level”: it works great for ceilings, but for floors you need to subtract the thickness of the floor and it doesn’t work for roofs.
  • If you have ExtrusionRoof and FootPrintRoof you could use “Base Offset from Level”, but actually it doesn’t work and anyway it’s a not a valid parameter for ceilings and floors.

Converting elements to geometry might be slower but the script remains easy and (so far) always working


Fair point that I failed to take into account sloped roofs.

Perhaps an Element.BoundingBox then? From there get the Z values from the BoundingBox.MinPoint and the BoundingBox.MaxPoint and find the difference.

Again all of this isn’t to say the ray trace method is bad, but that it may have some issues as you scale it.


Here the graph with Bounding Box.MinPoint instead of Point.Project as @JacobSmall suggested :wink:


Just to close the topic, I run a test on 100 rooms with 6 different heights.

  • Point.Project: 25.38 s
  • Bounding.Box: 24.83 s

Maybe there’s still some possible improvement somewhere, but at the end the result is acceptable.


Great work!

The other advantage of a geometric solution is that you can orbit around the Dynamo result and actually see where funny results are coming out.

Any real life project will have an odd room with a particular bulkhead or soffit because we didn’t coordinate something or the client had a crazy demand.

This is why I don’t see visual programming as any way inferior to full programming… Our schemes are 3D and we need to understand them in that way.

Sorry for the ramble :slight_smile:



You want to post a sample model so that we can potentially improve that? Not a guarantee, but would be a good benchmark if someone wanted to optimize this.


Yes of course, here are the files. Thank you!

RoomHeightTestFile.rvt (1.9 MB)
GetRoomHeight_BB.dyn (16.0 KB)
GetRoomHeight_Project.dyn (16.2 KB)