After searching around fo a while I have come to the surprising conclusion that the question I am about to ask does not seem to have popped up properly.
What I am trying to do is make a complex roof family.
This consists of a number of nested families, such as the composite roof (01)
and a facebased void family (02).
These are both loaded into a generic family with the rest of the gutters etc. in image 03.
Now if I load this family into a project, my voids will not show as voids, but rather as solids?
Can somebody help me with this problem?
I have already made all the families shared and cut with voids when loaded.
@ToanDN wrote:
#1 = face based void
#2 = family, do not load #1 to #2
#3 = family
load #2 to #3, load #1 to #3 to cut #2
#4 = project
load #3 to #4
That works, too. The void displays properly in the project.
This is what the problem is, that the combination of an external void family and an external 'dakpakket' family (plain stacked roof (layers of insulation,multiplex etc.)) seems to not show once you push it further into a project.
I am on 2017.1 if i am not mistaken.
@Alfredo_Medina can you post the project in which this works? I am very curious. if it works, then I guess using an 'illegal' roof family might be the culprit?
I use 2016. I can post the sample file later
@Alfredo_Medina wrote:
I use 2016. I can post the sample file later
Maybe it works in earlier versions. It definitely breaks in 2017.
Okay I'll be damned.
I just tested with 2017 using fresh families and project and it works like @Alfredo_Medina has described. OS, there must be something going on with @detlevvanloenhout families.
I think I may have figured out the problem.
Look at the picture below, I created a copy of the roof file and make it not shared, load it in the host family, add voids, load the host family in project. Voila, the voids are now showing on the copied roof.
But I understand you need it to be a shared family for scheduling in project so I am not sure you can do anything about that.
Revit file is attached for reference.
Ok so.... still bugged as to the way Revit could be working.
And also, yes, i kind of need the shared family option to retrieve my quantities and such in schedules. We are growing ever reliant on Solibri and Vico for our quantity retrieval.
Bigger issue that might arrise (i'll have to check) is that if we do not use shared families, the family, when converting to IFC doesn't 'decompose' into its smaller family sub parts. So for instance the roof-tiles, which is for us a quantifyable volume, needs to be retrieved...
Consider just cutting with a void in the 'dakpakket' nested family and associating parameters if any...
…and/or nesting the void cut there (and associating parameters), that should also work.
Edit: gotta start paying attention to those timestamps...
Anyway, would work in rvt2020 but doesn't with rvt2017.
Hi Martijn,
Welcome to an old issue. I am currently running 2019, and i can confirm that the problem didn't get solved in that version yet. Currently installing 2020 to see if this contains this killer feature. Thanks for the heads up!
If you just use a void cut (with rvt2020) it will work in the project, but you should not nest the 'panlatdek' though because that will not be cuttable (or cut that with face based void cut --- doesn't work, only in project). You can use the 'pumpkin carving' method by associating the extrusion end/start with parameters for instance to control if there is or isn't a roof opening cut. And for length/width just associate parameters to the void/void sketch.
Regretfully, i have to find that Revit 2020 does not yet work as I would've hoped, which would be like the flowchart i posted earlier:
So we will keep to our current solution of making overly complex families with lots of internal voids in the subfamily that all have to be connected on a top level...
Result of the test using nonsense-families is in the project file. You can see the void when hovering over, it just doesn't subtract when in the project.
I meant a modeled void, not cut using a face based void family (does seem to work in 2017 actually). I do agree that it is overly complex. Works with exception of the nested 'panlatten' family, so you just need to model that in the same family also.