Filled Regions in Generic Annotations Destroy Origin Associativity

[cvoight]

Generic Annotations are intentionally implemented in Revit as extremely simple. They can be thought of as having an x-reference plane and a y-reference plane, which determines the origin of the Generic Annotation family. No other reference planes or "snaps" can be created. Despite being simple, and against all known rules and common sense, creating a filled region in a Generic Annotation completely destroys the associativity of the origin reference planes between Generic Annotation families. This is a deeply frustrating and hard-to-troubleshoot bug. (Despite hours searching various terms before and after discovering the issue, I could find no reference to it.) I will explain the problem and three workarounds.

Problem

In order to offset a Generic Annotation (GA) symbol in plan view, you must either dimension to the x-plane or lock the x-plane to a reference plane or line. Locking a GA to a reference line in a parent GA family works quite well, but this problem occurs no matter the method you use.

The problem of origin associativity arises when multiple GA families with (different enough) filled regions (or, some GA families with a filled region and some without) are used in a single parent family. Attempting to switch between GA families using a Family Type parameter, or switching by hand using the Properties bar, will not work.

Let us proceed to a minimal working example.

Create a new GA. Draw a square with sides of 1/8", center it on the y-plane, and move it such that the top is 3/16" from the x-plane. (See Square.png). Save it as Square.rfa. Draw two lines from the endpoints of the bottom side to the midpoint of the top side, and delete the three sides not part of a triangle. Save it as Triangle.rfa. Delete the linework and create a circle with a radius of 1/16", center it on the y-plane, and move it such that the top quadrant is 3/16" from the x-plane. Save it as Circle.rfa. Lastly, create a filled region (Solid Black) consisting the same circle you just drew in the same place. Save it as Circle with Filled Region.rfa.

Now, create a new GA family, and load all of the families you just created in. (See the attached Revit 2016 family "Generic Annotation Constraints Test Family.rfa".) Choose any of Circle, Square, or Triangle to place in the view, and align & lock it to the x-plane, y-plane, or both. (Or, draw a dimension to the x-plane, y-plane, or both.) You will find that, using the Properties drop-down, you can toggle between the Circle, Square, and Triangle families at will. However, as soon as you attempt to choose the Circle with Filled Region family, everything fails (constraints are not satisfied, or dimension references are invalid).

Workarounds

There are three workarounds that work "well" (for some definition of "well").

(1) Filled regions do not actually affect the x-plane and y-plane of a Generic Annotation family, except insofar as they are incompatible when locked to a reference or dimensioned. If you do not need to lock or dimension a GAs with different filled regions, do not do so, and there is no problem.

(2) Implement an annotation symbol offset by nesting each GA family of interest in its own parent GA family with a reference line (or dimension) controlling the annotation symbol offset. This requires a strict doubling of the number of annotation symbol families, but is the most robust solution.

(3) Implement an annotation symbol offset by nesting each GA family of interest in one parent GA family with a reference line (or dimension) controlling the annotation symbol offset. You can then use a Family Type parameter to control which annotation symbol appears. The trick here is to start with only the set of GA families that do not lose associativity when toggling between them. Then, edit a nested GA family that works, save it as a new family without making any changes, and load it back in. Only then can you edit the new nested GA family to create the symbol you need and load it back in without the presence of different filled region destroying the associativity of the x-plane or y-plane. The drawback of this workaround is that the families you saved out are fundamentally incompatible, and will suffer from the origin associativity problem if the family file is loaded into another model category family or generic annotation family.

See the attached Revit 2016 family "Receptacle E+ Annotation.rfa" for a working example of workaround #3.

[fabiosato]

Hello,

 I would suggest you to create all filled regions and then create a group, if necessary, create some invisible lines and include them in the group, then use reference lines and align and lock the invisible lines to the reference lines, this way you don’t need to nest families.

Unfortunately I can’t load any sample family at the moment.

[cvoight]

Nesting Generic Annotation families in a parent GA family is required for an annotation symbol offset to work properly, at least as far as I can remember or tell from testing. My initial goal was to eliminate the need to nest GA families at all, but you can't achieve an annotation symbol offset in plan view with "Maintain annotation orientation" checked. (I assume the technical reason is that it forces the origin x-plane of the annotation to stick to the origin "x"-plane of the family in plan view. You thus need to have an intermediary parent family whose origin doesn't move to host the nested GA families and move their origins as referenced to that parent family's origin, which is how I've always seen it done. There are other ways, but I don't see them as improvements.)

This problem only arises when dealing with multiple families with different filled regions, so I don't see how groups or creating the filled region separately would help. Creating the filled region separately simply moves the problem to a different level.

[fabiosato]

Hello,

Please check the attached family.

It is in portuguese but you may understand.

[cvoight]

This problem arises when you attempt to tie generic annotation families with different filled regions to a single origin point. (See the family in my original post.) While you can control filled regions using grouping and invisible lines, that doesn't resolve the issue in the original post because you have to create more parameters to control the visibility of multiple filled regions.