Hiding objects inside Family Editor

[Anonymous]

I will be modelling some bridge abutment wing-walls. I have attached a .png of two instances of the wing-walls, and circled in red the key difference between them (wing-wall extension) which I am concerned with at the moment.

I'm looking for ideas on how to model the wing-walls in such a way, that I am able turn "on" or turn "off" the wing-wall extension. I have watched some tutorial videos which suggest doing it with the "Graphics: Visible" control in the properties palette. However, I am not certain if this will actually affect how the overal cubic volume of the wing-wall will be calculated (which I will need for schedules and quantities later in the project).

What is the best way to do this?

[L.Maas]

How are you planning to model the wing walls in general. You plan to use a family for that?

If you are in a family you have indeed the visibility graphics override settings.

However those determine only the appearance. You can control how things look in different modes (front/back, top/bottom, left/right & 3D) and further what to show in coarse, medium or fine detail level.

What you probably will be looking for is the visible setting. Here you can control if part of you family will be visible or not and can be controlled by a parameter. This can have and influence on your scheduling in the project.

Depending on your requiremnts you also could consider to create separate families instead of using visibility settings

Maybe you can upload what you already have and we can have a look.

[Anonymous]

Yes, I am planning to use a single family for the wingwalls. Using further nested families to model the wing wall extensions might be an idea worth trying out. I haven't thought about it yet.

There's not much to look at at the moment, as I have not yet started working on the wing walls. I am modelling the bridge abutment in several parts:

 - Abutment footing

 - Front Wall (consists of two symmetrical halves --> identical to each other)

 - Wing Walls (left and right, which may be different instances... which has been accounted for in the footing dimensions)

 - Bearing pads

These will all be nested families in a single larger family. The abutment slab was easy. The front wall is probably the hardest, and I have been working on it for over a week now. I have not started the wing walls, and I have tried out (successfuly) methods for modelling the bearing pads using array parameters. I might have problems getting them to allign with the slope of the abutment though (haven't tried that yet).

People have suggested that I don't use nested families, because of the complexity... but many parameters of the families listed above will be common across several families. Using nested families allows me to associate several parameters, with one "main" controlling parameter in the main family. This simplifies things a lot, and also allows me to remove all the "shrapnel" (intermediate parameters for calculating various offsets, angles, etc), and only include the input variables I want to.

I have attached what I've got so far.

[L.Maas]

I do not agree with not using nested families. In general I think they make work less complex. As soon as I start using multiple instances of something I consider nesting families. If the compleity in the host gets too great I also tend to use nested families. With nested families you can make sure that those parts are constrained well before using them in the host.

I think the division between front wall, wing walls, footing and bearing pads seem logical (saying this as somebody without knowledge of bridge design).

I do not know how many variations you are going to need for the wing walls. I would consider to create few different types instead of trying to create everything in a single type.

Bearing pads should be possible to array along a slope. Also here, depending on the amount of variations, I would possibly consider to to work with visbility parameters instead of an array. (arrays are often slow).

In general I think you are on the right track. If everything gets too complex you always can consider to place separate families in the project instead of trying to do everything in single family. In a project you could then use groups or assemblies to keep everyhting together.