List Dimensions

[steve.70285]

I'll attempt this thread again since my original thread a few years ago in my opinion was not communicated that well...so here goes...

Many times I wish I could've made use of a dimension within a family that would "List" a value and have no acting priority on its host. The purpose of this dimension would be to extract information from a model that was created by other parametric dimensions. It would also allow the listing values to be used in other formulas, nested families and schedules.

Over the years I've spent many hours searching the Internet or looking in reference books, as I'm sure many of us have, looking for a formula to make our family or nested family flex as they should. Some of these formulas have been long and very complicated (especially when a radius is involved).

List dimensions would obviously not take away the need for formulas but I believe they would make some formulas a lot easier...not to mention the impact it would have on the use of reference planes and constraints.

The ability to extract this information for schedules displaying construction information is equally important. This idea for me started when I created a arch window family that include three separate window units grouped together with a single arch spanning over all units, I had everything acting from the apex and center point because that was the best way to work with a radius...knowing that window manufacturers and framers like to know the leg heights I was forced into the formula of figuring out the side lengths and tweaking everything making sure nothing was conflicting. Had I been able to use a list dimension...I could have dimensioned the side legs and made the length available as a listed value for my schedule; I could also rest assured that the dimension would not have tried to change the model.

I know this example is not the path everyone would have taken and since then creating a legend would have sufficed. But that’s not the point...since then I've though of many uses for a dimension that would list model values.

One of the great strengths of Revit is it's parametric core...I think there's a multitude of information we can extract from our models. "List Dimensions" would IMHO help us extract more.

[aaronrumple]

It would also allow the listing values to be used in other formulas, nested families and schedules.

I'm not sure I follow at all. If your parameter is setup as a shared parameter - it can be scheduled. So every parameter can be scheduled.

Nested families can, in fact, share parameters with the host. And other way around.

I'd love to see an example of what you're trying to do...

[steve.70285]

Yes, I understand information can be shared...but if you would...look closer at the concept and then back out.

If we could list a dimension from a graphic presentation of a model we could use the value to then act upon a nested family...for instance:

Say you create a door family and you use a sweep around the outside of the door for the frame...the opening in the center has no parametric value to it. Yes, you could create a parameter, subtract twice the profile from the width and height of the door and then apply it to the nested window insert. But what if you could list dimension the graphic representation of the opening and use it to act upon the nested family.

[twiceroadsfool]

Aaron, if i understand him correctly, here is what hes after:

A 7'-0" door, with a 2 " frame.

The 7'-0" is a DRIVING PARAMETER, it affects the door, yadda yadda.

He wants to be able to put a dimension between floor and Top Of Frame, that "reports the value" 7'-2" (or whatever it is, depending on the frame size and the door variable), but that doesnt DRIVE the geometry.

There is a way to do this now, using another nested family with shared parameters, to report the value.

In my blog, theres an example where i wanted "list values" for a "random" opening in a floor. If you builf a family similar to that, and loaded it in to your "other" families, you could technically get this to work. It just isnt automatic.

I can appreciate the desire for this though...

[steve.70285]

..., that "reports the value" ...

Aaron M, yes you've got it. Whether it's called "List" or "Report"...I think it would be a very powerful dimension to use in many situations.

[aaronrumple]

With the API - parameters can be hidden. So what you are asking for is currently possible.

You can always dimension to any Ref. plane inside a family. So you can also place a dimension on some item being driven by the 7'. But then again - you can just dimension any visible geometry you like. Again, I don't see an issue here.

(..and the API coordinate system can be used to do just what you list in your blog. People wanted an API - Revit gave it to you. Be careful what you ask for.. )

..and I don't see why you couldn't use the spot coordinate. Aligning your grid with a coordinate is just two clicks for the whole project.

[steve.70285]

OK, how about this...

I'll work with the door family I suggested earlier. Although I would not typically create a door this way it does highlight my point.

When I create the door frame using a sweep locked to the outer reference planes (Image 1) the opening is solid geometry that can be dimension...nothing new yet.

I then dimension the opening and label it as Glass Width (Image 2).

Now to change the width of the door from 3/0 to 4/0 the dimension is what acts upon the opening and forces it to stay at the original width (Image 3).

Had I used the proposed listing or reporting dimension on the opening (Image 4) it would not have locked the dimension width...it would have flexed with the family allowing me to use the value for nesting a glass insert and using the value as it's width.

[twiceroadsfool]

[QUOTE=aaronrumple]

(..and the API coordinate system can be used to do just what you list in your blog. People wanted an API - Revit gave it to you. Be careful what you ask for.. )

QUOTE]

Im sure it could, lol. I cant write code any better than i can walk a tight rope. And i got some big old clumsy feet, lemme tell ya.

Id love to get in to the API, but its not something i think id pick up.

You bring up a point i hadnt though about though. I think the OP's confusion is that when you make a new parameter, if it has a value, itll start to conflict with other parameters.

If i make HEIGHT (7 ft) and FRAME (2 inches) and then make TOTAL and dim it from the ground to the T/O Frame, it will sometimes cause a conflict. I forget which way ot works though. If you make the default parameter value 0'-0", THEN tie it to a dim, itll assume the value and "report," so to speak.

Ill often do that, and put the parameter under the "other" catagory, while all the meaningful ones are under "constraints" so there at the top of the properties box...

[aaronrumple]

OK, how about this...
Had I used the proposed listing or reporting dimension on the opening (Image 4) it would not have locked the dimension width...it would have flexed with the family allowing me to use the value for nesting a glass insert and using the value as it's width.

You lost me.

You want the glass to move with the frame and change from 2' to 3'? You can do that. Make a door panel with instanced parameters. Lock the door panel to the opening. It will stretch accordingly. Schedule the nested shared family to see its parameters. Or dimension it.

Yes? No?

[aaronrumple]

If i make HEIGHT (7 ft) and FRAME (2 inches) and then make TOTAL and dim it from the ground to the T/O Frame, it will sometimes cause a conflict. I forget which way ot works though. If you make the default parameter value 0'-0", THEN tie it to a dim, itll assume the value and "report," so to speak.

Just make the one your moving an instance. Type drives instance. Type fights type. Ref. planes fight ref. planes. Ref. planes drive ref. lines.