Tag Archives: Quirk

Plan View Types Part 3

Leave a reply

I have posted a few times now about the Revit 2013 new Plan View Types.  I really like this feature, however I found another nuance that everyone should be aware of and hopefully will change with future service packs or releases. 

At first I loved the fact that when levels were created it allowed the Plan Views to all have the same name if they were under different view types.  I still like this, however it seems to be causing issues.

Notice in the image below I have Level 1 and Level 2 views in each plan view type. This is great now if you rename a level or view the capability to rename all of them still exist.

 

Now simply move a view from one category to another. 

 

If that view name already exists then it doesn’t add another number at the end, it simply add up to the next available number. Which seems totally non_Revit like in my opinion why not a (2) at the end?

 I wanted to make everyone aware of this issue. I have already been discussing this with clients to see how they want to impliment and deal with this issue.

Small nuance that could be frustrating however not devastating to a project.  If you want to apply a view template via another view and all of the plan views have the same name how do you choose?  As you can see there are numerous Level 1 views.

Square feet per foot dialog

2 Replies

I was creating a schedule key today for and abbreviation list, when this dialog box popped up. 

Can I ask what this dialog box means and why it came up when I was in a text value in a schedule key.  I love Revit warning some times, they are just puzzling.  I think the programmers but them there to make us ponder and laugh during our busy days.

Cross-Section Rotation Quirk

Leave a reply

I was recently doing a quick little job for a client and in modeling the structure I needed to show a 2×4 wood framing member turned flat, so I used the OOTB 2×4 and set the Cross-Section Rotation to 90 degrees.  The following is what I got.

Since I wanted the top of the framing to align with the level, and the above was the result, I was reminded that the cross-section rotation’s base point is the intersection of the workplane and the Lateral Justification, so I changed the Lateral Justification to ‘Side 1’ and got my desired result.

This got me thinking – what if I had wanted to move the framing more than just a little?  It is a known quirk that the z-direction offset doesn’t work quite right when the cross-section rotation is set to anything other than zero, but I haven’t seen any documentation to explain what is really going on so I thought I would figure it out.

The conclusion is this: assuming the cross-section rotation is set to a value, a, if you enter a value, z, into the z-direction offset, the member will move as follows:

Vertical movement = z*cos(a), where up is positive

Horizontal movement = z*sin(a), where left is positive

I could paste a ton of screen shots here showing a bunch of variations, but I encourage you to go play with these settings and see what happens.  Take particular note of the fact that cross-section rotation values greater than 180 degrees causes positive z-direction offsets to cause movements in the negative directions.

So what is the solution?  I would suggest using the start and end-level offsets for z-direction movement.  However, if there is a reason why that is impossible, or if you just want to test it out, the following equations will produce desired results.

For a desired vertical offset, z, a cross-section rotation, a, and assuming no horizontal movement is desired:

In z-direction offset enter: z / cos(a)

And then move the framing member to the right this amount: z*tan(a)

For a workplane that is not horizontal, the above equations work if vertical is taken to be perpendicular to the workplane and if horizontal is taken to be parallel to the workplane.  To get global horizontal and vertical movements, the angle of the workplane would have to be considered, as would the cross-section orientation (Normal vs Horizontal) since each case would require different equations.  Since this topic seems to be complicated enough, I will not go into any more detail on non-horizontal workplanes.

Given my affinity towards math and families, I would love to be able to incorporate these equations into the framing families (since the equations are valid for a 0 degree rotation too), but of course none of these parameters are available until after the element is loaded into a project, so I will put that on hold for now….but I reserve the right to revisit this idea!

Move with disjoin

1 Reply

I found another nice little feature (some might call a bug) about using the Move command while having the disjoin checkbox on.  The point of this option is to allow a user to move an element, say wall or beam, that is joined on either end and break that connection during the move process.

What might not be totally apparent is this will also disjoin it from everthing, if you had dimensioned to that wall the dimensions are gone etc.  If you move a level everything associated with the levels gets deleted (views, walls, columns etc.).  What I discovered recently is that if I move an element and another model has that element being monitored, then that file sees the element as being deleted.   When the coordination review is ran in another model it will see it not as moved but as being deleted. It even disjoins any monitoring.  The moral of the post, if you are using move make sure you have a dang good reason to have disjoin checked.