There must be something magical about 33% and Revit updates lately?
Friday, September 24, 2021
Thursday, June 17, 2021
A tale of mystery set in ancient times...a fairytale of majestic proportions...
Sadly it's more mundane than that. This morning I noticed a distinctly Reviteristic situation while answering a client's question. To get a void to cut a revolve, their orientation to one another seems to matter.
If I create a revolve in the Front view of a Generic Face Based template and then create the extrusion in a side (Right/Left) view the void won't cut if the extrusion extends too far toward the other side of the revolve (seem image).
It took two voids on either side of the Axis of the Revolve to get a full cut of the revolve form (see image).
However if I create the revolve in the Right side view AND create the void extrusion in the same view one void is enough (see image).
Perhaps this is old news to some but it's definitely subtley quirky (which defines a Reviteristic for me). Next time you're taking a journey with a revolve and void...remember this? I'll try.
This was done using Revit 2020.2.4 BTW
Friday, June 11, 2021
A recent message asked how they can enter values into the Project Base Point (PBP) like we used to be able to do when the PBP had a clipped/not clipped status.
The answer is Specify Coordinates at Point (SCaP).
They wanted to enter 8,000,000/8,000,000 as their example. R2021 won't accept that value but R2019 would.
In the past, when we selected the PBP, entered coordinate values, it actually shifted the Survey Coordinate System (SCS) away from the Origin/PBP. It was easy to assume we moved the PBP because it is easy to overlook the information that displays above the selected PBP. It says PBP but right underneath (see image) it says Shared Site: and the coordinates it displays are relative to the SCS.
Entering values in the PBP directly (in the past) is same as using SCaP (now). The Survey Point will move to mark the 0,0 origin of the SCS after we enter our values. The PBP will still be at the Internal Origin (IO). The following image is 2019 and 2021 showing the same end result, just using a different tool.
Entering values directly into the PBP now will move it away from the IO, something it did not do in the past. This invokes a Local Coordinate System (LCS) that uses the PBP as its origin. Spot Coordinate/Elevation annotation can reference this LCS. This why Revit won't let us move the PBP too far (10 miles) from the IO.
I think Autodesk should change the PBP reference to the Shared Site since it is confusing. I think the PBP should show reference coordinates back to the Internal Origin. There is probably some room for disagreement though, which is why it probably still references the SCS.
This change seems to annoy people the most because we can't just enter values into the PBP directly and get the "old" result. We can enter values but not to alter the SCS, which is what really happens with the clipped PBP of old. The unclipped status of old is when the LCS is invoked.
The PBP only moves in an unclipped state now, thus no clip.
Tuesday, June 01, 2021
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.
Wednesday, April 14, 2021
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.
Wednesday, April 07, 2021
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!
Friday, April 02, 2021
If you've found rogue RVT links in your model it might be Transfer Project Standards (TPS) and View Templates to blame. When you need a View Template from that other project you're working on you run the risk of adding RVT links to the project's database. You'll find them listed in the Manage Links dialog but if you try to reload them Revit will tell you there aren't any instances placed.
This happens when a View Template manages overrides to those linked RVT files in "that other" project. Just remember to check Manage Links after using TPS (reports, haha); otherwise this Gotcha will Getcha.
Hat tip to Alexis Kotzambasis for identifying this issue.
Friday, March 19, 2021
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?
Thursday, March 18, 2021
I read THIS post at RFO with interest naturally. The thread is about losing dimensions when linked files are updated. A subtle development in the thread is that radial dimension and linear dimensions are affected differently when a link is unloaded. Aaron Maller noticed that, mentioned it (in the thread) and asked someone at Autodesk about it. They looked into it and replied with:
Originally Posted by Autodesk Team
Here are the details. This is caused by the inconsistency between linear and radial dimension internal design.
For linear dimension, it handles “Unload a linked file" as a special case of dimension references not visible in the current view, while for radial dimension, it handles the unloading as invalid dimension reference, and thus it requires deletion of the radial dimension when unloading.
We will see how we might improve the radial dimension to follow a similar behavior pattern.
The emphasis was added by Aaron. Okay, good to know. For now, radial dimensions are at great peril if they are referencing a linked project. Best bet is to avoid dimensioning to linked elements anyway but especially so with radial dimensions.
Wednesday, March 17, 2021
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.
Monday, March 15, 2021
"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...
Sunday, March 14, 2021
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.
Saturday, March 13, 2021
Wednesday, January 27, 2021
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.