I noticed that the RevitColumn Slanted only has one input for Level, while the RevitColumn Vertical has inputs for both the (Base)Level and TopLevel (including offsets).
The Vertical is perfectly according to our BIM standards, so that’s nice. However, for the Slanted column it now appears with the same Base and Top Level in Revit, while we would like to have a similar approach as for the Vertical.
Current implementation
Preferred implementation
Now my question is if the current implementation was chosen deliberately and why? And would it be possible to have a TopLevel input, similar as for the vertical column?
One small additional remark is that the RevitColumn Vertical is placed under the Architecture tab in Grasshopper, while both the Vertical and Slanted are considered as Structural Columns in Revit.
No real good reasons for not setting the top level in slanted columns, I’ve just added it!
Do you think the offsets are needed too? Currently, they get automatically calculated from the baseline endpoint and level height.
P.S.
I think Vertical columns in Revit can be either architectural or structural, while the Slanted only structural, hence the separation
Alright, nice! Regarding the offsets, I actually prefer that they automatically get calculated. Currently the slanted columns also get generated as endpoint driven, not angle driven. So I can imagine that trying to get the offsets right with manual input might be a bit tricky from GH. However, it’s a different approach than with the Vertical. So I leave the choice with you.
Haha alright. I guess we structural engineers just love our columns so much we want them to be included in our family
Would it be good to use the same approach for vertical columns? So users have the option to only define a line and the offsets are automatically calculated in Revit?
If a user sends several vertical columns like this:
The current implementation is mostly driven by Revit API internals (vertical columns are point-based, slanted are line-based) but since Spekcle always sends them with a baseline we could totally calculate offsets from its endpoints, if that’s how most people like to model…
We would have to remove the offset inputs in this case form the GH node.
No strong preference from our team, cc @Reynold_Chan !
For structural engineers it’s common practice to connect the (base)lines of beams and columns to each other, primarily for the use of structural analysis models. So basically you start with column baselines that are most of the times from level to level. In Speckle 1, and now in Speckle 2, I used to compute the offsets by evaluating floor thicknesses and beam heights as inputs for the offsets. So with this in mind it would add an extra step in the script to adjust the endpoints of the baselines using those offsets.
So to conclude, I think for the vertical columns I prefer the offsets how they’re currently implemented.
Regarding the slanted columns I’m not sure yet. I think that adjusting the offset parameters affects the angle of the endpoint driven slanted column, which is definitely not what you want. Will have look into this maybe later this week. For now, the current implementation without inputs for offsets is fine.
Users should be able to easily control the offsets for vertical columns if they want to so I don’t think the offsets should be removed from the GH node.
It might be an option to add a “RevitColumn Vertical by line” object (on the right side in the screenshot below) so users can choose the method they prefer. Just like there are multiple options to define a Revit wall. I’m not aware of current user requests for this feature and I think it’s merely a nice to have but I thought I share it just in case.
