show existing rooms in "show previous and demo" phase

[Anonymous]

Can you please address why new rooms show up in lieu of existing rooms when"show previous and demo" are set for the phase filter?  Every single other existing element including doors, walls, windows, etc. show in the "show previous and demo" phase filter with the exception of rooms. Thank you.

[MKFreiert]

it won't work for all of the reasons we've given over and over and you say we haven't listed. y

but once more: no other object in revit behaves like a room because of what they're used for, and how complex their relationships are. linking multiple instances together will cause problems for most users most of the time. if nothing has changed, you don't need multi phase data, but if anything has changed, the entity in and of itself is a different instance.

it's like relocating an HVAC unit. you demo the old one, and replace a "new" one, even though it will be the same physical unit. it's different. it's NOT the same fixture even if all that's changed is it's location.

in the case of rooms, though, just changing the phase changes it, so you have to demo it. you could make calculation points persist, and auto populate a room in a future phase, but then you'll need to manage creation and demo phases for every room, which would be a huge headache, since the point of phasing is that things change.

[MKFreiert]

and what you're asking for is to workaround the model, to falsify data in it.  bad practice.  

[mastjaso]

---

@MKFreiert wrote:
it won't work for all of the reasons we've given over and over and you say we haven't listed. y

---

I said they've been refuted. Not that you haven't given any.

---

@MKFreiert wrote:

but once more: no other object in revit behaves like a room because of what they're used for, and how complex their relationships are. linking multiple instances together will cause problems for most users most of the time. if nothing has changed, you don't need multi phase data, but if anything has changed, the entity in and of itself is a different instance.

it's like relocating an HVAC unit. you demo the old one, and replace a "new" one, even though it will be the same physical unit. it's different. it's NOT the same fixture even if all that's changed is it's location.

---

You are correct, it should be treated just like an HVAC unit. If it moves, you demo the original, and place a new one with the same tag. But if it's existing, it stays where it is and has no demolished phase.

---

@MKFreiert wrote:

in the case of rooms, though, just changing the phase changes it, so you have to demo it. you could make calculation points persist, and auto populate a room in a future phase, but then you'll need to manage creation and demo phases for every room, which would be a huge headache, since the point of phasing is that things change.

---

Changing the phase doesn't change the room though. It might change the wall cover, or it's volume, but it doesn't need to change the room itself. The room could persist with different volume properties for each phase. Managing the creation and demo phases for every room would be no more of a pain than managing the creation and demo phases of literally anything else. Want it gone, just set it's demolished phase. It's not complicated and would provide much more consistent behaviour for users.

You're talking about me working around the model by faking things, but that is *precisely* what you are describing doing. If an existing stairwell or neighbouring office stays the same, you are proposing that in your model it should be deleted, and a new one added, even though that's not what's actually happening. Rooms as they are are forcing us to fake them, rather than modelling the actual building.

[MKFreiert]

YES. YES IT DOES.   

from a model perspective, and a database perspective, it changes.   i don't know how i can be any clearer about this.  the data associated with it changes.   i get that you do not understand how or why this is true, or what implications that has, but it changes.  

a balloon that has been inflated is not the same object that was sitting on your desk yesterday.  

you say they should be treated like an hvac unit, and they ARE.  because they have to change they are in effect automagically demolished for you.

elements in revit functionally exist in (at least) 4 dimensions.  xyz and time.   when you change the phase of walls of the room, your are changing their time.   the room changes.  since everything involved in a room (other than its calculation point) has changed, it has to be a new item.  

[mastjaso]

---

@MKFreiert wrote:

YES. YES IT DOES.   

from a model perspective, and a database perspective, it changes.   i don't know how i can be any clearer about this.  the data associated with it changes.   i get that you do not understand how or why this is true, or what implications that has, but it changes.  

---

I don't think you understand how the revit database works or what I'm proposing then.

In the database every room is represented as a Room object. Each room object contains properties for it's name, number etc, as well as an object that stores it's volume in a series of XYZ coordinates. The "Room" object could instead have 2+ volume objects, each one corresponding to a phase within a project. But the key is that then the room itself doesn't need to change from phase to phase so all the other properties stay the same. When revit goes to display a room it would just query the room object for the volume that matches the current phase / phase filter.

---

@MKFreiert wrote:

you say they should be treated like an hvac unit, and they ARE.  because they have to change they are in effect automagically demolished for you.

---

If they're automatically demolished no matter what then they do not behave like HVAC objects.

---

@MKFreiert wrote:

elements in revit functionally exist in (at least) 4 dimensions.  xyz and time.   when you change the phase of walls of the room, your are changing their time.   the room changes.  since everything involved in a room (other than its calculation point) has changed, it has to be a new item.  

---

This is not true, nor representative of how rooms exist in the Revit database. By this logic, every time you move a bounding wall, Revit would delete that room object and create a new one. But this is not what Revit does, when a wall changes Revit simply updates the volume property of that room, but the room itself never ceases to exist from the database. You can solve the problem of changing walls by just having a volume property for each phase of the project since the walls / bounding elements will only ever change with each phase.

[MKFreiert]

i understand exactly what you're proposing, and have repeatedly explained why it doesn't work.  apparently i'm not doing a good job of communicating that to you.

objects do not have only xyz coordinates.  they also have time.  revit is 4 dimensional (actually 4D plus, but that's a different discussion)

the room calculation point generates the data about the room by looking at relationships relative to that point within one phase.  

if the calc point persists to a new phase, all of the data that it would generate is related to functionally different objects, because those objects have changed time.     

the way walls etc. deal with things cutting/cleaning up with them is coarsely explained as nested boolean interactions.  with a room you have a minimum of 6X the number of booleans vs any other object.  that gets wicked complex when you add in time shifts as you need to rectify all of those booleans across at least 2 time slots, in addition to dealing with objects that persist in both, but have changed some relative volume.   you can't merely recalculate because from a data standpoint you don't know that anything has changed until you do the comparison. 

yes, when you move an hvac unit, you delete it and recreate it.    rooms deal with time.  they are a snapshot of relationships at one point in time, and time is an axis.  you can't move an object relative to the axis you placed it on.  "model" elements are on xyz and can persist across time.  rooms are on T and can expand across xyz.  

when you move one wall at a time, revit only needs to recalculate one progression of booleans.  calculating multiples that move when you change phases isn't the same as recalculating a "new version" of the room, because then you already have a new room, and calling 2 things the same thing in a database is bad.  

no, every time you move a bounding wall revit does a recalculation of the *same* room, which is fine and much less complex.

[mastjaso]

---

@MKFreiert wrote:

i understand exactly what you're proposing, and have repeatedly explained why it doesn't work.  apparently i'm not doing a good job of communicating that to you.

objects do not have only xyz coordinates.  they also have time.  revit is 4 dimensional (actually 4D plus, but that's a different discussion)

the room calculation point generates the data about the room by looking at relationships relative to that point within one phase.  

---

The only "time" properties that objects have in the Revit database are phase created and phase demolished. These are stored as "CreatedphaseID" and "DemolishedphaseID".

---

@MKFreiert wrote:

the room calculation point generates the data about the room by looking at relationships relative to that point within one phase.  

if the calc point persists to a new phase, all of the data that it would generate is related to functionally different objects, because those objects have changed time.     

---

Yes, so you store multiple copies of any generated data (such as room volume) with one copy per project phase.

---

@MKFreiert wrote:

the way walls etc. deal with things cutting/cleaning up with them is coarsely explained as nested boolean interactions.  with a room you have a minimum of 6X the number of booleans vs any other object.  that gets wicked complex when you add in time shifts as you need to rectify all of those booleans across at least 2 time slots, in addition to dealing with objects that persist in both, but have changed some relative volume.   you can't merely recalculate because from a data standpoint you don't know that anything has changed until you do the comparison. 

---

I don't really get what this has to do with anything. Nothing changes in how Revit calculates a room. It just has to do it once per phase and store that information. The only "time shifts" that exist in the database are the different phases.

---

@MKFreiert wrote:

yes, when you move an hvac unit, you delete it and recreate it.  

---

Yes, and if you were to move a room to a different spot you would demolish it and recreate it, but HVAC units remain as existing if you don't demolish them, as should rooms.

---

@MKFreiert wrote:

 rooms deal with time.  they are a snapshot of relationships at one point in time, and time is an axis.  

---

That is not how the Revit database works and I think you misunderstand how sophisticated "time" is in the Revit database. The only thing related to time is the phase created and phase demolished properties. Once again, some of rooms' properties (such as volume) are a snapshot of relationships at "one point in time" which really just means "during one phase". Rooms can exist across phases if they just store multiple snapshots of this information (one snapshot per phase). 

---

@MKFreiert wrote:

 you can't move an object relative to the axis you placed it on.  "model" elements are on xyz and can persist across time.  rooms are on T and can expand across xyz.  

---

That may make hypothetical conceptual sense but that is not how the database works. Rooms inherit the element class the same as every other object. They have  XYZ coordinates, volume / boundingbox properties and they even have phase created and phase demolished properties, they're just always set to the same thing.

---

@MKFreiert wrote:

when you move one wall at a time, revit only needs to recalculate one progression of booleans.  calculating multiples that move when you change phases isn't the same as recalculating a "new version" of the room, because then you already have a new room, and calling 2 things the same thing in a database is bad.  

no, every time you move a bounding wall revit does a recalculation of the *same* room, which is fine and much less complex.

---

If you were to move a wall in your New Construction phase, Revit would recalculate just the "New Construction" snapshot of information for your room (including volume). If you were to move an existing wall that gets demolished, then Revit would just calculate the "Existing" snapshot of information for that room. If you were to move an existing wall that doesn't get demolished, then Revit would have to run that calculation once for your Existing phase, and once for your New Construction phase. But those two snapshots of information would both still be stored in the same Room object, there would be no duplication of Room objects in the database.

It adds a little more computation, but only when moving existing walls, and even that scales by a factor equal to your number of phases.

[AaronEllsworth]

---

@MKFreiert wrote:

mastjaso

it seems that there are some things you don't understand about revit, and that's fine, it's what this forum is here for. to learn about your tools and how they work.  we all learn from each other.  

---

metisdesigns, who ever you are, are you aware of how arrogant and condescending you come across? Its really quite unpleasant, and unnecessary. A softer, more respectful tone will get you far more success.  Listening to those with whom you converse would also be worth doing.  You keep commenting on how this issue is a dead horse, and you keep having to beat it, but you're actually beating up your fellow Revit users, and to what end? I love Revit and your defense of it won't change that, but it also won't change my opinion that some features of the program need further development.  Phasing is one of those things that is a little half-baked. As another example of a phasing problem, wall openings can only take the phase of the host wall, but what is stopping them from behaving just like doors where I can put a new door in an existing wall? In order to put a new opening in an existing wall I have to do something besides the obvious choice of a wall opening, but that is a topic for another thread.

[ToanDN]

---

@ToanDN wrote:

---

@MKFreiert wrote:

Existing

Demo

New Construction

within those:

elements to be existing to remain:  phase created Existing (no demolished)

elements to be existing and demolished:  phase created Existing, phase demolished Demo

copy rooms from Existing to Demo

to show existing + demo, Phase Filter should be set to existing + demo while Phase is set to Demo.

---

Aside from the overlapping Rooms because the some of the boundary have been removed, and as long as I don't need to show Room Area on the Room tags, I think your solution by far the best.

---

@MKFreiert Now thinking about it, under which phase would you pop a new door in an existing wall?

- If you add the door under Demo phase, then on the new plan, it will show as an Existing door, where as a new door added in a new wall will show as a true new door.  Graphic difference aside, the schedule can be come a mess too.

- If you add the door under New phase, then the demolished portion in the existing wall will not show under the Demo plan, since the demolish action has not happened under Demo phase.

So, in order to use your method, one would have to use this workflow:

- Under Demo phase, demolished a portion of an existing wall to accommodate the future door.

- Under New phase, add the new door in said opening.

I think this workflow maybe a bit too impractical.  Am I correct?

[MKFreiert]

Aaron, 

i'm readily admit that i'm really frustrated with this thread,  no, phase management isn't perfect, however i've tried a lot of different ways to explain to a number of folks why what they're seeking would be bad practice and/or impossible from a data management standpoint, and every 6 months or so, it gets dragged up again, not by someone with a new idea, or asking for clarification as to how/why part of this doesn't work, but often simply complaining, and offering ideas that have previously been discussed, apparently having not read them. 

i start to loose patience when rather than asking for clarifications, folks just say no.  All the while demonstrating that they don't understand how particular interactions work, or what the impacts would be on others.  if the folks saying no, it can do this could explain how their proposed breaks to the entier structure of how revit groks place and time would work, i'll happily discuss that.  

there are a TON of features that need further development, and there are a TON of things we can all continue to learn about how the software behaves, and what it can, can't and practically should be used for in varying circumstances.  

[MKFreiert]

@ToanDN it depends on how the work is being accomplished.

if you want the new door opening to be cut in as part of demo, you add an opening during the demo phase that describes the RO for the new door. you then demo that opening in "new construction" and never show that. you've "constructed" a new opening, but you're putting something in that opening, so it needs to go away to be able to host the door. it's a hack, but in terms of what's actually happening to the wall, and database, it's accurate, if annoying, and lets you accurately locate your RO and will generate "new" infill around the door for that last inch or three.  if you need to gyp in a larger cmu opening, you just add a new wall there, in the retained opening.

i've also had situations where adding a new header will actually be accomplished in "new construction" so the demolition of the wall under it won't actually happen via the demolition contractor/phase. this is the sort of annoying nuance of producing clean/constructible CDs comes into some construction planning/coordination/thinking about how the folks in the field are going to be looking at it. (like adding dimension strings, and redundant check dims that are easier for someone laying them out with a tape/chalk to measure off of something critical vs off of a gridline for something that doesn't exist for 30' in any direction) we're producing instructions, we want them to be clear, as well as accurate.


it's an added step, but it allows for folks to display things a bit more clearly in certain complex situations. i've actually added the phase to a project for one particular enlarged area that it was easier to explain some particularly complex structural wall work overall i'm not a big fan of it, but it's a tool in the tool box that can be really useful when you need that left handed drill bit, or the client really wants to see something in their CD set in an odd (or horribly communicated) way.

recently, (last 3-4 years) i've not needed it as most of the remodel work i've been involved with has been TI work where the landlord is doing the demo and turning over some level of a shell/whitebox/horribly inaccurate revitg model and our "landlord work" phase describing demo and misc work (elevators, slab leveling, etc) happens as an interim phase between existing and our CD set. for demo happening after we take over the space, it's not necessary.

**edited for clarity**

[Anonymous]

I have a set of views for existing, another for demolition and another for new construction. I find it would be very simple for Revit to allow walls demolished in demolition phase to actually keep being room bounding. When one selects the demolished walls, the "room bounding" property is still checks but in reality it is not and one can't place room in this phase. If it were possible to place rooms in demolition phase, even if the walls are demolished in this phase, it would be possible to then tag them.

It sound very logical and easy to do for Revit...

[Anonymous]

This conversation got way too convoluted.  It doesn't make any sense why this is so hard.  Rooms can obviously detect their boundaries.  if a rooms boundary is demolished then the room should also be demolished not changed in size.  If I'm changing a rooms boundary then I want a new room number not an existing room number.   If I'm not demolishing any of the existing room boundaries then I want the existing room number from the existing phase to show in the new construction phase.  This shouldn't be any different from showing existing walls in new phases.  you could even make the existing room tag grayed out like walls and that would be great.  It makes no sense to me that rooms can't be given a demolished parameter and be automatically demolished when its boundary is demolished.  Even if the room has to be manually demolished I would still take that over not existing in future phases.  Its a real problem and shouldn't be that hard to fix.

[mastjaso]

Lol, you're right, the conversation didn't need to get that convoluted, but some people refuse to believe that Autodesk could've done anything wrong. 

And I can tell you right now, that if you look at the database for a Revit project, a "room" already has the "phase created" and "phase demolished parameters", it's just a matter of Autodesk tweaking the phasing / other room related code to properly support phases.

[Base12]

Per my observation on the progression of Revit over the past several years, I'd hazard a guess that Autodesk has pretty much just abandoned it.  The "Wish List" is miles long and has had outstanding, legitimate industry standard requests from over a decade ago.  There have been no real improvements for many years.

[mastjaso]

Autodesk is doing exactly what I would expect most business to do in this situation, they've managed to establish themselves as *the* BIM software, and have basically an entire industry dependent on them with no options to switch elsewhere, so they're collecting crazy amounts of money while doing the absolute bare minimum possible. 

This is what an uncompetitive market looks like. Autodesk has no incentive to improve, despite the fact that every $1 that Autodesk spends probably saves $100 for the construction industry as a whole.

[MKFreiert]

so you're proposing that at each phase, any room that didn't have any of its extents change, would remain, but if it had any extents change it would be flagged as demoed?   that goes against the requested behavior to keep the same room if you demo a wall to expand the room, or change a door or window.  what happens if i want to paint a room in multiple phases?

it's convoluted because there are a passel of variables that different people want to behave in different ways, most of which conflict with each other, and usually with most phased workflows in some manner or other.  people see their workflow, and don't look at how that will impact other workflows.

there are a lot of potential solutions to get revit to produce behavior that would benefit some folks sometimes, and add work load to all others, all to functionally add misleading information.   this all comes back to remembering that the revit "room" and what we think of as a room are very similar, but not actually the same concept.  the revit "room" is a way to talk about an assembly as a representation of an abstract idea, not of the actual abstract relationships.   

in looking at the last several years of projects i've worked on, from retail, residential, transportation, healthcare, etc, I can honestly say that out of the hundreds of projects and tens of thousands of rooms, none of them would have been helped by having rooms persist across phases, as even the large hospital remodels had enough rooms renumbered or reworked that copying over the few rooms that persisted was far less complex than trying to manage persistent rooms ever would have been.  every few years i do run into a "dammit i wish rooms persisted" moment, and then i remember this accursed zombie thread, and start to see the problems it would cause in my project.  

[Base12]

So in all your years, you've never created even one demolition plan in Revit?  

What good is a demolition plan without room names?  That's the original point of this whole conversation.

[mastjaso]

"there are a lot of potential solutions to get revit to produce behavior that would benefit some folks sometimes, and add work load to all others, all to functionally add misleading information."

First of all, no, it's not "misleading information" it's accurate information. Not having the ability for rooms to persist across phases is misleading because actual physical rooms *do* exist across phases and renovations. 

"this all comes back to remembering that the revit "room" and what we think of as a room are very similar, but not actually the same concept.  the revit "room" is a way to talk about an assembly as a representation of an abstract idea, not of the actual abstract relationships.  "

What are you trying to say here? "talk about an assembly as a representation of an abstract idea, not of the actual abstract relationships"? A room exists in the Revit database, as an element, bounded by a prism with the tops and bottom bounded by planes and the sides bounded by walls/certain categories of objects or room boundary lines. Look at the APIs, that's all there is to them.

As I've already pointed out numerous times, this isn't very complicated. Rooms have a "phase created" and "phase demolished" properties, all you need is to add the exact same functionality that everything else has, and let you set these. Then certain room properties (like volume or area), will just have multiple copies (area Phase 1, area Phase 2 etc.).

It's not complicated, and please stop pretending like it's behaving the way it should. As long as the real world has rooms that can exist across project phases, Revit should support that. This is not an insurmountable problem, and not one that inherently makes other workflows harder. Just one that will take Autodesk a little bit of time and attention to fix.  

[MKFreiert]

oodles of demo plans.  please refer to my earlier answers in the thread about the multiple ways i've dealt with rooms in them.