Revit Floors (open letter to developers)

[eldad]

I have a major problem with floors in Revit since version 5.

In short, I can’t trust Revit!

In long, my floor keeps on moving, it seems that when a wall is attached to a floor, moving this wall will change the floor sketch, this is a fundamental need, Floors must not move! I don’t care if walls attached or not, nothing should affect the floors, simple as that!

I just had enough of this ludicrous issue, forever and ever I have to amend my floors sketch, you guys need to fix it, it looks like Revit is still stuck on the 200m2 average home plan, as soon as you draw a floor that is big and not square, something goes wrong.

I don’t want to know about, splitting the floor into smaller chunks, or creating an external floor family and importing it in (that what I have to resort to) we shouldn’t need to find a workaround for a simple fundamental function as a floor.

So please Revit developers, for the 10th time, do something about it.

thanks

[sonya]

i have found that the only (mostly) reliable way of big floors is to draw them with sketch lines, and never, never, ever use the pick walls tool to create the floor - to limit the association the floor makes with the wall

[eldad]

I know mate, that's the only way I draw, but this does not change a thing.

my floor plate is 4500m2 and Revit can't handle it.

[truevis]

i have found that the only (mostly) reliable way of big floors is to draw them with sketch lines, and never, never, ever use the pick walls tool to create the floor - to limit the association the floor makes with the wall
Even without picking walls for the sketch, I've found there to be an unpleasant relationship sometimes that can mess the floors up if I manipulate walls.

Anybody got tips to avoid this?

[rjcrowther]

Whilst I have never drawn a 4500 sq.m floor I also have not been able to get the pick walls option to do the right thing. I now exclusively sketch lines even though I have read several recommendations to use the pick walls tool. It seems to be worse when the wall type is cavity brick rather than a single leaf .

My solution to floors has been to model them after the walls are set. Although the walls usually change between design stages it is the best I have been able to do.

I also have a problem where the roof just bombs out on occasion when the walls drastically change (residential) causing the removal or inclusion of a hip or valley.

It is just something I have excepted.

Rob

[eldad]

It seems the bond between the floors and the walls is too strong, they are 2 separate elements, one should not affect the other.

the point is, that it does not matter how we draw the floors, they should work. this issue has been going on for a few years now...

[Tobie]

Just to check the process. I drew a 4500m² floor. Added some walls inside the floor area. Moved them to over the floor edge. Then moved all the walls in different directions and the floor stayed the same. I drew the floor with lines and not with picking walls. Could you post your file with only the floor and walls please?
Cheers,

[eldad]

Just to check the process. I drew a 4500m² floor. Added some walls inside the floor area. Moved them to over the floor edge. Then moved all the walls in different directions and the floor stayed the same. I drew the floor with lines and not with picking walls. Could you post your file with only the floor and walls please?
Cheers,
tobie,
The problem arises when your floor is a little complicated (i.e. not a square)

The problem is not with the file, this is not the first project this is happening. My file is about 90meg at the moment, I appreciate your willingness to check the file, but believe me when I say it’s a Revit problem…

J

have a good long weekend...

[SkiSouth]

Eldad,

Have you used reference planes to define the edge of the floor? It is an extra step, but when I first started Revit (years ago), the BIG rule was ALWAYS use reference planes. So when something must stay put I was taught (in this forum) to set a reference plane, lock (pin) it, then lock the associated object to that plane. It doesn't mean that the object can't move, but you must unpin the reference plane, then move the plane to move the object.

[aaronrumple]

The associtivity of floors/ceilings has saved me big time on changes over my years using revit. I think its a great feature. Pin/Move with Disjoin/Cut and Paste/Sketch constraints are all techniques that can be used to fix an object

[sbrown]

I agree with aaron The floors should move with the walls. I'm not understanding what is happening to you guys. I work on extrememly large project with complex floors and occasionaly when I move a wall I have the floor sketch is invalid message and have to use move disjoin instead of straight move. But I WANT the floor to move with the wall usually.

[sfaust]

I'd have to agree with Aaron and Scott. I think the floor/wall associativity is one of the best features. I haven't done a building quite that large, but we have some complicated floors and other than the occational invalid sketch thing it's always done exactly what I wanted. I use the pick walls tool whenever possible...

[jeff.95551]

I've been begging for some kind of 'hard' pin for some time to address this issue. I think generally the floor/wall relationships work, but we do complex projects with multiple floors and often multiple floor types mixed in on one floor, and dealing with wandering floors is a constant and very frustrating issue. We NEVER use pick walls, and I am about to give in to my collegues in the office and NEVER use the join tool with a floor, either. I have one section of a building where the floors keep shifting back and forth, and every time we discover that we have to spend the time to check the entire floor boundary. On a residential project it might be a nuisance, but on a 300k + mixed use apartment/parking/retail structure, it is positively infuriating, especially when you are at 90% and just trying to do simple cleanups for documentation.
A simple tool that locks an element and doesn't allow changes would be very easy to implement, and for us at least, would completely solve the problem. I have spent 35+ hours in the last week dealing with the fallout from 'smart' elements moving when they aren't supposed to, and coming to grips with the fact that I have no real control over the model. If it weren't for a cold brew (or three) at the end of the day, I'd probably be in jail right now.

Jeff

[twiceroadsfool]

I agree with Aaron and Scott, but i am SERIOUSLY IN FAVOR of a Hard Lock / Hard Constrain tool.

We have floors that are divided up, because theyre getting demo'd and repoured, around new columns. Now, the Dim to be held is off the column line, not the wall behind the column line... But the walls keep moving slightly, and it keeps jacking the floor.

Now, obviously, the answer is just to constrain the sketch of said floor to the column line... But with a team of 6, i try not to constrain too many things, or people move items without taking note, and nothing "appears" to have moved, etc...

The constraints are great (locked dimensions), but a HARD LOCK would be great.

Otherwise, i love floors just the way they are. :)

EDIT: Also worth mentioning... Ive worked in a program that REQUIRED diligent constraints everywhere... its a nightmare. Ill take whatever hardships come packed in with Revit trying to figure out what assumtopins to make about moving walls and floors... Its certainly better than the alternative. :)

[Jit]

We had similar problems and we solved them (atleast for us) by modeling inplace floor.

[hand471037]

The constraints are great (locked dimensions), but a HARD LOCK would be great.

Otherwise, i love floors just the way they are. :)

EDIT: Also worth mentioning... Ive worked in a program that REQUIRED diligent constraints everywhere... its a nightmare. Ill take whatever hardships come packed in with Revit trying to figure out what assumtopins to make about moving walls and floors... Its certainly better than the alternative. :)

You bring up a very good point here. 'Hard Locks' are not as easy to work with overall. I, too, have worked with some software (Alibre Design and Maya) that used 'hard' constraints for things, and well, once you get above a few simple relationships it becomes so complex that it adds a not insignificant amount of overhead to working with the model.

It's weird, but part of the learning curve of Revit is understanding how it's interpreting your modeling and what behavors it will impart to things depending on how and in what order you model them. It's a pain, yes, but it's less pain than the systems I've used that require one to either manually set up all relationships (Maya) or auto-assocate every single thing (Alibre). I've found that Revit, 90% of the time, sets a happy medium between these two extremes.

So while I think a 'hard lock' is a great idea for Revit, the dev team would have to add it in an eloquent manner I think to really have it be useful.

[twiceroadsfool]

You bring up a very good point here. 'Hard Locks' are not as easy to work with overall. I, too, have worked with some software (Alibre Design and Maya) that used 'hard' constraints for things, and well, once you get above a few simple relationships it becomes so complex that it adds a not insignificant amount of overhead to working with the model.

It's weird, but part of the learning curve of Revit is understanding how it's interpreting your modeling and what behavors it will impart to things depending on how and in what order you model them. It's a pain, yes, but it's less pain than the systems I've used that require one to either manually set up all relationships (Maya) or auto-assocate every single thing (Alibre). I've found that Revit, 90% of the time, sets a happy medium between these two extremes.

So while I think a 'hard lock' is a great idea for Revit, the dev team would have to add it in an eloquent manner I think to really have it be useful.

100% agreed. All of these forums, ill make reference to a situation with a Roof pitch and a gutter that kicked my behind, but that was the issue of a hard constraint.

When working in teams, its very tough to delineate a METHOD for hard constraints, and keeping everyone in check.

Well, a Roof was modeled, and a Roof Gutter was modeled as well. No one was suer how the gutter was constrained to the Roof, but altering the roof pitch created an 8 hour disaster becuase the gutter became overconstrained, and broke. In Revit, we would simply delete the gutter and start over... But in Hard Constraint world, that meant The downspouts were gone, the gutter was gone, etc...

I should rephrase my desire... I dont want a HARD LOCK, i want a HARD PIN. The kind that says "Sorry, this object IS NOT MOVING" whenever something tries to affect its position and/or geometry. I know it would be annoying, but i want to pin a set of grids, and know that its NOT MOVING. giving someone one extra dialogue box to read and not stopping them is futile if people wont read them anyway, hehehe...

[truevis]

...I should rephrase my desire... I dont want a HARD LOCK, i want a HARD PIN. The kind that says "Sorry, this object IS NOT MOVING" whenever something tries to affect its position and/or geometry. I know it would be annoying, but i want to pin a set of grids, and know that its NOT MOVING. giving someone one extra dialogue box to read and not stopping them is futile if people wont read them anyway, hehehe...
Yes, as someone else mentioned in another thread, we could use a NAIL, not just a pin. I'd even like to see the nail require a password to extract it.

The nail would also keep objects from being deleted.

[jeff.95551]

I guess I don't understand what would be so hard about it. If I have a floor that is 'hard' pinned, and I move a wall (or change a wall, or look at a wall funny) such that it wants to move the floor, I can get a dialogue that says - object is 'hard' pinned (or whatever the name is) - Unjoin or Cancel?

Done.

[Scott D Davis]

what if, while creating the floor sketch, you dimensioned the sketch lines, and then locked the dimensions? Then finish sketch.

[dhurtubise]

This is pretty much what i do all the times. Keeps my floor tight to the walls without problems.

[sonya]

.. another rant ...


having the floor move around with the walls is fine and dandy if your building is rectangular and simple. what works for one company & their projects & workflow doesn't necessarily work everywhere

the moment the building becomes irregular and complicated (we had min. 20,000 m2 floor plates, min. 160 vertices in the floor, curves, multiple angles other than 90 degrees, and multiple oddly shaped openings (voids, lift cores, stair cores) in the floor & 4 or 5 people in the model all the time) you find aligning a bit of floor to wall here does something quite unexpected over there and quite frequenly on saves to central revit can't reconcile the wall moved by a co-worker and deletes your floor 'cause they automatically clicked on OK when confronted by "invalid sketch" and an ID number.
"Oh look", you say some time (hours, days) later "the level 2 slab has disappeared again"
repeat.

[jeff.95551]

I don't want to get started on the 'delete instances' issue. I'd like to have been in the programmers meeting when they decided that if Revit can't figure out what to do, it'll just ask your permission to delete a whole bunch of random stuff, and it'll all be ok. What a lame cop-out.

Scott - I'd never looked at constraining a floor from inside the sketch. Do you still get the Unconstrain/cancel dialogue when you want to move something? Or does it try to propogate the changes throughout the entire building when it moves the floor?

I still vote for a hard pin.

[twiceroadsfool]

I don't want to get started on the 'delete instances' issue. I'd like to have been in the programmers meeting when they decided that if Revit can't figure out what to do, it'll just ask your permission to delete a whole bunch of random stuff, and it'll all be ok. What a lame cop-out.

I still vote for a hard pin.

While i agree with you on the hard pin, i have to disagree with your previous statement. It may be a cop out, but at the end of the day there is a user clicking Okay to delete something.

I harp on the users here RELENTLESSLY. If you DONT know what a message means, you SHOULDNT be clicking okay.

I fully concede that the jargon used in messages isnt the most friendly for people who arent the overly technical type, but you cant close your eyes and click okay claiming ignorance in the 11th hour, either.

Last time someone clicked okay here, and didnt know what they were clicking, they completely altered the shared coordinate location of a linked model, that was tied to 12 other linked models, lol...

For the SAME reason, if there ever WAS a Hard pin, i dont believe there could be a dialogue to say "unjoin or cancel." Unless you mean disjoin from the hard pinned object. I just dont think there could be a prompt to "un-nail", or wed be in the same boat.

[jeff.95551]

TwiceRoadsfool: "For the SAME reason, if there ever WAS a Hard pin, i dont believe there could be a dialogue to say "unjoin or cancel." Unless you mean disjoin from the hard pinned object."

That's exactly what I meant. There are lots of places where Revit prompts us to Unjoin or cancel. The consequences to unjoining are minor at worst, so I always click Unjoin.

I stand by the first part - there's no excuse for putting a choice in front of people that they are ALWAYS going to reject. That's not a choice - it's a copout. If you expand the dialogue, you can see the element number(s) that you will delete, but since you are in a dialogue, you have no way of finding out what those are. Since people generally trust Revit (for good reason), they tend to assume that the software wouldn't put a choice in front of them that it didn't want them to take. So they hit it without reading. That's wrong, but no worse than the Revit team giving them the choice in the first place.

Jeff

[twiceroadsfool]

TwiceRoadsfool: "For the SAME reason, if there ever WAS a Hard pin, i dont believe there could be a dialogue to say "unjoin or cancel." Unless you mean disjoin from the hard pinned object."

That's exactly what I meant. There are lots of places where Revit prompts us to Unjoin or cancel. The consequences to unjoining are minor at worst, so I always click Unjoin.

I stand by the first part - there's no excuse for putting a choice in front of people that they are ALWAYS going to reject. That's not a choice - it's a copout. If you expand the dialogue, you can see the element number(s) that you will delete, but since you are in a dialogue, you have no way of finding out what those are. Since people generally trust Revit (for good reason), they tend to assume that the software wouldn't put a choice in front of them that it didn't want them to take. So they hit it without reading. That's wrong, but no worse than the Revit team giving them the choice in the first place.

Jeff

Got ya. For the first part, i just wanted to clarify that you meant "unjoin" as in "separate from Hard Pinned Object" and not unjoin as "click here to UN hard pin".

I agree with you that the choices were currently given arent great, when its going to delete items, but if thats the only choice youre currently given, you cant simply click "delete" and undo peoples work because its accomplishing YOUR task, youve got to find a way around it, in my opinion.

[Maximillian]

Yes, I like the floors to move with walls , otherwise what is the point? if you have to go around and change walls, floors and roofs. Using lines without locking them, should keep them unassociated i would think.

[eldad]

Well, obviously this is an issue that affects many people, we all know the workaround to get things done, but so many of us spending so many hours fixing floors! This is even worse when you got a dead line and about to issue 50 or so sheets and suddenly you realise that your floor is out, and even worse than that is WHEN YOU DON’T NOTICE, and you get a call from site and they are about to pour the concrete!

You get the point.

Something need to be done about the floors, I don’t want them to move with my walls, sometime Revit is trying to be too smart. I drew the wall where I want it and this is where I expect it to stay, same for every other element in my project. You can’t seriously tell me that you trust Revit 100% when you move walls and your ceiling sketch moves with it, you still have to check.

Where are we going with Revit inelegance? Do we expect to sit in front of the computer and just “think” about the project and Revit will draw it?

Sometime it’s too smart for it’s own good… one must be very careful in not passing to much responsibility to a computer program J

[sbrown]

Can you identify what makes the floor move in a way it shouldn't. If so can you you submit it to the developers? This letter here is nice for a discussion, but if they can't reproduce it and understand your process they cant fix it.

[jeff.95551]

The problem is that you don't know things have changed until later when you notice in a section or floor plan that somehing is in the wrong place. The only clue it is happening is when you do a simple operation that seems to take much longer than it should. I've learned that in those cases the best action is Ctrl-Z, and then figure out a different way to do what you want, like move-disjoin. Unfortunately you don't usually get that warning.

[eldad]

Can you identify what makes the floor move in a way it shouldn't. If so can you you submit it to the developers? This letter here is nice for a discussion, but if they can't reproduce it and understand your process they cant fix it.
Sorry, there is no way for me to find out excatly which element causes the floor to move, it can be a simple thing as moving a wall by a few mm, the problem is not project specific but rather a Revit one.
Like Jeff said, by the time you notice it, it's too late...

[sbrown]

I've had floors / lines etc move on me and there usually are clues that something "bad/unwanted" is happening. Look for additional regen times, slower response. Basically if you feel a command took too long, it is probably messing up your floor and you can then pass on what you were doing to adsk and hopefully they can figure out the problem.

Note I'm not trying to say that the current behavior is correct or user error. I just know they can't fix something if they can't document the process causing your pain. They also won't just create a magic button to Nail something down just because we ask for it.

[affdesco]

Do you use Grid Lines to establish your project. With Grid Lines set and levels set at the project beginning... then snap, align and lock the walls to the Grids, then snap, align lock the floor lines to the grids and or walls. When you make changes... change the grids only. I'm sure this is not everyone's pick but it is my 3rd generation solution. I found problems snapping / aligning to walls in that I would make mistakes when the wall had additional members.. ie.. plywood, stucco, etc. where I would accidentally snap to the stucco or plywood references. That is why I moved to the Grid process.

[gordie_v]

Well, obviously this is an issue that affects many people, we all know the workaround to get things done,

This is not in fact a workaround
there are many ways to create a floor
with some ways the floor moves with walls
with some it wont'

it seems to me what your problem is is user training and office/project standards.

If you are doing a project like post tensioned concrete structure where the floor location is more important than the wall location, then your work flow will be different

you need to find a work flow that works for you and make sure everyone knows that. this is how it becomes "the Way" and not a work around

[iru69]

it seems to me what your problem is is user training and office/project standards.
This does not reflect a full appreciation of the issues.

An example that just happened to me yesterday:

I had a building drawn. I added an "existing" sidewalk drawn as a floor slab. I created it using sketch lines (not by picking walls). I aligned the sketch line with the perimeter of the wall, but I did not "lock" it to the wall. A while later, I went to move a wall of the building that was in alignment with the sidewalk. The sidewalk line moved as well, and because of the extent in which I moved the wall, the sidewalk became "invalid", and I forget the exact dialog box, but because I didn't hit cancel, the sidewalk was deleted. So, I did "undo" and attempted to disassociate the sidewalk from the wall, but no easy way to do that. I finally re-edited the sidewalk so that I could manually pull the sketch line away from the wall, then moved the wall, and then re-edited the sidewalk to put the sketch line back where it was suppose to be.

But I'll get right on those office/project standards. :?

[sbrown]

but no easy way to do that. I finally re-edited the sidewalk so that I could manually pull the sketch line away from the wall, then moved the wall, and then re-edited the sidewalk to put the sketch line back where it was suppose to be.
:?


When this happens, copy/clip your floor to your clipboard, make the wall change, then paste/align/sameplace the floor back into position. When you draw lines revit keeps the lines position RELATIVE to walls so the behavior you see is supposed to happen. knowing that if you draw lines you will see a check box for "moves with nearby elements" uncheck that for your side walk lines then you should be ok.

[Maximillian]

"moves with nearby elements" .

seems to be the culprit!

[Jos Arpink]

I'm a Revit Structure user and I think that most RS users would agree that floors moving on their own is generally unwanted behaviour. To illustrate this, in the screen shots attached, 2 slabs of different thickness meet at about midspan between the walls. Changing the wall thickness causes the adjacent slab to 'follow' and opens a gap between the slabs.

As per an earlier post in this thread, one way to prevent this unwanted behaviour is to dimension/lock the floor's sketch line back to some reference. I need to do this for each of the 2 slabs.

The cut/paste-same-place idea is not something I like because it's not neutral to the documentation. Dimensions, tags, etc will have to be redone for the new instance of the slab.

Another workaround is to take all the bits of slab and Group them. This defeats Revit's behaviour of wanting to 'move' slabs with walls, but forces you to clean up slab edges after walls have changed. Probably something we would prefer to do ourselves rather than have Revit make assumptions.

Hope this serves to illustrate the issue. We probably really want it both ways were the supported edges would adjust and the 'free' edges would not.

[samov]

seems to be the culprit!

well... i normally use "moves with nearby elements" when i want the DO NOT MOVE THIS behavior ... and it seems to have worked ok so far...

Try implementing this checkbox more oftern...

The problem i have:

The "normal" lines i let move around SHOULD be different than those i do not. The fact that the checkbox is on or off should be visible... (just like the Defines slope in roofs make lines have a small something to tell them apart).

Maybe then, people would use this more often as it is quite a usefull checkbox.

[truevis]

well... i normally use "moves with nearby elements" when i want the DO NOT MOVE THIS behavior ... and it seems to have worked ok so far... quite a usefull checkbox.

Um, where are you finding that parameter or floors, their sketch lines, or walls?

[samov]

Sorry for the misunderstanding... I composed the message while reading something else and never bothered to read it back to see if it made any sense...

"well... i normally use "moves with nearby elements" when i want the DO NOT MOVE THIS behavior ... and it seems to have worked ok so far..." i was talking about compenents and their check box...

"The problem i have:" was supposed to be a suggestion for implementing this option in lines...

If we were to have this option it would be really nice to have visual feedback ( just like the blue dimensions ). Revit is about relationships between elements and sometimes it's hard to figure out what is tied to what when modeling.

Read it back twice... hope i start making sense now.