Showing posts with label Floors. Show all posts
Showing posts with label Floors. Show all posts

Saturday, November 23, 2019

Zoning Clearance Thoughts

A long time fellow Revit traveler reached out to me via Revit Lifeline last night asking about zoning clearance ideas. Where he lives and works they want designers to demonstrate the building is not too tall. They also want them to prove it doesn't extend into a zone that leans back into the site. All in all the code reduces the size of the building that can be built on any given property that falls under its jurisdiction.

I have heard and read about this concern many times over the years. But in response last night, I mocked up a quick example to see if it met his needs (waiting to hear back). I thought, "Blog post? I just posted something the other day...don't get carried away. Yeah, but you've only posted like twice this year slacker! So a blog post it is then..."

Here's a few images to ponder first. Pretty fancy house design eh? Doors and windows are so last century. I CAN design YOUR next home, just call when you're ready...operators are standing by.





The upper surface is a thin floor which is manipulated through Dynamo and Shape Editing. Lauren Schmidt's LandArchBIM blog is a very nice source for land techniques and I stole her graph ideas in this post to make it. Her post explains the technique relies on a sub-region to match whatever hardscape shape (property boundary in this case) is necessary. I used the floor's offset parameter to move it up above the surface by the zoning height required.

The front and back property boundary clearance requirement is built with a railing and profile. The fact that railings can be hosted by toposurface now opens this door wide. The surface form might not lend itself to a nice clean railing though, mileage will vary. You can see the rear railing is a little deformed in a couple spots. I built parameters into the profile so I could (using types) vary the height of the angle portion, change the angle, change the height above property (spring point of the lean) and the thickness of the railing.

I created a specific material to assign to it all so it can be mostly transparent.

My example is admittedly simplistic. How many property boundaries are really a simple rectangle? Pretty rare, about as rare as a purple unicorn that uses Revit? A front or rear boundary that has arcs and many segments will probably pose some issues creating a hosted railing. I can imagine things going wrong but I'll wait until I'm dealing with something specific to worry about that.

The file I mocked this up is in Revit 2020.2 and the dynamo graph (link has both RVT and Graph) is so simple that this screen shot would help you build it nearly a fast as downloading and opening it up. That's what I did with Lauren's example. You do need the packages I've circled.


Oh, the mockup has a massing element too, you'll have to turn massing on though. At first I thought I'd sweep a profile along the property edge defined by the upper surface. After I did that I thought of the railing. The learning curve is much less steep for a railing than massing, bonus being much faster too.

Decided to add a couple more images. I realized that I could have turned off the sub-category Interior Edges for Floors to hide the tessellation in the other images. It also occurred to me that another railing and profile configuration could deal with the top. I just created another type from my existing profile family to make it a 90 degree railing. A separate wide profile without a vertical portion would provide just a top surface. The floor and railing approach don't result in the same surfaces but within reason? If reason can be applied to a zoning requirement?



Here's both visible...


Tuesday, February 20, 2018

Copy Monitor - A Different Way?

Morning musing...

It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.

C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.

Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.

I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.

For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."

Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.

This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.

I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.

Wednesday, April 22, 2015

Wish - Copy, Rotate and Mirror Sub Elements

I really wish I could copy Split Line or Point while using Modify Sub Elements. It's really quite silly that I have to sketch or pick to place these things over and over (and this is a 2016 image...so no joy there either).



Wednesday, February 25, 2015

Need a Ceiling Tool

Revit Workflows and Auto Floors Builder are two 3rd party applications that tackle the task of creating floors more efficiently. Revit Workflows is focused on finish floors and Auto Floors Builder has a more structural focus. While I think Autodesk ought to tackle this sort of refinement directly it is great that there are some options.

Where are equivalent tools for creating ceilings? Is the API holding development back or are they just still on the drawing board? My inquiring mind is curious...

Thursday, February 12, 2015

Visibility of Floors and their Parts

Floors are unique in that Revit will show them even if they are below the view range settings of the view (floor plan). They'll be visible until they exceed 4' (1200mm) below the level. Parts that are created from floors won't. In fact parts created from a floor that is at the level of the view (in other words, normal) won't show up either.

It is necessary to adjust the View Range to permit the parts to be visible. It would be more consistent with floors if their parts assumed the same quirk capability.

Thursday, December 18, 2014

Creating Elevation Views and Finish Floors

If you use the finish floor approach to create individual floors for rooms they manage to confuse the Elevation tool. If you create an elevation view inside a room you will likely find that the view's crop boundary is very short.

These are two interior elevations I made. The crop region for the one on the left is good but it's floor is flush with the sub-floor (and level). The crop region for the view on the right is bad, too short because the finish floor is set so that it sits on top of the sub-floor. Quirky quirky.


Raff, a member at RFO, started a thread the other day and it reminded me that I'd created the video below, embedded here.



The video is based on Revit 2015 R2 and Update Release 5 installed.

Thursday, December 19, 2013

Copy Paste and Structural Floors

The situation this post describes seems like a bug to me. If not then it is certainly confusing least.

When we use Copy to Clipboard and Paste Aligned... to place families on another level or more than one other level the outcome is affected by whether a structural floor slab was present when the families were added. For example consider these floor slabs (see next image), each configured as shown by the screen capture of their properties. There are three desks in the view too, one on each floor. Specifically the floor on the left does not have it's Structural parameter checked, the middle floor has both Structural AND Enable Analytical Model parameters checked, and the floor on the right only has the Structural parameter checked.


If we use the Copy to Clipboard tool on the three desks (one on each floor) and then use Paste Aligned to Selected Levels, choosing Level 2 we get a dialog showing that there are two warnings associated with the desks over the two structural floors. The desk on the left is not involved in the warning.


This is what the end result looks like in elevation. We have a new desk on Level 2 above the floor that is not structural but the other two new desks are in the same location on Level 1.


At this point it appears that it is caused by using the Structural parameter. If it's checked that is BAD for using Copy/Paste. If we create a floor that is not structural the hosting relationship isn't forced on the hosted elements. If at any time we check the structural parameter any elements that you place on that surface will lock out the normal desired Copy/Paste behavior, they'll only be placed on that surface. Deciding to un-check (turn off) the option after it was turned on won't resolve the situation either. The floor can't EVER be structural. If they are/were any families placed on the floor's level will become locked in to that floor.

Said another way, this condition affects families that were originally placed on a floor that is or became Structural before the families were placed. If the families were there before the floor or before the floor was changed to structural they'll work fine with Copy/Paste. In my testing so far this condition also appears to be limited to families that are level based (also referred to as "not" hosted), for example furniture, casework, generic model, plumbing, and specialty equipment. If the families are "Face-Based" they appear to be unaffected, for example a light fixture.

We can avoid this by turning off the Floor category in the view before placing families. Changing the view to use Wireframe instead will not help.

This post is the result of looking at a project shared at RFO that was exhibiting the problem.

Wednesday, October 23, 2013

Tagging Elements and their Area

Revit allows us to tag rooms and spaces to display their area. If I'm tempted to do the same for Walls, Floors, Ceilings or Roofs the list of available system parameters (built into Revit) does not offer Area. Revit MEP users can tag a Duct's area.

It seems to me a bit arbitrary to disallow the tagging of data that is part of the element. We can see it in the element properties and include it in schedules. While a schedule is an ideal way to summarize data a floor plan is useful to provide context AND display a variety of information, like area.

It would be excellent to see more parameters unshackled.

Wednesday, October 16, 2013

Finish Floors and Doors

It's a fairly common practice to create separate floors for structure and finishes. The structural "layer" of a floor may actually be modeled by the structural consultant, assuming the structural engineer we are working with uses Revit and isn't working directly in the same model with us (architecture bias in this post).

Architects usually document floor finishes. Quite often I see this done as a Filled Region exercise. The effort required to sketch a filled region is not much different than sketching a floor boundary. The benefit of using a floor instead is that's it modeled and it will be available in many views, as needed. We can tag and schedule them to study and document the design more effectively. External applications like Revolution Design's Revit Workflows offer a specific set of tools to manage creating finish floors very effectively. KiwiCodes offers their own version as part of their Bonus Tools app. These tools make the notion of using finish floors that much easier to consider.

One side effect of modeling finish floors is that they can compromise the door graphics we use, for example the panel and swing we are used to seeing in plan views. This happens because these graphic features are usually created on the work plane of the host level. The other issue is that, even if the floor doesn't obscure the graphics, the door panel, if just lines, probably won't mask the floor finish fill pattern (if one is used).

If we create a masking region (or lines) directly in the door family, to represent the door panel it will mask the floor finish as long as the Draw in Foreground parameter is checked.


Quirkiness ensues if a nested family is used. I happen to prefer to deal with swing graphics as a nested family. My logic is to make it once and use it in many families; a "kit of parts" mindset. Unfortunately the Draw in Foreground setting fails to work when the nested component is brought into the host door family.

To resolve this we need to make it possible to raise the graphics higher. Filled and Masking Regions can be assigned to a Reference Plane; Model and Symbolic lines too. This means we can use a parameter to change the elevation of the graphics, via the parameter and associated reference plane, to compensate for various floor finish conditions. The setting Draw in Foreground will allow this to work as long as we don't check it, which seems counter-intuitive.

In this image I've use the Draw in Foreground setting on native lines and masking regions, not checked on the left and checked on the right. I've also nested a swing family. The red elements are visible and the highlighted (purplish) are not visible except that they show up because I've got my cursor hovering over the family.


To get the nested swing family to show up above the floor is was necessary to not check the Draw in Foreground parameter for the masking region and lines. It was also necessary to place them on a separate work plane in the family that I could control with a parameter to raise it above the floor elevation in the project.


In the image above the only graphics that don't show up now are the bottom left line and masking region. They won't show up because the Draw in Foreground parameter is not checked. It's easy to sort out once you know.

Speaking of 3rd party applications, I used the Revolution Design tool to create floors for my testing. The app coughed when I tried to put in some floors. After looking at the error message I noticed that the doors I was working with don't map a value to the stock Width parameter, they use their own parameter to control the width. This annoyed the floor tool because it's looking for that parameter, the stock "Width". It's hard enough for programmer's to create applications that suit our varied needs. It's even harder when we create content in a different way than what they might reasonably expect in order to complete their tasks.

At first I was a bit confused but then I remembered that their floor tool will create a sketch that turns into door openings to define where the edge of the floor will stop for thresholds. The application looks at any doors it finds along the boundary of the room and creates a sketch based on the door Width parameter it expects to find. In this case the value was zero width and that made the application mad, Revit too. It was easy to fix. I just used a formula in the Width parameter that mapped it to the parameter these doors were using instead. Just another subtle thing to consider when we make content.

Wednesday, September 11, 2013

Mass Floor Area vs Volume

I managed to trick myself into believing that area and volume for a "floor" should be the same whether a mass has one or several mass floors. To help explain my delusion, I created a mass that is a 50x50x50 cube, with five levels.


If I remove two levels from the mix (levels 2 and 5) I get twice the volume for floors at Level 1 and 4


Looking at the 3D view it immediately made sense to me. Looking at the schedule I found myself thinking something was wrong. Why is there double the volume? Why would the floor think it is so much bigger? The real problem was my perception. I was thinking floor, the thing I walk on, instead of a "floor", where I am in the building.

If it isn't obvious, the Mass Floor area is the surface area of the mass floor element. The Mass Floor Volume is the volume between mass floors or the top and bottom of the mass if there are no other mass floors.

Btw, you can select and delete a mass floor, like in a 3D view for example, and that's the same as opening the Mass Floors dialog and un-checking a level.

Thursday, July 25, 2013

Concrete Steps

Revit doesn't seem to like generating a smooth underside for some stair configurations. A post at AUGI asked about making what seems like simple concrete steps. Yes, they do look simple. The stair (and railing) features sure have a lot of buttons, dialogs and subtlety. There is definitely no easy button unless you are satisfied with whatever the stair looks like after you place two points to create a straight stair. This is the image that the original post included at AUGI.


Years ago I picked on Autodesk because the stair and railing features couldn't easily be used to make the stair in their building's own ground floor atrium/foyer. They've moved since and there aren't any featured stairs now. Coincidence? [evil grin]

Revit doesn't mind creating the steps if we choose the "Stepped" option.


This is what the sketch looks like.


Keep in mind that the "end" of a stair like this needs a riser not a boundary sketch segment. That's why the sketch line at the top of the steps is black, not green. Creating a stair that ends at a landing can be a bit counter-intuitive, I wrote a post about that condition some years ago too, it's called "A Flat Slope".

A little bit later I was doing something with a floor slab edge and it occurred to me that I could use a slab edge profile to create the steps too. So this is the result of a profile family applied to a Slab Edge type and then applied to three sides of the floor edge. I made the top step the floor so I'd have three edges to work with. If I wanted a joint between the floor slab and the step I could just make the top step a floor and create another floor behind it for the building's floor slab.


Here's the section through the steps and floor (on the left) and the profile family in the family editor (on the right).


The section of the step profile shows that it extends under the slab. I did that so I could use Join Geometry between them and clean up the lines between them. Assigning the same material to the Slab Edge type means that the concrete pattern flows between them nicely. The view from below the steps reveals the nice sloped slab edge that results from the slab edge profile. Compare that against the stepped version and this one looks more realistic from a construction perspective.


Now all I need to finish it off is a short foundation wall to close up the space behind the steps and the edge of slab. Something to consider for those little steps you need for your next project.

Saturday, May 25, 2013

Three Minutes with Floor Sloping

I wrote a reply to a thread at RevitForum.org the other day so this is really just an echo. In the context of choosing a method for sloping floor slabs (or roofs for that matter) see which approach best fits your current situation.

1) Slope Arrow - This is very effective when you know what sort of offset is required from known points but they are not necessarily at the start and end edges of the slab or in the same direction as any slab edge. Slope is defined by the location of the tail and head "endpoints" of the slope arrow. Revit will slope the entire floor according to the offset/slope parameter values you provide, between those points. It is perhaps the most versatile method other than shape editing but it is also a bit harder to become comfortable with.

2) Define one edge as slope defining - This is very easy for slabs that slope consistently overall in one direction, from one edge, and you don't really care where the other edge "ends up", it is what it is. You just pick one edge, set a slope. It is just like roofs except we are limited to one edge defining slope with floors.

3) Defines Constant Height - This too is very easy when the start and end edges of the slab also define the floor's lowest and highest elevations (and what we see as the slope value isn't the priority). You just set two parallel floor sketch lines to the appropriate elevation values, whatever values define the required offset.

Fwiw, for structural floors/roofs - Pick Supports (shape editing) - This will slope a roof according to the structural elements you select.

I took a few minutes to record a video of each approach, embedded here. It also touches on using the cantilever settings to extend the edges of a floor slab beyond the structural support members.



Saturday, April 13, 2013

Floor Perimeter

When you examine the properties of a floor you'll find Perimeter. Somebody decided perimeter shouldn't be available to tags so we can't tag a floor but we can see it in schedule (no, can't tag it in 2014 either).

If you alter a floor sketch to define an opening for something like for a stair or a mechanical chase, it alters the perimeter calculation. If you use either a Shaft Opening or Opening by Face it doesn't alter the perimeter value. Floor A is untouched, B is altered within the sketch and C has two openings one of each type. You'll see in the schedule that perimeter is not altered except where the floor sketch is changed to create the opening.


The moral of the story? If you'd like to be able to use the floor slab perimeter value then don't edit the floor sketch to create openings.

Wednesday, April 11, 2012

Wall Floor Interaction and Linked Models

When we have architecture and structure in separate Revit models we end up with somewhat clumsy graphics in wall sections. This is more pronounced if the structural slab is in the structure model only. It could look like this.


The wall continues past the floor as if it isn't there. One possible solution that allows us to keep the structural slab in the separate file and avoids the copy/monitor scenario is to place a Reveal on the interior side of the wall. The profile needs to be equivalent in size to the slab thickness and the wall thickness (inside surface plus however far the slab extends toward the exterior). This approach creates a bit better result.


I should mention that this works the other direction too, since the reveal is part of the wall it will leave a "hollow" space for the structural model's floor slab to occupy.

Tuesday, April 10, 2012

Finish and Cancel Inequity

In the past Aaron Maller and I have had long conversations that oddly enough focus on Revit. He mentioned the inconsistency between the way some elements that are sketch based are finished and the way shape editing for floors and roofs finish. He recently reminded me of it, for example he put forth this list.

Floor, roof, stair or ramp Sketch Creation = Finish and Cancel
Edit Profile = Finish and Cancel
Model Groups = Finish and Cancel

Floor or roof Shape Editing = Accidentally hitting the escape key and getting kicked out of it. We are supposed to click the Modify button to finish Shape Editing.

It would be great if Shape Editing were consistent with the others!!

Monday, January 09, 2012

Revit MEP Space Tag Shows Unoccupied Now

The alternate title I was going to use is, "More Floors Than Revit Wants".

A thread popped up at AUGI recently discussing space tags that were working but aren't now. In this case, the tags being used were made to report the linked file's room name and number instead of showing the space's own name and number. That's a common work around to avoid worrying about what a space's name and number really is.

One reply mentions that they've seen a situation where they have more than one linked file and there are floors in each of them. It's my observation that the multiple floors issue isn't just that there just are multiple floors, it's that usually there are floors that are "inside" the Space. When an architect places "finish" floors on top the structural slab (often in a separate model) they typically place the floor using an offset equal to the material thickness. This puts the floor up/inside the Space.


This seems to reduce the space to a quivering mess.

One thing that fixes it, adjust your level(s) computation height (Instance Property of a Level) so it is equal to the top or slightly above their finish floors. To avoid that, ask them (the team that gave you the file) to set their finish floors so they are not Room Bounding instead. You'll have to wait for the new file though.


Then again, another way is to just use the regular space tag (using space name/number) and the Space Naming Utility extension (free to subscription members) to sync Room names/numbers with Space names/numbers. I'm still amazed that it isn't just built into RME by now.

Thursday, July 14, 2011

The Difference Between Join and Attach

There are two kind of messages that Revit shows you regarding how walls, floors and roofs interact.

The first kind (Attach) occurs when the geometry of a wall touches a floor or passes through the floor. If you edit the sketch of a floor, when you finish the sketch Revit asks you if you'd like to attach this wall (or any other walls that intersect too) to the underside of the floor.


The point of this is to establish an "automatic" relationship between the underside of a floor and various walls. If the floor type (thickness) changes the top of the wall(s) will change as well. If the level the floor is assigned to is raised/lowered the walls adjust accordingly too. It's meant to be "quicker" than manually doing it yourself by selecting walls and using the Attach Top/Base tool. However you may want some walls to do it and others not so much. Many times the "correct" answer is NO.

Here are the results for yes and no responses (note that there is no "joining" of geometry, just the wall height is changed).


Same thing happens when a wall and roof geometry intersects except the dialog message is slightly different.


The second kind (Join) is when a floor intersects a wall, like at exterior walls. Revit asks if you want to join geometry so the cut/projection lines that it draws better represent how these elements would really intersect.


The first message does appear too, just before the second message appears. It's good to choose NO to the first so the wall does not get attached (which would change its height) and then YES so the geometry joins nicely. If you aren't cutting a section through this part of the building then you could argue there is no need to join geometry since nobody will see the clumsy connection between wall and floor.


Now for this message to appear it is necessary to "Pick Walls" and use the "Extend into wall (to core)" Option. If you don't use these then you just get the first message.


If you choose NO for both "questions" you can always use the Join Geometry tool later between any elements that need to "clean up" better. Again the point of this second kind of question is to provide a "speedier" way to end up with a better section(s) when you cut one later.

Tuesday, July 13, 2010

Dept. of Bugs - Sloping Pad Defect gets Ornery

I wrote about THIS back in August of 2009. The sliver left behind in the image below could be eliminated by taking the advice in that post. Unfortunately 2011 eliminates that technique from the ranks of viable alternatives, per Jean-Frederic Monod's comment on the earlier post.


Possible workaround? Use a pad to drop the site toposurface to the lowest elevation and then use a floor to create the sloped and flat "pads" instead??

Tuesday, September 09, 2008

Floors - Voids and Various Rumblings

[Note: The 2010 release of Revit has resolved this issue.]

I wanted to use a floor hosted family to create a "waffle slab". Simple idea really, just create a four void blend cluster that could easily be placed in a "thick" floor slab to result in a waffle slab. In experimenting with it I discovered that the floor volume is not altered unless the void cuts both the top and bottom planes of the floor. If the void only removes some of the floor material it does not alter the floor volume at all. Here is an image as an example.


Using Revit now for a little over six years I've managed to convince myself that it wasn't always this way...but I can't be too sure anymore as my memory isn't what I used to remember it to be. I also tried the trick of using it in an In-Place family too...no difference. Ideally a void ought to subtract volume from a floor regardless.

A second issue with this approach is that if it is used in conjunction with a floor slab created by Revit Structure that uses the metal decking profile feature...the void family will kill the display of the profile for the entire slab.

These two issues "killed" this approach for me, shame too as it would have been "easy".

A third oddity before I go, regarding the new Mass Floors feature. If you try to create a Calculated Value that uses the Floor Volume parameter Revit will reject it as an invalid parameter name. Trouble is that it is a system parameter! Here's a couple images that depict the issue.

When you examine the parameter heading value under the Formatting Tab in Schedule Properties you'll find an "extra" space at the end of the parameter name. It's my guess that this is getting Revit annoyed.

Oh all right, since I'm on a roll one more...this is hardly the only such element with this issue but you can't tag a floor with Area, Volume or Perimeter data even though the element clearly knows what they are.


Per a comment I've POSTED the file if you are interested in the "waffle" family though it doesn't really "work" for the reasons that I listed above.