Paul - thank you so much for sharing all this great content - I never knew you did that.
One of the things i saw in a handout you made for a Midwest University presentation was:
Many hosted ceiling elements have voids integrated into them. This allows the fixture to be recessed into the ceiling plane. This can have an impact on performance in large files. Create a void that moves away from the surface when “Cut Ceiling” is unchecked To deal with this, you can use a Yes/No parameter to drive the size of the void element. When checked, the void will be big enough to engage the surface host. When unchecked, it will move away from the face and disengage*.
I got super excited and tried it out and spent way too many iterations attempting to make it work before i noticed your footnote:
"Unfortunately, this does not always work as expected. Once you uncheck the void, it will not re-engage with the surface when rechecking the box. So, it works well to disengage the void, but not as well to re-engage it."
It seems the issue is even greater than this - it's not just the void that cannot re-engage, but the entire fixture loses its association with the ceiling. If its ceiling hosted - the family requires the instance be deleted, and if its face-based, the family remains but no longer hosts to the ceiling surface - so if the ceiling moves - your lights all get hidden or start hanging down.
Is there a way to avoid this? Am i doing something wrong? Or is this how your families behave as well? |
Any clue why this happens? It seems like even if you place a void in a face-based family which NEVER cuts anything - the family will never host to a face in a project model - it just instantly becomes disassociated.