Revit Architecture Forum
Welcome to Autodesk’s Revit Architecture Forums. Share your knowledge, ask questions, and explore popular Revit Architecture topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

show existing rooms in "show previous and demo" phase

169 REPLIES 169
SOLVED
Reply
Message 1 of 170
ballen
37692 Views, 169 Replies

show existing rooms in "show previous and demo" phase

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.

169 REPLIES 169
Message 141 of 170
Base12
in reply to: ballen

The entire issue could be solved with a check box on the room item properties that is "subject to phases", or not.  If it's subject to phases (as Revit currently works) then nothing changes.  Uncheck that box, and poof, hallelujah the "existing" room remains present and visible/taggable, etc in all phases.  Done.

 

Trying to justify why this isn't important has no appeal to those who clearly find it important.

Message 142 of 170
Keith_Wilkinson
in reply to: ballen

Or just have 'phase created' and 'phase demolished' like any other element?



"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."
Maimonides
Message 143 of 170
croundy
in reply to: MKFreiert

Just to throw in my two cents hopefully without insulting anyone, I just want a static room that i can see in future phases. I don’t want my rooms to be dynamic and adjust to changes in future phases. Even if just the finishes change I want a new room that can be scheduled with new room finishes etc. however I still want to be able to see the existing rooms and room numbering around my new room from the previous phase, and I want to be able to apply a room tag to those previous phase rooms. I would like a demo phase parameter that will turn off previous phase rooms individually at a certain phase like all other model elements. That would make my day.
Message 144 of 170

And I really wish you wouldn't be so condescending like you're the epitome of knowledge on the topic, because someone in that position would approach a conversation differently: By not starting off saying that people have no understanding of what's being talked about when there's clear evidence in previous comments indicating otherwise. It indicates that, clearly, you couldn't be bothered with investigating what else I have said to ensure you weren't, in the worst case, putting words into your own mouth, and shows a complete lack of understanding of my particular background. I thought I'd at least fix the latter, but it sounds like you just want to be right. I hope I'm wrong on that much. And I cited my master's classes as teaching me things I already knew not because they taught me nothing and were worthless excuses of money pits labeled as "classes," but because I had experience in that particular area. That particular class in question was a requirement for the degree and assumed I had no previous working experience, which is fine and honestly the right move since I was an exception in that regard, but also does not detract from the core concept of that part of my argument: that CS/IT project management heavily gleaned from AEC project management because they are both, at their core, design fields. I'm beginning to question why I'm even responding if you're going to try to read between the lines only to find your own assumptions, but I feel this needs to be said regardless of how you try to spin my words further, so here it goes:

 

You're also SO close to understanding what I'm saying. If there are changes to a room, it's a new room (as far as Revit is concerned), but if there are no changes to a room, it is an existing room. Just like if you were to change a wall type, if information about the room changed, you as the user would make the decision to demo the existing room and create a new room in its place with the updated information. If there are no changes, you would leave it be and tag it as needed in your drawings. But Autodesk precludes you from that option; forcing you to have phase specific elements, forcing you to keep up with either additional rooms or additional views to properly show your drawings according to your firm's or client's CAD requirements.

 

And do you even hear yourself trying to wax poetic? Because I hear it loud and clear, however it sounded to you when you typed it. It doesn't matter what people think of as a room when you're assigning it's location in a CAD/BIM software; the software dictates how it is to be perceived. The developers already had that discussion and decided for you how it needs to be thought of in their software because they had to decide how it would be coded. In Bentley Microstation, for example, you can create a room based on it's boundary (you get to draw the outline), while with Revit it's a single click to place an element that, as per Revit's design, requires an origin point. Microstation thinks of the room as an enclosed space, Revit thinks of the room as a theoretical point whose bounds and space are calculated afterwards. Users must then adopt their software's philosophies so as to be better modelers. But both of these cases are irrelevant to the topic at hand, as they are equally feasible with phases.

 

And from a documentation standpoint, we do, in fact, have an Object ID. It just has a fancier, more relevant, if lesser known name: Room Number. Without this little identifier, we would not be able to relate the room information back to our plan drawings, unless you want to try and fit all the information from our room schedules within the confines of each room on a larger scaled plan. The difference is in the backend of the software, where info is still stored by Object ID rather than a user input value. But we also don't typically include existing rooms on our room schedules because they're existing. They only need show on our plans, and schedules only need show New Construction elements. Practicality has nothing to do it with it because rooms are, at their core, conceptual constructs created by humans as a means of assigning properties to their surrounding built environments while allowing easy means of identifying those property sets. It doesn't matter how it's placed in the design software or how the user conceptualizes it. Either the property values persist or they don't. End of story. When digitized into your design software, due to complexity issues, changed properties require a new room, but persisting properties have no such requirement. And in fact by designing your software to assume the first is always the case you limit the end user and create additional work where none was needed.

 

As I saw in your other post, you tried telling me to think about it in terms of an old vs new "favorite chef's knife." I get a new knife and it becomes my favorite chef's knife, yet I still refer to the new one by the old nomenclature of "my favorite chef's knife" even though the identity of the knife itself has changed. You are correct. But that isn't what I'm arguing. That's exactly how it should work. What I'm arguing is this: I got a new knife block because I needed extra spaces for new knives I have acquired, but I do not get a new chef's knife. My favorite chef's knife has not changed, just its container. It goes into the same slot of the same size next to the same knives that were in the old knife block, but there are new slots and new knives that previously weren't there. So why, in Revit, would I have to do the equivalent of acquiring a second, new copy of that same favorite chef's knife to represent my existing favorite chef's knife in my new knife block? Why can't I keep the old one when nothing relating to the existing knife has changed? And now I have to keep track of both old favorite chef's knife and new favorite chef's knife because that's just best practice? No thank you. There is no reason this is the case beyond lack of desire to make a change by Autodesk decision makers, and people not understanding the difference between real world, conceptual, and digital representations of rooms are not helping the matter get pushed forward. Not saying you're one of them, but there is definitely an issue with that even in this topic's conversations.

 

I can see where your misunderstanding stemmed from - my example of how the mechanics of phased rooms could work by bounding themselves to walls in each phase the room exists in via internal/backend reference table may have been misleading and I may even have presented it poorly. Since your argument seems to be hung up on your misunderstanding of my point, I hope this time I cleared it up for you. Bottom line: Existing rooms are existing, altered/new rooms are new rooms, but this does not excuse the fact that we need additional rooms or views as a workaround to display those existing rooms properly in our plans when we, the users, already makes decisions about which elements to demo and which ones to keep elsewhere. Give us the control, stop keeping it from us.

 

As for missing the forest for the trees, well, I'm sorry that they'd rather give us "shiny new tools" instead of fixing things that have long been a sore spot for the community. Do I like FormIt integration? Yes. Do I look forward to future development of that pipeline? Double yes. But to build on top of something that still has flaws by just ignoring them instead of trying to fix at least some shows a disconnect from and lack of interest in the community as a whole in favor of new customers and more income. If they're able to affording making a new software from the ground up and integrating it with other existing software, why can't they afford a smaller task of, say, fixing their Dark Mode? Is Dark Mode or Phased Rooms at the top of my priority list? Not necessarily, but with them and the mound of other fixes the community has been asking about for literally years gets pushed aside in favor of new tools in a grab for more customers, I'm surprised more people aren't insulted.

Message 145 of 170
paul.t.macknight
in reply to: croundy

That's essentially what I think needs to happen, too. But on the backend - with how Revit is designed with rooms being points that search for bounding elements - it would be easiest on the dev side to update the room elements to test their boundaries against room bounding elements in each phase the room exists in. For rooms we show as existing there should be no change, like you said, but it would still have to test if it were to be as automated a process as it is right now. This process would put it on the users to demo the room if something changed, but since we're already doing that with really every other model element, I don't see why people are so opposed to the idea. I wholly agree with you.

 

Then I go and suggest how it would work and people start jumping down my throat about how I don't understand rooms and how they work in Revit. And... I bite back. I apologize that it made the thread seem more hostile than it should be.

Message 146 of 170

Paul,

I'm certainly not the epitome of knowledge on the subject.  I'm just sick and tired of folks harping on something that they don't understand which has been explained over and over and over for 8 freaking years.  This is not a new problem, it is not an issue for the majority of users, and there is a known (really easy) workflow.  Over eight years ago, this issue was marked solved, twice.  Maybe it's not solved for you, but it is so far beyond beating a dead horse we're into beating the compost from the plants that grew from the compost of the second dead horse that ate the crops fertilized from the first horse's corpse .  Am I waxing poetic?  Yes, this thread is patently absurd. Every 6 months or so someone doesn't read the existing answers, and/or is certain that they know more than the folks who built Revit and drags it back up.  Revit has had several pretty major rebuilds since this thread was started, and added a TON of features. Is it perfect?  No, it's still got plenty of room to grow.

 

Your have communicated (possibly unintentionally) that you feel that you learned everything you needed to know about CS/IT in an internship, and that you understand more about how the software works than folks who've been working on it for years.   Maybe that wasn't your intent, but that was my takeaway.    I'm certainly not trying to be condescending, but I seem to have hit a sore spot and I apologize. 

 

Could half of the issue be solved with an added parameter that auto-clears if the bounding objects change?  maybe.  That requires some cross phase checking functionality that isn't' really present that I'm aware of. But that leaves the problem of non-bounding objects that change the function of the room.  That's manual changes which would supersede model accuracy, and obviously bad practice.  Could that be a much more complex check of "what is in the room?"  Yes, but that's almost certainly going to lead right back here with folks saying "why won't my room persist." --because they added a new chair-- It doesn't really fix anything, it introduces what would probably get flagged as a warning.  Do Revit Warnings need some revision, yes, but lets not add more.

 

Could a fraction of the issue be solved with an option to do something with a "show previous rooms" view filter option maybe- but that is a bigger structural change which may open up some other really nasty phase visibility options that could lead to really bad practices.  I think that one by itself *might* be viable-- I've talked about it maybe 5 years back with folks who were no longer on the dev team. But just like the pre2012 family template tricks, they pointed out that it's got the potential for funky exploits if you're not really thoughtful in how you implement it. 

 

 

Message 147 of 170
MKFreiert
in reply to: croundy

Ya, I like that too, but there's some potential for problems with adding more granular phasing control that can override things.    Personally, I don't see why we can't get a "show previous rooms" only override, but apparently it opens some ugly doors. 

Message 148 of 170
MKFreiert
in reply to: ballen

To be clear - Rooms are one of the single most complex objects in how Revit deals with3D.  They're why room bounding warnings  are some of the worst warnings for model performance, and even by themselves can lead to model instability. 

 

Intellectually, to us, they're simple.  They're a concept that we've understood since we were little kids.  In terms of computer processing though, they're a hot mess.   It -seems- really straightforward, but like trying to specify particular door hardware all the way down, it rapidly becomes an absolute zoo.

Message 149 of 170
Base12
in reply to: ballen

I'm not a programmer at all, so maybe this is irrelevant - and I don't need an epistle written on it either - but there's been a lot of talk about 'bounding issues' surrounding room placement, and existence in the model.  I know empirically that you can break the boundary of a room (and get the subsequent warnings, etc), but the room doesn't go away.  It just goes into a 'not placed' category.  Somehow Revit already knows what to do with problem rooms, as objects, not just philosophies.  Maybe "previous/existing" rooms get a new category, akin to "not placed", and maybe they even lose their volumetric properties, etc but the tags could persist in plan view, regardless.  Again, not a programmer, but on the scale of the entire platform it doesn't seem like one of the harder issues to solve.  Not to change the subject, but comparing this issue to the fundamental problem how poorly text performs [after 2016, or whenever they broke it] suggests that Autodesk doesn't necessarily seem invested in making Revit shine like it could.

Message 150 of 170
Keith_Wilkinson
in reply to: croundy

It's the adjusting to changes in later phases that's the challenge I think.  Any other element will stay the same or it's demolished and recreated.  So as a minimum you would need to be able to demolish a room.  It would also need to be able to look for different bounding elements in each phase it existed which I suspect would be tricky.



"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."
Maimonides
Message 151 of 170
MKFreiert
in reply to: Keith_Wilkinson

Exactly.

 

If anything bounding it (or included in it) changes, a room would have to get auto-demolished and a new room created.   That's introducing a whole new set of problems and potential confusion.  

Message 152 of 170
MKFreiert
in reply to: Base12

Unfortunately unbounded rooms cause issues too.  Like many problematic things, one or two isn't bad, but if you're autopopulating hundreds of them, bad things will probably happen.  

 

Message 153 of 170



There are also plenty of items that have been a growing concern for the community at large in those "8 freaking years" that Autodesk continually ignores or sidesteps in favor of producing new features that, while helpful, may not have even been needed. Do I like what's been added? Sure. But they they go and create a whole new software from scratch to implement with Revit when there was already some function for that within Revit and other parties were developing tools to do just that. Tell me, how expensive do you think that was compared to some of the fixes that the community has cried out for for years? I assure you it wasn't cheap. They develop tools for and make changes to things that already work, but the things that don't? "Oh look at this new feature we're implementing in the next build..." It's infuriating, no matter how much good development has happened. I don't care if the DOT puts in a new intersection with turn signals and better sensors/timing or a round about if all the roads around it are full of pot holes. That's a tad extreme, but the point stands. They say they want progress, but they're ignoring standing issues to do it, and that will ultimately make Revit crumble.

 


@MKFreiert wrote:

Your have communicated (possibly unintentionally) that you feel that you learned everything you needed to know about CS/IT in an internship, and that you understand more about how the software works than folks who've been working on it for years.   Maybe that wasn't your intent, but that was my takeaway.    I'm certainly not trying to be condescending, but I seem to have hit a sore spot and I apologize. 


There you go reading between the lines again. I clearly stated that I learned everything I needed to pass a single class from my internships (my exact words were "previous working experience," but sure, we'll go with your over simplification and assumption), and nowhere do I state or even indicate that I learned an entire degree's worth of knowledge from a single summer's worth of work. Were some of my statements unclear? Perhaps to some, as I know the way they should be read and you do not. But neither have I indicated some of what you accuse me of stating, and it is clear you are at least half to blame for that. You may be apologizing, but I think you're apologizing for the wrong thing and thus don't understand how you are actually at fault. My intent was clearly written. You should be apologizing for making broad assumptions because you only absorbed what you read where it suited your opinions of me.

 

By the way, what is condescending are comments like:

  • "I really wish you hadn't done that"
  • "You're so close to getting it. [You poor thing, let me tell you how you're wrong and why I know better]"
  • And, my favorite, "From a practical standpoint..." before proceeding to talk about largely philosophical issues about rooms that are better discussed over coffee or tea than in a thread where we're talking about the actual practical aspect of how it would be changed based on how people have already decided to code rooms to act. I mean, how humans think of rooms has no bearing over how we can include features to the already decided digital representation of those rooms.

 

I do see one problem with your view on rooms and room information, though (beyond you seeming to ignore my whole explanation of a room only persisting if literally nothing about the room changes): adding a chair or other non-spatial element to a room does not intrinsically change the room itself. If there is a property on a given element that relates back to the room to which it belongs, it is not tied directly to the room element itself. Rather, it is a property assigned to the element using an in house implementation similar to the Revit API method IsPointInRoom which, you guessed it, simply checks if a point is in a room. There is one possible issue I see arising, and that's with doors and how they interact with rooms. But even then, that's an issue cascading to doors that should also be solvable with properly design phase update, not an issue with rooms themselves.

 

There should be nothing about a room that is automatically input beyond the OOTB parameters Revit disallows from editing, like area. If there is automation, it's through, for lack of a better term, a third party tool to alter room information - like importing excel information to Revit. It's the designer's job to monitor, maintain, and manage that type of information, not the software's. Furniture has no place on a room schedule, and simply adding a chair does nothing to the properties of a room. And this is, of course, assuming that every project specifies the count of chairs and it is not the responsibility of the client to acquire furniture and that furniture is not simply a means of representing the functionality of the room (which I can guarantee you is not the case as my firm works for such clients). If you're changing the furniture of the room as a whole from a manager's office to a meeting room, then you are changing the functionality of the room. This functionality change would 1) require a new construction room to account for the appropriate changes, and 2) be the trigger for the furniture change, not the result. There is no argument that you can make that doesn't require the user to create a new room in place of an existing one, much like we do with walls and doors. That's just how the original developers of phases in Revit decided to think about phasing, and how we, while using Revit, must think about it.

 

And each phase of the room would have it's own boundary. Sure, I can see your concern about how the designer is made aware of a boundary change if there is no cross-phase checking on the room, but riddle me this: Why are we allowed to change walls even when they're set to be existing? It's not like Revit knows we're adding new construction to or changing the type of the wall, right? It's simple: the computer can't intrinsically understand what is happening. Drawing checks are a must because, to this day, there is no one perfect BIM suite that tells every designer of every little thing they personally need to know when making model changes. So what if a wall get's moved? Turns out, you don't move a wall, you demo it in one place and create a new wall in another place. That means you are aware of a change to surrounding rooms, and thus simply need to demo out any connecting rooms and create new ones to account for the change. If a wall is removed? Same as when the client decides to remove a wall between rooms in the current implementation of rooms in Revit: you get that oh so lovely Multiple Rooms warning/error, then same as with a "moved" wall - demo existing rooms and place new construction ones.

 

Your argument, from what I can tell, has largely become a philosophical "What if..." trying to concern itself with the potential fallout of the change, when in fact there are multiple everyday examples of how the workflow would, in fact, work. I'm not saying there wouldn't be an adjustment period, and I'm still not even claiming that this should be on the top of Autodesk's priority list. I'm simply advocating that this is extremely feasible, and that it should one day be implemented after the proper design tests by the dev team.

 

Your arguments overall may have a place in the larger context of BIM software as a whole, where there is no consensus on the best way to represent rooms (as is evidenced by the multiple methods for creating them in different software suites), but this is a forum for a specific software by a specific company whose dev teams have already taken care of the philosophical discussions and decided how it is to be represented within the context of the software in question. Even people who don't have an IT degree or programming experience understand how rooms in Revit are represented. Stop adding complexity to the issue where there is none, and focus on the complexity that exists (which in this case, I again argue, is very little).

Message 154 of 170

I think you might benefit from being a bit more succinct... just a thought... 



"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."
Maimonides
Message 155 of 170
paul.t.macknight
in reply to: Base12

No, you're exactly right. Revit isn't best in the performance category anyway, and while unbounding errors could become a significant issue for performance (but honestly, why are you making such wide sweeping changes without prepping rooms for those changes first?), Revit already handles related errors. The framework for this is already there, they would just need to build a reference table to store the cross check between rooms and bounding elements for each phase the room exists in. That's honestly not that difficult to do in a database. I would say it would be difficult to get rooms to display based on phase, but they're already doing that for other elements.

 

It's not necessarily at the top of my priority list, but the people saying it's too difficult to implement to be bothered with I think are focusing on the philosophical "what if's" and not focusing enough on the practical implementation in front of us (Revit), and are trying to quash it before we even try to push it to the dev team. Unless the dev team themselves (or I suppose the community managers in their stead) comes forward and explicitly say it's too difficult for x, y, and z, I'm not going to buy that it's not possible because I know how I would implement it (I have a programming background). And if the answer is "Revit isn't built for that," then why don't we have a more flexible software platform yet?

 

I'm not going to get started on the text considering it is off topic, but I wholly agree. Autodesk market's Revit as a flagship software, but they really don't seem to treat it like one in terms of fixing issues. I get some issues not making sense as to why it just stopped working, because coding can hard and occasionally it's literally just a misplaced comma that you can't find for hours, and the dev team is probably not allowed to deviate from their schedule. But there's only so much I can buy into that with all the issues that Revit has.

Message 156 of 170

Adding an exam table and cabinets to a small office that has had its desk and chair removed almost certainly changes that room.    Those are the sorts of object which may be associated with a room, and will be scheduled related to it, and may constitute the entirety of the change of "Rm 101 - On Duty Office" to "Rm 101 - Exam 10".    Those two are not the same room.  That change should have an automatic cleanup.   Yes, it is the designers job to monitor and track changes, but the entire point of BIM is to move closer to one source of truth that works to remove human error in data tracking.  What you are suggesting would introduce more possibility for human error, not reduce it.

 

"And each phase of the room would have it's own boundary. "    What you suggest is taking one of the one of the single most computationally heavy lifts in the software and making it  exponentially more complex.   You keep saying I'm adding complexity, but I'm not.  The complexity is already there.  It seems simple because it works quite robustly and hides all of the complications.  

 

We're allowed to change most things in most views because the programmers (right or wrong) trust us to be skilled professionals , and knowledgeable operators who understand what we're doing.   Most view objects have access to most things across all phases.  The view Phase filtering just turns off or overrides how things are rendered, but the view object itself encompasses the entire timeline of the model.  Why wouldn't we be able to edit existing objects, or future phase objects?  

 

Message 157 of 170


@paul.t.macknight wrote:

It's not necessarily at the top of my priority list, but the people saying it's too difficult to implement to be bothered with I think are focusing on the philosophical "what if's" and not focusing enough on the practical implementation in front of us (Revit), and are trying to quash it before we even try to push it to the dev team. 


No one is trying to quash the idea of fixing it.   I'd love to see some more advanced features with rooms and phase visualization.  But, I also understand why that's probably not going to happen.  I'm trying to point out that it is a lot more complicated than most people think.  If you're going to suggest changing something, it is far better to start from understanding the complications that have necessitated its current behavior.  

 

The idea has been in front of the dev team for years.  It's been voted in the top 50 things on the ideas list for at least 2 years, and I'm pretty sure that it was up there on the AUGI list for a number of years when they maintained the Revit wish list.  I think it even made the top 10 a few times.   There are very good reasons why it hasn't been "fixed".  

 

Message 158 of 170
Keith_Wilkinson
in reply to: MKFreiert

I think that's a fair summary.  Obviously, it would be nice to see Autodesk put more money into development to potentially deal with issues like this but currently, the Dev team needs to be realistic about how the resource they have is utilized - it's basic cost vs return.  I think the thing that is worth bearing in mind is that over recent releases there has been much more focus on those issues that have been an irritation to users for many years and that I think is good to see and I hope it continues.



"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."
Maimonides
Message 159 of 170
MKFreiert
in reply to: Keith_Wilkinson

There definitely were a few "drier" years for user facing updates, but they coincided with getting Forge really moving.  But, user's weren't seeing change.

 

I'm not sure how much folks realize that there's often a lot of back end rework that needs to be done to make more significant changes.  Autodesk has talked about that a little bit at AU keynotes, but unless you really dug into what they've been doing to (I hope) improve collaboration and data stability and accessibility, you'd think they haven't been pouring money into development for years, and realize that they've been building backend for the launch of ACC for years.  General users aren't seeing changes that directly impact them, so they think nothings happening.  Something like 1 out of 10,000 Autodesk users *might* have seen those talks, so it's no wonder there's frustration.

 

In recent developments from an Arch side, I'm most tickled about the last few years updates to structural tools.  I barely touch those, but they mean my structural collaborators are doing MUCH more in Revit than they were 5 years ago.  

Message 160 of 170
nemdaec10
in reply to: David_W_Koch

If any element that would change the parameters of a room (demo or new wall, new door, square-foot change, etc) were to change, the room information would become unstable so the room cannot extend beyond the static phase that it was placed in. If you think about it, every component in Revit is static, but with doors, walls, windows, or any other component, they are placed within a phase and remain unchanged until they are demolished. Any change between phases that would alter the static nature of a room (see above) would destabilize the room. 

 

In Revit 2022 (I'm not certain that this existed previously) A better workaround has been found with only a minor brain bender required on the user's part to allow the existing or previous phased rooms to show up in the demolition phase: 

 

  1. Create a view of the existing phase with the phase filter set to Previous & New.
  2. In Visibility/Graphics Overrides (In your view template if you will have multiple demo views such as plan, RCP, & multiple phases), go to the Filters tab. At the bottom, click on the box Edit/New to modify document filters.
  3. Create a new Rule-based Filter for each new construction phase of your project, calling it Demolition, or Demolition-Phase 1... (Make sure you have the new Filter set to Define rules).
  4. Check every category that you may have items to demolish. (Some categories can't be added because they aren't phase specific)
  5. Filter Rules: AND (All rules must be true), All Selected..., Phase Demolished, equals, Phase 1 (or whatever phase you are setting the filter for). Apply/OK.
  6. Back at the Filters tab, Add your Demolition filter. Set your overrides in Project/Surface & Cut to show all of your demo items correctly in the view.

Remember: You will want to create a view template set for each phase & view type needed. Each view will be set to the existing or previous phase, allowing the correct rooms to show. 

 

We have put this into our Project Templates and it is working quite well. 

 

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


Autodesk Design & Make Report