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!

[aaronrumple]

Aaron,

Is there a knowledge base article, or something somewhere documenting what the baggage is (good and bad) that comes along with each category?

Thanks!
No summary that I know of other than the cultural memory of AUGI.

If you dig deep enough it is mostly all in the help file, but there isn't a good overview of everything.

[Calvn_Swing]

Hmmm,

One more thing to ask Santa for...

[Mr Spot]

We have filters added to our slab setouts etc and use floors for bench tops.

The floor types have a type comment for benchtops enabling us to filter and turn them off independantly if needed.

This way we are still able to use face based families for sinks etc.

Works a treat and is gives you a lot of customisable options such as slab edges for different returns...

[Calvn_Swing]

Not a terrible idea at all. Unfortunately, I can imagine the confusion of the contractors and estimators when we export out of Revit to other formats and all these floors show up all over the place. That could be a nightmare.

I'm afraid this is one of those situations for me where a perfectly good workaround won't work for me because of how we leverage the data downstream.

Personally, I'd just prefer Autodesk fix this and let me host a face-based void in any **** thing I wished. I'm just tired of feeling like there is so much potential in the software that is being held back by the programming... (lack of time/resources)

Edit: Naughty word, but it was worth leaving the stars to convey the intent...