Display Issues: differences between Categories

[Anonymous]

Hello.

Can someone please chime-in and explain the logic behind the differences
between RVT Categories and how they display in Plan View?

Example:

I made a custom component (Family) that was set as the 'Generic Model'
Category.
When placed, its elevation was set above the Cut Plane but below the Top of
the Primary View Range for the Plan View.
The Object displayed in its entirety.

I then decided that this component was really better categorized as
'Specialty Equipment'. So, I re-assigned it in the Family Editor, and
re-loaded it into my Project. As I did this, the object disappeared from
Plan View. I then switched to a 3D View to verify it was still present in
the model - and it was.

So why does Generic Model Display, and not Specialty Equipment, I ask?

I've discovered that if I lower the Elevation of the Specialty Equipment to
exist at or below the Cut Plane, but above the Bottom of the Primary View
Range; it will display in Plan View.

I've also tested and discovered that adding Symbolic Lines to the Plan View
of the Specialty Equipment in the Family Editor and re-loading into the
Project will not overcome this issue of elevation - if the object is above
the Cut Plane the Symbolic lines will not display either.

I note that Specialty Equipment does not have a "Cut" setting for
Lineweights in Object Styles, and Generic Model does.
Is this the indicator for this display behavior that I'm experiencing?
And if so, why is 'Specialty Equipment' regulated to this type of Category?
Why not have a 'Cut' setting for it?

Quite a fair bit of an Architectural model gets lumped into this Category:
lockers, toilet accessories, kitchen equipment, medical equipment, etc.
Seems very short-sighted, to me, to limit the Category in this way.

[vector2]

> So why does Generic Model Display, and not Specialty Equipment, I ask?

see image..

[Anonymous]

I found a workaround:

Create a *Model Line* element in the family,
somewhere low enough to exist below the Plan View Cut Plane and above the
Bottom of the Primary View Range.

This then triggers *everything* to now display,
the model line(s) at the lowered Ref. Plane *and* the 3D Extrusions that
exist above the cut plane.

Weird.

[Anonymous]

"caLayton" wrote in message
news:6389221@discussion.autodesk.com...
> I found a workaround:
>
> Create a *Model Line* element in the family,
> somewhere low enough to exist below the Plan View Cut Plane and above the
> Bottom of the Primary View Range.
>
> This then triggers *everything* to now display,
> the model line(s) at the lowered Ref. Plane *and* the 3D Extrusions that
> exist above the cut plane.
>
> Weird.

Hey Corey,
I don't have an explanation for why this is, but it certainly 'is' 😕

Instead of a model line, you can also use a reference line.
--
Bobby C. Jones
http://bobbycjones.spaces.live.com

[Anonymous]

"Bobby C. Jones" wrote in message
news:6390711@discussion.autodesk.com...
> Instead of a model line, you can also use a reference line.

Hi Bobby,
Thanks for the tip.

I'd rather the Ref. line, I think.

Also to note:
Under normal conditions, this is pretty easy to accommodate:
Just stick a single invisible Model Line or Ref. Line, constrained to the
Level datum in the Family template.

This will keep this "display trigger" on the floor, so to speak.

But here's another wrinkle:
My particular Family that prompted all of this is created in a face-based
template.
And because there is no *vertical* face-based template (which would be
similar in orientation to a Wall Hosted Template...)
I cannot constrain the Model/Ref. line to the Level datum.
Instead, I created a Ref. Plane, at a fixed distance "below" the extrusion
objects, that will *likely* land below the cut plane and above the bottom of
the Primary View range in the model, but there are no guarantees.

We really need a *vertically-oriented* face-based Family Template,
to compliment the horizontally-oriented one we already have.

[jcgardea]

I would really want someone form Autodesk to explain this. It really does not make any sense. At least from the Architectural side.  And I can't believe someone from Autodesk has not responded this in 3 years!.

Not happy about this.

[jcgardea]

Also the workaround does not seem to work in Revit 2012 and after...