Face hosted voids not cutting cabinet family...

[Calvn_Swing]

So, I searched and searched, and I know there is at least one thread about this on the forums, but I just couldn't find it. Sorry!


Anyway, I'm trying to make a sink that will cut into a counter-top family we've already made. We build these vanities the same regardless of the purpose, and just mount sinks to them if we need them. Obviously, the ideal way to do this is to make a face-hosted sink family with a void to cut the counter top. However, I can't make it work for the life of me. It can cut walls, floors, etc... but it won't cut a counter top. Even more annoying, it will host in the counter top, but won't cut it. The counter is a simple casework family.

What in the world am I missing?

[aaronrumple]

From the help file for face based families....:

If the family contains a void cutting the host, the component will cut its host, but only if the host is a
wall, floor, roof, or ceiling. When a component with a void is placed on any other host, it will not cut.

BTW: Casework doesn't allow for a join geometry condition to be used either. I suggest you do counter tops as generic models. You only need a few families to cover all the possibilities and sinks are much simpler.

[Calvn_Swing]

And so I'm struck down with my own advice....check the help file! Ahhhhhh....

Somehow I missed that sentence. I looked back, and there it was! Thanks aaron, I don't know how that one slipped by. How do you handle this situation may I ask? It seemed like such a simple thing to do at the time, but then again I'd never tried to cut anything other than a floor, wall, roof or ceiling...

[tomnewsom]

You have to create the void in the host family, I'm afraid.

[aaronrumple]

See attached. I've gone to generic models for countertops. It is much faster and requires far less fussing with families. The graphics end up great as well as the 3D...

[Calvn_Swing]

Looks interesting.

We considered using line-based components for counter-tops as well. However, in this case we are using several component families to make what amounts to "standardized" built in configurations.

For "custom" counter-top work (every time is different) what you've got seems to work really well. For "standardization" uses, not so much. Also, the generic model thing throws me. We don't model anything in the generic model category that already has a "fitting" category. You said it was faster and required less "mussing," I'm wondering in what ways?

Usually, the only thing that ends up being generic models in our files is construction equipment. I'd use special equipment, but that bloody category doesn't cut in section. Why they wouldn't let us control this behavior in the VG settings is beyond me.

Thanks again,

[Teresa.Martin]

Hi! You could also try making a counter top and base cabinet with the line based generic model tool. Within that family you can make a void that you can move and size for the sink, etc. If you know your way around parameters it is pretty easy to set up.
Good luck!

[aaronrumple]

Looks interesting.


For "custom" counter-top work (every time is different) what you've got seems to work really well. For "standardization" uses, not so much. Also, the generic model thing throws me.

Thanks again,

Placing them in the generic category is the whole trick in speeding layout. Whether you use line base, or other is irrelevant.

I can have only a few pieces using generic category and then join them all together using the join geometry. I can't do that if they are casework and I end up with seams all over the countertop. now all I need is a straight run, an inside and outside corner, and any special segments with holes for sinks and such. Now I can configure any counter top shape I need. Specific layouts can be grouped and reused using these very basic pieces.

[Calvn_Swing]

Thanks for the reply Teresa.

Unfortunately, for reasons stated above, line based components don't work as well for our scenario as they do in other situations. The other reason I wanted the void in the sink family is that we use the same counter for situations when we have no sink as we do when we have sinks. So, the nice thing is that we can place a sink where we need one and not have to maintain two separate sets of counter families just so we can have sinks in some of them.

Setting the parameters isn't the problem, it is the methodology of faced based families not really being "face based" but rather system family face based...

[Calvn_Swing]

...I can have only a few pieces using generic category and then join them all together using the join geometry. I can't do that if they are casework...

Aaron,

Is there a knowledge base article, or something somewhere documenting what the baggage is (good and bad) that comes along with each category? These little "hidden" differences drive me crazy! It is good to know that generic models can be joined, but why in the world wouldn't we be able to join casework too? Or special equipment not cutting in section, it's nice to have the ability to have something not cut, but what if it is in another category? I have to make it "special" to make it not cut. The entire idea is just antithetical to the description of Revit as a modeling database. I expect categories to behave consistently, or to have control of the settings that can create inconsistency. Since I've got neither, I at least want documentation of the differences...

Just to prove I tried the help file, this is the helpful information it offered on this topic:

"NOTE:Family parameter options vary depending on family category."

Ahhh, nothing like specificity!


Oh, and one last thing, how would you handle round/oval sinks? I don't see how your current system of line-based components can handle it. I assume you've got a non-line-based family with a parametric oval hole in it that you can adjust accordingly?

Thanks!