BILT Speaker

BILT Speaker
RevitCat - Revit Consultant
Showing posts with label generic. Show all posts
Showing posts with label generic. Show all posts

Saturday, 20 February 2021

Cut with Voids when Loaded in Revit

When this new feature appeared in Revit about 10 years ago (v2012?), it was always a bit mysterious - it had many confusing restrictions about how and when you could use it

So, what is this family property that shows up in the Family Editor in Revit?

Autodesk Help in v2021:

"Cut with Voids When Loaded: When selected, voids created in the family will cut through solids. The following categories can be cut by voids: ceilings, floors, generic models, roofs, structural columns, structural foundations, structural framing, and walls."

That's it - all the help you will get from Autodesk on this one!  It hardly explains much about how to use it.  If you dig deep you might find more information - but there is no link to it.  

It is inaccurate in that it says "voids . . . will cut through solids".  It should say "may cut. . . "
It is also not up to date with its category list.

In Revit the tool-tip is pretty much the same, although it does at least have a diagram that shows why you might want to use it:

This is a classic example of inconsistency in help and tooltips.  I remember during beta testing that we asked for the ability to cut holes in worktops using this new feature - worktops are usually in the "Casework" category, which was not included in the list of cuttable categories.  Luckily it was added as a further enhancement a year or two later - but Casework does not appear in any lists from Autodesk, even though it was used in this illustration.

[Edit] If you dig deeper in the Autodesk Help files under 'Cut Geometry' , it does have an updated list of categories that can be cut by this method:

 "You can cut objects in a project when a family with unattached voids is loaded.

Objects that can be cut include: Walls, Floors, Roofs, Ceilings, and Structural Framing, Structural Columns, Structural Foundations, Casework, Furniture, Specialty Equipment, and Generic Models."

I recently had a requirement to use this "new" feature in a Revit family - but I could not get it to work.  So I decided to revisit exactly how to make it work:

How does it work?

  • A void form has to be created in a Revit family

  • Tick the "Cut with Voids When Loaded" checkbox in the family parameters
  • The category of the family is not relevant to this feature

  • Load the family into a project
  • Place the family in the project in a location where the void intersects with an element in the model


 

  • The element will not be automatically cut
  • Use the "Cut Geometry" command

  • Select the element to be cut, then the family with the void in it
 
  • The element may or may not be cut, depending on the following rules:

Rules and Exceptions

  • The element to be cut must be of one of the following categories:
    • Casework (not listed in the help file or tooltip),
    • Ceilings, 
    • Floors, 
    • Furniture (not listed in the help file or tooltip),
    • Generic models, 
    • Roofs,
    • Specialty Equipment (not listed in the help file or tooltip),
    • Structural columns, 
    • Structural foundations, 
    • Structural framing,
    • Walls
  • The void in the family must not be cutting anything in the family - this is the rule that caught me out recently.  To get around it I had to create two voids:
    • The first one to cut elements in the family
    • The second one to cut elements in the project 
      • [Edit]There are two ways to prevent the void from cutting elements in the family:
      • 1. You have to create the void in a location where it does not intersect any geometry,
        • then move it to the correct location - it will not cut any intersecting geometry;
      • 2.  Or create a solid where you want it, and change it to a void - it won't cut unless you tell it to [Thanks to Simon Weel for reminding me of this method]
 

  • [Edit] I have had problems with saving families that only contain a void element that is not cutting anything - but I think that only happens for in-place families.
  • Cutting only happens in a project
  • This capability does not work in the family editor - when one (cutting) family is nested into another family.  This is a very frustrating restriction - it means that you have to build additional voids into the parent family, which is a pain if you have complex angled geometry.

Once you understand those rules and limitations, you can use this capability to get families to selectively cut elements in a project.  It does have some advantages over 'Face-Based' families that also allow you to cut into a host element:

  • You can decide whether you want individual elements to be cut or not
  • It does not need to be hosted  - it can be placed directly in the model with its own parametric controls (height etc)
  • It can be moved away from or to an element to be cut (it remembers the cutting status if moved away and back)
  • This can be added to existing families (converting to face-based requires recreating families)
  • The void can be anywhere in the family - it does not have to be related to a host face in the family (as face-based families do)


I hope this saves time for anyone who cannot get this feature to work properly.  

In this example I have carefully made the void slightly bigger than the basin for clarity in the illustrations - and to make sure that water runs down the side of the basin into the casework and rots the timber.  I suggest that you make it a closer fit or use lots of silicon to seal it.


Monday, 20 April 2020

System Volume Parameter in Generic Category Families

 Here in New South Wales, Australia, we have a planning requirement (SEPP65) to provide a certain amount of storage in multi-unit residential developments.  Some of that storage can be in the apartment itself, and some can be in storage cages/cupboards in the basement.

The storage has to be calculated by volume per apartment - this means that we have to create schedules that combine the storage cupboards in apartments with the cages in the basement.  Thus we need to create objects of different shapes and sizes in the model.

There are several ways to calculate the volumes from these objects, but surely the simplest way would be to use Revit's automatic volume calculation properties?

System Volume Property

You would think that Revit would be able to report back the volume of any object in your model.  It is a database, right?

It turns out that it can do so, to a very limited extent - and of course that leads to restrictions and frustrations.

It seems that only cetain category objects can report their volume, and then there may be further restrictions on scheduling or tagging:

By Category

  • Many of the system families do have a "Volume" property

  • But you would not want to create storage cages or cupboards by mis-using those categories?  No, you would not!
  • Logically you would use the Casework category for cupboards - but sadly that category does not have a volume property.
  • The same applies for most loadable family categories.

  • You could use the Mass category, but that is not sensible either, because that should be reserved for creating building massing models - if you start mis-using that category it will surely make life difficult (not least with visibility issues).

  • Rooms do have volume properties, although that can depend on project settings - see below.
  • Rooms are also not an ideal way to model such things as high-level storage cupboards!

  •  That leaves us with one last option (that I know of):  the Generic category.
  • For many years in Revit, generic families did report a Volume property (automatically calculated from the volume of all solid objects in the family).
  • However, it was not originally possible to schedule this property
 
  • In Revit 2014, Autodesk enabled the ability to schedule this Volume property.
  • This was one of my few successes with lobbying Autodesk to include one small new feature in Revit, that would make a big difference to us.
  • Sadly they ignored my pleas to also enable this property to be tagged.

Generic Families

Prior to v2014, we created a range of storage families that did the volume calculations as formulas within the families - so that we could schedule and tag the volumes.

When it comes to basement storage cages, the shapes often become quite complex as they have to wrap around columns or need angled sides.


This led to some quite complex formulas that needed to take into account optional cutouts to the shapes, and to allow for overlapping cutouts.





Fortunately all these calculations became redundant with v2014, as we can now use the system calculated "Volume" parameter to schedule storage volumes.

Except . . . . . When a project requires the storage to be tagged on drawings.

Room Volumes

Rooms do have the ability to calculate and report their volume, and it may be easier to create basement storage cages as rooms with cage walls to enclose them.  This would allow any shaped area without having to create a range of families.


However, this becomes problemmatic when you need to create one schedule that combines the basement storage cages (Rooms) with in apartment storage cupboards (Generic category families).

Room volume calculations also have some quirks, that depend on project-wide settings:

  • Rooms have a height property - this is used for the system calculated volume.
  • However, it will not work if Rooms are set to only calculate Areas (not Volume)
  • This project-wide setting is generally recommended as it makes the project performance noticeably faster - the menu even tells you that (and it is true)

  • If you enable Areas and Volume calculation you will get the volumes being reported, but a slower project.
  • If you need to do this anyway, then it is no extra overhead for calculating room storage.




Room Volumes are calculated at Wall Finish, regardless of the Room Area settings.
  • This can be complicated if you need room areas to be calculated to wall centrelines.
  • More on this in another blog post . . . .

Sunday, 17 March 2019

Glazed Doors in Window and Door Schedules in Revit

I started out writing this blog post about the behaviour of subcategories in nested families.  On closer investigation, the weird behaviour I intended documenting was not as I had thought - still a bit strange but not quite worthy of a post all to itself.  So I have changed tack and turned it into a discussion about how to get a glazed door family to appear in both door and window schedules.  Many experienced Revit users should already know this, but for those who do not, read on.

Schedules and Categories

Typically door and window schedules are created separately as single category schedules. Multi-category schedules have too many limitations to make them work efficiently for this task. A door or a window is usually either one of those categories, and therefore it can only appear in one of the schedules.  What if you have a window assembly that contains a glazed door? or a sliding glass door, which you want to show in the window schedule (because it is glazing), but also in the door schedule (because it hosts door hardware)?  This common requirement seems problematic in Revit, but there is a way around it . . .

Workaround:

Shared Nested Family

When a nested family is 'Shared', it behaves differently to the parent family in terms of subcategories.
For example, you might have a window parent family, that contains just a frame (or a fixed glass side panel).  Inside this could be a nested sliding door family.  Providing the door family is set to 'Shared', then it can have its subcategories independently controlled (by View Visibility) in the project;  it can also be individually selected, tagged and scheduled (as a door); the parent family can be tagged and scheduled as a window.

Nested Door Family Category Settings

Nested Door Family Subcategory

Parent Window Family

Parent Family Category

Parent Family Subcategories

Nested Door Family in Parent Family

Tagging and Schedules

Standard door and window families are normally tagged separately according to category
Once placed in a project, the combined door/window family can be tagged for either category:




Tag the whole family for the window category tag

Tab select the nested door family to tag it

Scheduling

  • The combined window/door family will appear in a window schedule. 
  • The Nested door family will appear in a door schedule

Category Visibility

This example shows a single swing door nested family in a window family (with fixed window panels either side).  In the project, both door and window categories/subcategories affect the sub-element display:
All Categories On

Door Panel Subcategory Off

Window Category Off - Door Category On

Non-shared Nested Family Categories

When a normal 'non-shared' family of one category is nested inside another family of a different category, it behaves as if it is part of the parent family in terms of categories.
Unshared Family Settings
In the parent family (in Family Editor), the nested family still shows its category when selected
Non-Shared Nested Door Family in Window Parent Family
When loaded into a project the whole window can be selected, but not the nested door family. 

Window family with non-shared nested door - in project

Changing the visibility of the Door category does not affect the nested door.
Door Category Off, Window Category Visible

Hiding the Window category, (while the door category is visible) hides the whole family, including the nested door
Door Category Visible, Window Category Off

This behaviour is as expected.

Weird Revit Behaviour:

Non-Shared Nested Families

However, if the nested families have elements of a specific subcategory (of the Nested family category - door) the element's visibility is still controlled by that nested family subcategory.  This does not really make sense if the nested family is not shared.
Door Panel Subcategory Off


This can be very confusing, as you have no way of knowing what category the nested family is, without editing the parent family.  As far as the user is concerned, the family is a window - since you cannot select the nested door in the project, the user will not be aware that it even has a nested family, let alone that a subcategory that has nothing to do with windows will still affect it.