Missing panels in contextual Modify tab

This has been happening sporadically in Revit 2011 and I believe it’s been fixed in 2012. Basically you would be editing a profile sketch such as a wall through Edit Profile, you switch your view to a standalone RFA family and upon switching back to the project environment, the contextual panels disappear and the contextual Modify tab switches to the usual Modify tab only, leaving you stuck in sketch mode with no apparent way back to the project.

The first way out is through assigning a keyboard shortcut for Finish Edit Mode: all 8 of them in 2011 (and 9 in 2012!). Honestly, I think there should only be one as the user doesn’t care which particular sketch mode is active: they just want to learn one shortcut that gives them the ability to finish any sketch mode. I sympathize with the technical reasons why there’s more than one, but if that is truly necessary, why make them look identical with no way to distinguish them except through endless hours of trial end error?

The second method makes the panels reappear so you can continue editing the sketch or finish/discard; here’s how you do it:

1. Start a new family, pick any one;
2. Load it into your project;
3. Once you get the error that it cannot be placed in this mode, hit Ctrl+z to undo.

For some reason the panels come back. Obviously, do not switch back to the open families or you’ll lose them again! This has happened to me several times now, especially when I open a profile family to “steal” the linework and paste it into the profile sketch of a wall. So if this happens again in 2012 in one of the 9 sketch modes, one of these methods might help you get out of a bind.

Missing panels in contextual Modify tab

Propagate Extents

How long do bugs take to be resolved? Well, sadly in some cases the answer is “more than 5 years”. At least 6, possibly even more. Here’s proof.

This tool is not widely known, possibly due to discoverability. It’s not a button that is always there, but one that appears when you select a datum, such as a grid or a level. The idea is that when you change the extents from 3D to 2D, you can then propagate these custom 2D extents to other views. But there’s a catch: for some reason this functionality is broken when it comes to views that have a crop region enabled and when the datum’s 3D extents go beyond this crop region. Let’s say you have grids or levels close to each other and the text overlaps. In this case you add an elbow by clicking the little in-canvas symbol and make necessary adjustments to your view, perhaps even shifting the datum’s end point. Since this is a view-specific edit, the use of the Propagate Extents tool will then help you push these changes to all the other views you pick.

There is a workaround for this problem and it’s annoying if you have a lot of views to work with:

1. Disable the Crop Region in the view that contains the 2D extents you want to propagate, and also in the views you want to propagate to;
2. Select the datums, click the Propagate Extents button on the Ribbon, pick your views and finish the command;
3. Re-enable the crop regions in the affected views.

To me this seemingly trivial tool is so good that it’s a shame it doesn’t work properly. I think it’s time to dedicate some manpower to get it fixed.

Propagate Extents

In-place Masses and Level Constraints

When constraining in-place masses to levels in the project environment, you might be faced with a number of constraint errors depending on how (where) you apply them.

There are a few other quirks which also seem to imply buggy behavior, so instead of a long textual post, how about a video? It’s been long overdue to set up a YouTube Channel for this blog! Here is the embedded video:

 

Or you can view it in HD by clicking here.

In-place Masses and Level Constraints

Filters, View Overrides and Halftones

Here’s an example of something that seems to be broken. I created 2 floor types and 2 wall types, and called each one Object1 and Object2. Then I created a filter for the floor and wall categories, and filtered By Type = Object1. This way I could verify that the issue is not isolated to a single category. I assigned this filter to the Visibility/Graphics dialog, set an override for projection lines to Red, and the result is shown below:

 

Then I set a view override in addition to the above filter and made Floor projection lines as Blue:

 

Thus we can deduce that overrides are applied in this order

1. Filters
2. View Overrides

So far so good. Based on this order, one would assume that if I set an additional view override to Floors and Walls to Halftone, Object2 should halftone but Object1 should not, right?

 

Wrong! As you can see above, the halftone setting in the View Overrides is taking precedence over the filter. I’d say this is an inconsistency that needs fixed. Agree?

Filters, View Overrides and Halftones

Topography and BAD pads

I confess: I have not used site tools in Revit that much. There are a variety of reasons for that: not much opportunity in what I was doing in the past, insufficient tools, etc. But recently I started using them in schematic design, especially because I have made a pact with the devil to obliterate the perception that only SketchUp is adequate for this phase!

Continuing on the usual trend of reporting what doesn’t work in Revit and suggesting possible fixes, I came across a problem today. The same issue in a slightly different context has been reported over the last year by Mr. OpEd. himself, so this bug is not new.

In my case I had a sloping 8” pad for a roadway and another 1’-0” pad for a sidewalk. They share the same edges, yet the toposurface started bleeding through. What is most peculiar is that the surface of the topography itself was actually below the pads, yet it was bleeding upwards to 6” above the hosted level of the pads. This elevation turns out to be the underside of the sidewalk pad had it been perfectly flat. As a side note, the green form was built out of a sloping floor to represent grass since we cannot have overlapping pads.

 

This bug is obviously related to sloping pads. In this example, I copied and pasted the slope arrow between the two pads so they would be exactly co-planar, yet the bleeding issue still happened. After a bit of playing around with the thickness of the sidewalk pad and changing the Height Offset from Level parameter (note: I was not going for sectional accuracy here), I got the bleeding to stop. First I changed the sidewalk pad thickness to 1’-2”, then offset the pad downwards and then back up to the original offset. Behavior is very inconsistent as bleeding stops after making an offset change and reverting to the previous value.

 

 

 

I also noticed that when changing the pad from a thicker to a thinner one or vice versa, the toposurface did not update. As you can see, I changed the sidewalk slab from 1’-2” back to 1’-0” and ended up with a 2” gap. Not Revising Instantly now, are we?

 

Anyway, I kept thinking about this as the issue kept cropping up all over the place while working on the above site model and I was tired of trial and error solutions. Finally I nailed down the problem behavior thanks to the previously mentioned observation about the elevation of the bleeding edge. The next series of images explain the problem and solution.

So the key is to model your pad so that without any slope arrow, it is in line with any other pad, at the lowest elevation. Then add the slope arrow to make the pad slope upwards. The slope arrow direction does not seem to matter so in the above example, it could be rotated 180 degrees with the head getting the 10’-0” offset and the tail remaining at 0, and the result would be the same. Hope this is helpful!

Topography and BAD pads