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.

[ToanDN]

That method is literately the first reply of this thread.

[SteveKStafford]

A template configured with existing/new construction work in mind can take much of the load off a project team. If the views required are already present, assigned to view templates and placed on preliminary sheets then all the user is required to do is model and document. They just need to transition from view purpose (existing scope) to view purpose (new scope) etc.

There is a reliable approach that requires very little upkeep once it is in place. It's based on real elements that belong in the model, not text elements that have no relationship to the model at all.

[Anonymous]

Yes but a link to an autodesk published workflow was not in the thread to the best of my knowledge. I posted the link to further the conversation that Autodesk acknowledges this "workaround" and is still probably the best choice of our poor options.

If I would have seen this link earlier, I myself would have stopped searching for a better way and just stuck to my solution.

[Anonymous]

Can someone please prove me wrong because I feel like I'm crazy...

Just set your phase to "Existing" with phase filter "Show Demo and New" and Demo the work in the existing phase... 

This solves the room problems in terms of showing the rooms in the "New Construction" Phase.

It also has no downsides in terms of the previously mentioned "Door Problem"

Frankly, I see it as an oversite by Revit to force everyone to show the plans at "New Construction" 

The demo phase isn't New Construction, in my opinion, it is demolition. 

This also solves the same problems with projects with multiple construction phases...

Please, someone, prove me wrong. 

[SteveKStafford]

Have you tried it with room's present? When an element's Phase Created is Existing and it's Phase Demolished is also Existing that defines it as a Temporary element, not Demolished. Rooms don't have those parameters because they exist in a single phase, unlike walls and doors for example. When you demolish the existing walls that provide boundaries to existing rooms, in the same phase, they lose their boundaries and generate warnings...losing room area data. 

Revit's designers didn't/don't consider demolition as a singular phase or scope of work. It's a wider view than regarding phases as equal to tasks or activities like project planning scheduling software does. Demolition is an activity that can happen alongside other new work and often does. Put another way, "We have a building (existing) and we're going to change it (new)." A lot happens after the client conversation, first mouse click and/or pen/pencil sketch begins the design process.

[ToanDN]

You are not wrong. I personally use that method a few times. It makes use of the Temporary under phase filters.

The thing is if you have a door in the new construction phase cutting an existing wall then you won't see the part of the wall demolished when the view phase is existing due to the demolition activity has not happened in that phase.

[Anonymous]

Use a room separator?

[Anonymous]

Thank you for giving me the only justifiable reason this is a bad idea. 

From an MEP consultant standpoint, this isn't really an issue. Just set the linked model in a view template to the new phase and the phase filter to Demo and New. 

Our model will be set to the method I described and we add spaces to the model for the existing phase and the new phase. Giving us the best of both worlds. 

But what do I know? I'm just a newbie. 

[SteveKStafford]

Phasing Linked file relationships depend on phase structure and filters being matched precisely. If they don't then you'll find phase graphic overrides don't work properly. For example, if one of their phase filters reads Show Previous and New but yours reads Show Existing and New graphic overrides won't behave. If they have four phases and you have two then mapping won't be able to address two of their four phases.

Each project will present you different situations. Trying to abide by how the software is intended to work is generally a safer strategy.

[Anonymous]

This problem has been on the books since 2013 and has not been addressed in a satisfactory manner. please tell the developers to prioritize this. The workaround solution, which has become the industry standard, should be an embarrassment to Autodesk.

How do we elevate this issue to Autodesk so that it can actually be addressed?

[mastjaso]

Hey guys, Revit may not support basic concepts like a room existing across multiple phases of a project, but don't worry, Autodesk has a whole slew of new generative design tools available for you to spend more credits on! 

Honestly this lack of functionality was f**king preposterous back in 2016 was when I first commented in this thread, and the fact that's it's now 4 years later and there has still been ZERO word from anyone at Autodesk about this is quite frankly unforgiveable.  

[Anonymous]

Couldn't have said it better.
-OG poster

[nemdaec10]

I can't believe this issue still exists after all these years...

Why not have a view filter that shows the rooms from the existing or previous phase when looking at the Demo views. Autodesk wouldn't have to mess with the concept of Rooms being single-phase and those who actually have to use the software in real life could label the rooms being demolished without extensive workarounds. 

[Keith_Wilkinson]

Here's an option we're trialing here.  Create a new shared project room parameter for the room existing name (and existing number if necessary).  If you are well organized and have your accommodation managed using an excel spreadsheet this data can be easily added to the model via Dynamo.  Then you can tag either the existing room name or the new room name in your plans and sections.  Personally, I'm not a fan of overlaying views, it works but it's a bit messy and needs management.

One issue with this approach however is if you are merging multiple rooms into 1 although depending on numbers you *could* add in a number of parameters... food for thought maybe. 

[alex_gallegos_wsp]

My interpretation of Room Tags not visible in a Demolition View (Phase=New, Phase Filter=Previous+Demolition) is similar to what happens to Ducts & Pipes when they've been Demolished in any phase.  Ducts & Pipes lose their System & become 'Undefined'.  Walls on the other hand lose their Room Bounding function.

Autodesk needs to fix this.

[paul.t.macknight]

There's definitely a way rooms could be phased, but the issue is that Revit's likely too rigidly coded in the backend (at least for rooms). Since Autodesk didn't originally create Revit and they historically have shown no interest in rebuilding it from the ground up to address some glaring design flaws within the software, we will likely not get phased rooms despite the technical feasibility and practicality that system would offer. And with Revit the way it current is, as much as I want phased rooms, I would have to say no thank you because to make it work would likely require too much calculation on Revit's part and just further slow down the already outdated software. Just another issue grandfathered in thanks to Autodesk's unwillingness to give proper funding to dev teams and guidance for prioritizing new vs revamped features.

As for the how, I think there's a little bit of a limit on creative thinking happening from metisdesigns, as it would not require a rework on the room boundaries to make them extend beyond their constructed and demolished phases, but rather the room elements themselves and how they're calculated. Simply have each room calculate which boundaries contain it for each phase the room is in (excluding it's demolished phase). If the room is in 3 phases (Existing, Demo Phase 1, Demo Phase 2, with the last as it's demolished phase), it has 2 calculations to the boundaries that are in those phases. Resource demanding though it may be, these boundaries would then be stored into a database that each view accesses to determine how to display the room based on the phase of the view. This data would also have pointers to the room bounding elements it extends to and listeners on both those elements and the room in the case of a bounding element being placed within the room, and only update the rooms as needed rather than recalculating the model on every single element change. The biggest issue that would cause the model the most fuss would be if a single ceiling/roof/floor element with volumetric calculations turned on, as it would interact with and alter multiple rooms simultaneously. You would also, possibly, still have the issue of how to display previous/next phase rooms, and would likely just need to disable phase filtering for rooms as a result, but I think that could be worked out if the rooms are simple not displayed at all in their demolished phase. But the reason this is likely not feasible in Revit at the moment is that rooms seem to be a hybrid element; they act like they are view dependent, like annotations, but also volumetric and interact with model elements. But even this thought isn't the whole truth and we see how phases could be implemented with the ability to turn on room volume calculations that then limit the vertical extents of the room to floors and roofs/ceilings.

Another misconception I think is happening is that, as rooms are very data-dependent, they cannot persist when there are major changes to the room. Unlike with walls, where model elements can be added or removed in different phases, element parameters are immutable. Just like if a you were to change a wall type from GB+||+GB to GB+||, you wouldn't change the wall type in a phase, you would demo the original wall and place a new wall with the demolished phase of one and created phase of the other set to the same phase, essentially "hacking" the demo graphics to show the demolished gyp layer. To change room data (number, name, wall finish, project parameters, etc.) is to fundamentally change the room; these rooms would have to be demo'd with new rooms placed with the new data. My above suggestion for how rooms could be phased have no bearing on this matter because they are mutually exclusive subjects, and this is how Revit and element parameters will work regardless of whether rooms are phased or not.

[paul.t.macknight]

Definitely forgot to read further into pages because I thought I was on the last page (not sure why), so I'm not sure how applicable the last paragraph is to the conversation at this point. Apologies if some of my comment is in reference to outdated information in this thread.

[paul.t.macknight]

I'm personally less a fan of this than overlaying views. Both methods require management, to be sure, but as you stated what happens when you have multiple rooms merging into one? Personally, this would just be a new room with no reference to existing room information unless it kept a previous number/name. Plus, your method is predicated on the idea that someone knows how to use dynamo or can find a company approved plugin (easier in some companies than others that are highly protective of sensitive client data) that extends into the COM libraries of Excel to automate the export/import process. And it's never a good idea to do this process without utilizing element IDs because that's the only way to guarantee you're not accidentally writing to the wrong room no matter how organized you are, and you can't expect people the innately know this because their confidence in their organizational skills will make them think room numbers are good enough, so you have to have someone on the team (like me) who can work on these automation tools and make it easily usable for the rest of the team but also have the ability to do other project/practice tasks because that is likely not a full-time position on its own.

Sure, it'd be nice if everyone could use automation software proficiently, but the reality of the matter is even people my age (I'm less than 5 years out of grad school) have varying levels of understanding and interest in using this type of software, despite the industry slowly moving that direction. They view learning it in addition to everything else needed for the field as distracting and, if they decide they need it, think they'll be able to learn it just fine later (despite learning new things becoming increasingly difficult with age). So overlaying views is my preference because it's easier for others I work with or who come after me on the project to understand. It's all about future proofing.

[Keith_Wilkinson]

Fair to say, whatever you do it's going to be a workaround. the choices are there based on what you have access to. You can choose the one that best fits your situation.  Maybe we'll see some improvement with this in years to come but it wouldn't be top of my list of things for development.

[paul.t.macknight]

Maybe, but with how Autodesk seems to be acting, I'm not holding my breath. I think it should be higher on their priority list than it and other existing issues seems to be, rather than giving us shiny new tools. I won't go so far as to call it s*** shining, because there are legitimately good things about Revit, but to clad a flawed foundation of a software with shiny new tools to attract executives that don't even use the software that then people like us have to use because the company bought in to it, only to not address those flaws in a meaningful way is causing a disconnect that will eventually backfire on Autodesk as the discontent users eventually advance into those decision making rolls.