Short Curved Walls and Non Core Layers

At Autodesk Revit forums I saw a post regarding disappearing curved walls. These walls were shorter than the current view range cut plane. When the Wall subcategory Non Core Layers is turned off only these curved short walls disappeared. Other walls of the same type that were straight remained visible. It looks like a bug to me.

In my testing, when the sub-category for Non Core Layers (Detail Level must be Medium or Fine) is turned off the wall will disappear when it's height is not at least 2 feet above the cut plane setting. For example, I can make a wall disappear if it's height is less than 6 feet when the cut plane (view range) is 4 feet. Enter anything 6 feet or higher and the wall reappears. This image is some full height walls and some walls that are 4 feet tall (lighter gray walls).

This is the setting I turned off in Visibility/Graphics.

This is the result, the curved 4 foot tall walls are gone.

I suppose, in their defense, they could argue that the reason it is possible to turn off non core layers is to be able to isolate, only show, the structural portion of walls. As such a curved wall that is not tall enough to reach the cut plane is not likely to also be a structural/bearing wall. At the very least it is unexpected to have a wall disappear only because it is too short and curved.

Cue Randy Newman, "Short walls got no reason..."

Revit 2025 Some Keyboard Shortcuts Missing

Revit 2025 has been released and I installed it this morning. I replied to a question at Autodesk Revit's user forum regarding a missing keyboard shortcut to apply halftone to a selected element. I ordinarily would not consider overriding a single element to get a halftone appearance so the question caught my eye as unusual...at least for me. I assumed the missing command was for the right click options to override elements in view.

I find that Revit 2024 (and 2023,22 & 20) have multiple keyboard shortcuts for overrides (see image comparing 2025 with 2024).

One difference between my installation of 2025 and the other versions is that pyRevit is not installed for 2025. I disabled pyRevit for 2024 and the shortcuts are still there. No "path" is displayed for them either, which is "weird".

Is it an oversight or did they change something under the hood that prevents allowing for hotkey access to the command? Perhaps they could see that the shortcut was rarely used so it was decided to abandon it?

Regardless, there is at least one Revit user in the Autodesk Forum's that misses it and noticed right away!

Edit 04/05/2024 - Trey at Autodesk replied that they'll work to get them back in as soon as they can.

Can't Delete Toposolid Points and Guardian

 A quick follow up post on my prior post about deleting toposolid points. Scott Brown isolated the issue his team was having to their use of a 3rd Party tool called Guardian. When they disabled it they could delete points as expected again. If your firm uses Guardian too then check in with them about an update to see if it has been resolved yet.

Ghost Tooltips Be Gone

This seems to be a recent phenomenon. I noticed it first in Navisworks and then occasionally in Revit or AutoCAD. What is that you ask? Well it's hard to describe. When I use a command and then move my cursor away from it to do something else a tooltip appears for that previous command. In some cases I didn't use the command, merely my cursor was hovering over it before doing something else. It's weird.

I've tried disabling tooltips entirely but there doesn't appear to be a way to do that in Navisworks, or if it is possible I've not stumbled on to it yet. Similar for Revit and AutoCAD.

A practical very recent example, I used Refresh and after it completed I moved my cursor to the far right side of the screen to activate the Properties panel and the tool tip for Refresh appeared. The only way the tip will disappear is to move my cursor back over the tool. However in the fifteen or so minutes since that happened no tips have appeared no matter what I do. It is so weird and annoying.

Strange stuff, maybe it's just my PC...

Delete Toposolid Points

Seems like a simple thing but only the Delete key on the keyboard will delete a point in the toposolid, at least while using Revit 2024.1. No, the Backspace key doesn't "delete" either.

2024.1 Schema Warning

Glynnis with IDEATE posted information at the Autodesk User Forums that you should be aware of if you're using 3rd party tools and are going to deploy, or have deployed, Revit 2024.1. Ironic that this update is the one that has caused a potential disruptive issue since many firms wait for this point release to deploy. I've taken her initial post and copied it here, go read the entire thread for any more recent commentary. Thanks Glynnis!

There's been a lot of chatter about the Schema error that was landing in a post about What's New in 2024.1 so I took the good suggestion from @RobDraw to start a new thread here.

What is a Schema?

I welcome other people's input on this, but from my perspective, a schema can be best thought of as a blob of Revit metadata, held in Extensible Storage workset, that has a unique GUID. This blob of data is most often used by 3rd party developers but is also used by Autodesk (or companies acquired by Autodesk). The structure of that data, per each GUID, needs to be the same. If a developer alters the data structure, then a new GUID is needed to avoid the error.

What causes a Schema error?

In order to experience a Schema error, you need to have two files (or a file with a linked file) that have the same schema GUID but with a different data structure. Whichever file is opened first 'wins' within the active Revit session. This makes solving these problems REALLY hard because the file that displays the error is not necessarily the file with the 'problem' schema. It's also why this problem seems to be squashed sometimes and then resurface later. If you only ever open one Revit file at a time within a session of Revit, you'll never see the error.

What's the New Problem

The new problem seems to relate to Revit files that are upgraded to 2024/2024.1. The 11 July Revit 2024.1 release notes show that in there were changes made to the API to try and fix an outstanding schema condition. It feels like that change may have created some new conditions. We have an open case with Autodesk on this issue.

This is the latest schema article on this at Autodesk

Autodesk Revit schema issue article

Slanted Walls Don't Miter

What if I'm asked to create a vertical bottom wall that will transition into a slanted upper wall? Initially the wall configuration looks like the walls on the left in the following image. I added another vertical wall at the top of the slanted portion just for fun.

Each wall doesn't know anything about the other so there is no attempt by Revit to miter them together. We might have expected them to join? If we consider what happens in plan views for a similar layout (see image) I don't think it's unreasonable to think that might have happened. If an automatic join occurs in plan views maybe using Join will work in a section? No. Wall Join tool? No. Attach? YES!

To resolve the clumsy look of the left walls and end up with those on the right side of the image we can take advantage of the Attach tool. We just need to add reference planes to define where the miter joint should occur. Then Attach - Top will fix the bottom wall and Attach - Base will fix the upper wall. Repeat as required until all walls relate to each other better.

Phasing and Replacement Windows

Over the years people have often complained about trying to document replacing existing windows with modern windows but maintaining the existing opening. This means swapping windows with families that are the exact same size. This is related to the wall that Revit creates to infill a wall that has a demolished window. You may have encountered this warning message?

That message appeared when I attempted to place new windows in the New Construction phase after demolishing the existing windows first. I was careful to set up views assigned to different phases and phase filters so there wouldn't be any display conflicts.

I got interested in this issue again recently because of a thread at the Autodesk User Forums for Revit Architecture. A fellow member was sharing how much trouble Revit has been giving them trying to do this kind of work. After some back and forth I narrowed it down to one window family and another member realized that family uses a void to cut the hosting wall in the family itself versus the usual opening.

This led me to write some hypotheses for testing purposes. I wrote:

Hypothesis A: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use an OPENING in the family to cut the host.

Hypothesis B: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use a VOID in the family to cut the host.

If either of the above are false then...

Hypothesis C: Within phasing we CANNOT replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF one uses an OPENING and the other uses a VOID, in the family, to cut the host.

I did some testing using the latest release of Revit, 2024.1 and I determined the following:

Hypothesis A is TRUE

Hypothesis B is FALSE

Hypothesis C is neither

I find that I can replace a Void based window with an Opening based window but not the reverse. Also any alterations to the hosting wall in the project; such as length adjustment, or top/bottom offsets, attach/detach will place the void type window at risk of being deleted. Weirder still is that it might not delete all of them, one or more.

It seems that the short answer is: eliminate window families that use a void to cut the hosting wall IF you intend to place identical sized windows in phased projects; to demonstrate existing window replacement without altering the existing openings. Windows created this way will not work for this task. A logical next hypothesis is to anticipate similar behavior in door families.

I speculate that this warning happens because an opening cuts fully through the host while a void (or combination of voids) might cut more and/or less of the host as it travels through it. I suspect that the infill wall can't abide the shape a void might create and that in turn means a void won't be viable as a window to alter the location of the infill wall. I think it's similar to curtain walls only supporting non-rectilinear panels with the system panel families.

I'd love to hear that the developers will test this against their own experience and expectations. I know that a lot of people rely on voids to shape the opening in a host wall to match a variety of actual construction techniques for openings. To eliminate voids in families as an option for this kind of project (replacement windows (and doors?)) is not ideal. They'd probably have to revisit the entire logic of infill elements where demolished hosted elements occur. Perhaps leave it up to us to fill in holes?

Revit 2024 - Template Views Crop Boundary Controlled by Scope Box

 There are new multi-discipline templates for Revit 2024 (imperial and metric).

In the new multi-discipline template the views that are placed on sheets are controlled by a Scope Box. When you look at the properties you'll notice that Crop View is disabled (gray).

We can turn off the visibility of the crop boundary but we have to disable the association with a scope box if we want to change the crop independently. Of course if we like and want to take advantage of the scope box being defined and used for the views, we need to open a view that isn't constrained by the scope box so we can adjust the Scope Box extents (it's called Views Overall)

Rumor Goin Round

I'm crawling out from under my rock later this week. I'm joining Jeffery Pinheiro's (aka The Revit Kid) BIM After Dark livestream on Thursday evening. He plays guitar and I play drums, we might get around to talking about Revity things too.

Local Save Does Not Work - Follow Up

 After speaking with an Autodesk developer we now know that our issue is related to past eTransmit use. Revit mistakenly retained a flag it uses to mark that file as such.

If we can successfully use Synchronize with Central and we get that message when we use Save then the correct response to the warning dialog is the top option: "Save this model as a central model in its current location - Revit will remove this message and allow users to create local copies of the model."

Remember, the message is accurate for files that have been created via eTransmit too. In our situation the files were working fine on BIM 360 but they retained the flag that should have been removed when they were added to the cloud.

Info Added 6/4/2021: The warning is triggered ONLY in the following scenario:

The warning is triggered ONLY in the following scenario: The model has been transmitted and then upload to BIM 360 from Revit using the option “Work temporarily”.

To eliminate this warning for future project, please make sure you choose “Save as a central model in its new location” when uploading the models to BIM 360 from Revit.

BIM 360 Warning Using Save not Sync

Lately we see this warning message appear, in BIM 360 hosted projects, when clicking the Save button (local) instead of the Synchronize with Central button.

It isn't happening for all models or all projects. I haven't isolated a cause yet and it shouldn't be happening at all. This is true for projects running in Revit 2020.2.3. Anyone else see this?

Overriding DWG Layers Didn't Work

A team was trying to override the appearance of the DWG layers after linking the file to their Revit project. Usually the reason for this not working is elements are not assigned to color or line pattern BYLAYER in the DWG.

In this case it wasn't working because the DWG was not within View Range's Primary Range, it was in the View Depth zone. Projection and Cut linestyles work inside the Primary Range and the <Beyond> linestyle is used for elements within View Depth.

Good catch Mia!

BIM 360 Linked Revit Models use Local Cache Path

We've been running into this situation lately. Linked Revit models start using an individuals collaboration cache location for the path instead of the project's BIM 360 location.

At first it seemed that we could resolve it easily by applying the update for Revit 2020. Most of the active projects I deal with are still based on Revit 2020.

It appears that a fair number of firms are deploying "even" years and skipping the "odd" years. The larger the scope of deployment seems to have some influence over that choice. I've been working with 2021 in smaller situations though, wishing it were true everywhere...I digress.

Autodesk acknowledges the issue and has this ARTICLE to contend with it.

Wishing it were that simple, we are still running into it. Naturally there is another ARTICLE that mentions they are still researching the issue but that using Force Relinquish (BIM 360 Manage Cloud Models option) can cause this situation too. This requires us to clear the collaboration cache for a user who has forced us (haha) to use Force Relinquish. We are still in the diagnosis phase ourselves so we're not convinced of anything yet.

The article also tells us that using Force Relinquish should be a last resort and not recommended for routine use. Autodesk article says, 

"This is happening because somebody has used Manage Cloud Models to force relinquish that user from that link, which breaks the link in the host model for the affected user."

"Note: Force Relinquish is a destructive operation and should be used sparingly! It is intended to be used as a last resort when the user to be relinquished is unavailable for some reason."

"If someone has been forced out through Force Relinquish, then all the changes that they have not synced, become orphaned and lost. While the central model will be unaffected by the use, people can lose work (and have to close and reopen the model which will be slow)."

"It is better for the user to open the model and use Relinquish All Mine to relinquish their permissions rather than using the Manage Cloud Models dialog."

Okay, that's fair. However the new named user subscription based model "forces" this option on us (not haha) at large because we can't pretend to be another user anymore. As soon as we log off to become that user we lose our Revit session too. Catch 22

It would be nice if employees didn't quit and go elsewhere or earn a dismissal. It would be nice if 3rd party applications didn't need to borrow a workset on our behalf and then refuse to return a workset without our knowledge. It would be nice is 3rd party applications that do automation didn't require their own username to run quietly in the background and then fail to return a workset from time to time.

That world is where we can find pink unicorns with diamond encrusted saddles, at least I think that's where they are, I could be wrong?

Right now clearing a workset conflict in Revit Server projects is not nice. BIM 360 at least has Force Relinquish...but now we're told you really shouldn't use it because it might wreck your linked model paths. It starts the kind of internal conversations that make EyeTee license management "heads spin". Nobody wants users to start sharing log in credentials do they?

Additional Collaboration Cache Article

Topography Links and Using Tag by Category Makes Revit Angry

This one is subtle, like so many Reviteristics.

A team is testing the Revit to Civil 3D relationship via BIM 360 and Autodesk Desktop Connector. I don't think there are enough moving parts for this equation but I digress. A user reported that Tag by Category (TbC) causes Revit to crash.

We narrowed it down to linked Topography. If any exists then TbC gets dicey. Here's what we know so far:

• Topography link Not Loaded status > Topography category visible in active view > TbC crash
• Topography link Loaded status > Topography category NOT visible in active view > TbC NO crash
• Topography link Loaded status > Topography category visible in active view > TbC NO crash

The team's project has two different linked topography sources so there are two of them in the Manage Links dialog. I haven't tried with just one present yet.

I'd be curious to see if anyone else can corroborate our situation. I've submitted crash reports (several/many) as I worked on this so perhaps Autodesk will find some lurking evil to contend with in the meantime.

Happy troubleshooting...

Exploding DWG Files

 "Just don't explode DWG files" is good advice, that is immediately ignored because...reasons...

Setting that aside, now that we've exploded that DWG, now what. First, there is full explode versus partial explode. A full explode will recreate all the DWG elements into native Revit elements (assuming it is possible) but a partial explode will produce some native elements and some new DWG elements (blocks).

Reducing all DWG elements to equivalent elements in Revit is fraught with peril. Not all blocks in a DWG are created well. Explode one block that happens to have very large extents and your project will now have display/graphics issues. A Revit project might have one imported DWG but many times that number after partial exploding.

I recently encountered three project files that had +95k imported DWG files. These were the result of partial exploding less than 20 DWG files. As most people are aware, Revit won't create an element if it is too short (less than 1/32" long). A scary number of these DWG files were invisible, undetectable by eye in any view, because I believe their contents were too short to display. Many thousands were in just a few views. I used IDEATE Explorer to select, open the view they were in, if they were invisible then delete them.

It was time consuming; for some of them it was fastest to just delete the drafting view entirely because the view/detail wasn't going to be used on the project anyway. It was part of the everything and the kitchen sink approach in their template. Many of these details were derived from existing DWG based details created over many years to varying standards.

Back to Revit and exploded DWG elements...

Each line, arc, circle, etc. element is recreated and assigned to a new line style named for the layer it lived on in DWG. Similarly each text element is created using DWG info to define it as unique. Line and fill patterns are created this way as well. Ditto for dimension styles...and filled regions...

Once these exist in a project they are prone to being used by others because they are there. It is hard to ensure the standards a company has developed are used when this additional noise is present.

If we must explode a DWG let's not do so in our active project. Use an isolated file, based on our project standards (template). Once exploded, take the time to convert everything to our standard types. The completed drafting view can be added to our active project using Revit's Insert from File tool.

Also consider the time is takes to do this well...might be as long or longer than sketching over a detail DWG instead. If our detail item library is pretty good we'll be able to create a detail faster because we have components to represent the same kinds of things the DWG has in block form etc.

Don't sweep the DWG remnants under the rug...

Drafting Views have an Origin Too

Drafting views look like a blank sheet of paper we can drop your pen and start sketching in. We can but it might help to know that they do have an origin and you can end up quite from from the origin if we use an external file to sketch over (which happens a lot). I routinely encounter projects that have very large drafting views, when you know where the origin is.

The old trick to find the origin in Revit was to import/link a DWG with a crosshair at the world coordinate system origin. Linked via Origin to Origin places that DWG at the origin of the view. The PyRevit application has a handy function to place a pair of intersecting lines at the origin of a view. I find I just use that now instead. It's about the same number of "clicks" either way.

Now, the natural question to ask is, "Does it matter?" I don't know but if large extents are bad in model views I can reasonably infer that it might also be bad in drafting views. I don't have any evidence that this model was bad because drafting views were huge. I do know that some bad models I've encountered also had drafting views with very large extents. When I deal with a such a model it is one of the things I consider (of the many things, so many things).

Good housekeeping isn't just for the model.

Large Extents -Can't Navigate in a View and-or View Will Only Show Wireframe

I've written about Revit's fussiness regarding large extents numerous times over the years. In some of those posts I mentioned a related view issue. A view that refuses to show the model in anything other than wireframe is a symptom of the large extent issue.

I recently encountered a project that didn't have any DWG files to blame for it. Not only did the view not show according to graphic style settings it didn't allow navigation of any sort. The view was frozen. We could open or close it but nothing else. I noticed I could use a crossing selection window but then using Filter to focus my troubleshooting effort was still too coarse.

I've been meaning to mention how much I like IDEATE Explorer (IE). It has been very useful to examine projects and track down issues. It permits examining a model in ways that Revit can't. for example, I can select a category of elements or instances of each family/type within the category.

I use it routinely to check for excess DWG imports (resulting from exploded DWG content), workset assignment, reviewing warnings (more effectively than Revit's own), phase assignment/usage, content naming/usage and resolve line style usage (and more).

After using the crossing selection window in various parts of the view I realized some structural elements seemed quite far apart. Keep in mind the view was a white screen of nothing...imagining gazing toward Earth from Mars and trying to pick out where California is or my house. The Project Base Point and Survey Point didn't even show up in the view.

I started with trying to isolate where in this vast white space the structural element was but no matter what I tried I seemed to always select some structural framing.

Once I knew which category to hunt in I used IE to look at individual framing elements. I found a single framing (W Beam) was 2+ million feet long. I expected to find a family very far away, not one that was just very long. I realized that a Structural Framing schedule could have revealed this element too, if I knew which category and to look at Length. I did make a schedule just to see if I missed any other really long framing.

One Beam, one verrrrry looonnng beam killed any view it was visible in. 3D views are where we were confronted with the problem but other views whose extent permitted the beam's true extent to affect the view were also victimized. In the end we rolled the project back to just prior to the beam being added. 

The views didn't "recover" from the harm when the offending beam was deleted. I surmise other aspects of the model were altered by the extent of the beam, perhaps scope boxes, crop boundaries, a connected or joined element...not sure. That will remain a mystery.

May your troubleshooting be quick, effective and "trouble" free.

DWG XREF Follow Up

 A year ago I wrote about XREF DWG files showing up in Revit even when they are assigned to Overlay vs Attached. It hasn't been resolved, meaning Revit is still doing it, no change...

Shortly after writing the post we arrived at our "solution", to assign all Xrefs (in AutoCAD/Civil 3D) to a unique layer(s) and turn that layer(s) off in Revit (via View Templates usually). This way the extra layers of the xrefs do not show up even though Revit is technically ready and willing to show them.

Create or Opening a Section View Crashes Revit

Have you encountered this issue (and/or elevations)? By crash I mean Revit stops responding, the blue spinning wheel of death. One cause I've identified is HVAC Zones. I've been able to resolve each on so far by deleting the related zone(s) and creating the zone(s) again. I haven't figured out what is going wrong with the zones. I'm just calling it corruption for now but I have no idea if it is something I can prevent or see first yet.

Happy to hear if any readers have encountered this situation too.