Bryant Quinney | Sr Applications Expert
About this document
This document takes to task the usability of a feature, one that was designed for cross-discipline consumption, and why it was discontinued, while exploring the possible reason for doing so. Autodesk has, since, very well expanded on a capability they previous had at a lesser extent by developing BIM 360. The following discussion also serves to put a spotlight on a feature many may not have even noticed. As well, some of those same people may yet be using the version of Autodesk software that did not include the depth of BIM that the current versions offer.
The terminology referenced here discerns the use of BIM from BIM 360. BIM is the foundational structure of information access about design objects, while BIM 360 is the product that Autodesk continues to develop, allowing this sort of access between their many applications. Not to be fully discussed here is the environment and depth of tools available to allow access to BIM data at various levels of project development.
Introduction
Between releases, it is typical of software developers to discontinue features, due to technology progressions or other reasons. The benefits and downsides of doing so do not get missed by Autodesk. Being a “hermit” of functional capabilities, the .ADSK file type had been discontinued from the Revit family with the 2019 version.
The ability to export this file type was in place up until the bigger push towards BIM 360 usage. The reasoning is understood to an extent, but the functionality assisted those who were (and are) not ready to make the full push into BIM 360.
Having left the export function in place, Autodesk could have leveraged (see “showcase”) the basic capability of cross-discipline modeling that is desired in many firms to this day. As it will be discussed further here, and from a Civil 3D standpoint, the use is notably limited when compared to BIM 360. With that said, the import functionality of an .ADSK file is still there. One may wonder what the end game could be.
Discussion
Thanks to my good colleague here at IMAGINiT, Marie Williams [Applications Expert – Building Solutions Division], I have an exported .ADSK file of a Revit model, found in the fundamentals class she delivers. It is of sufficient size and complexity to illustrate the level of information that can be consumed in a Civil 3D environment. As a modern-styled multi-level hotel, fully equipped with exterior doors and balconies, it gives a good basis towards the conceptual idea of project placement. This speaks to the context of a development project, namely when incorporated into a development software capable of handling such an object.
The ability to take the native Revit model into InfraWorks (IWX) is definitely there, allowing the visualization of the relation between the architectural component and the civil portion that also gets imported. With this capability, the InfraWorks software is situated in a place where the design components of civil engineering can meet architectural design intent without interfering with, or losing, data. However, this useful feature requires both the civil portion and the architectural portion to be used outside of the familiar design environment. If you are in the process of design, the simplicity of importing the most recent version of the architectural design component, while still in the vicinity of the design controls, can go a long way to prevent unnecessary repetition. This prevents having to export all of your design and then figure out how it works or interacts with the final design. The other side to this proverbial coin is that the capability involves importing, rather than using a live connection to the data. When the design changes, you would have to remove the previous iteration and repeat the process of importing the model into your design.
An ADSK File Discussion
With project development underway in Civil 3D, using an .ADSK file exported from those who are working on the Revit building model allows the design intent to be realized without leaving such a familiar environment. Many designers and engineers have not made much use of such a feature but have had a profound need for it. This could be due to the perceived (and often real) disconnect, or lack of communication, between the land development group, project manager, and the architectural group of whatever entity (or entities) given the charge of the project. The questions surrounding the possibility of cross-discipline data viewing or merging come up frequently, in classes and forums alike. Depending on the direction of data flow (between applications), or even the understanding of the software placement, answers come in forms like data conversion and export only after the degradation of the model in question. Therefore, it is no longer a “model” in function but a visual representation of what is intended.
This is where, like other technological features Autodesk has forged ahead with in their design software lineup, the .ADSK file shines. The actual model and a lot of associated data comes into the Civil 3D environment for reference. After importing a building model, via building site import, this is evident when you look at the model in the Prospector. It is imperative that this part of the discussion must disclose that you will only see the Building Site collection in the 2021 version of Civil 3D and no other version prior. If you recall on the previous page in this blog that the ability to export an .ADSK file from Revit was removed back in the 2019 version. Why the gap in functionality between the two leading software platforms that Autodesk has invested so much into? One software ceases to provide it while the other software makes more use of it.
In just one version prior, Civil 3D 2020, users could import and assign styles to building sites. However, the model data was not available in the Prospector in any capacity. So, why would Autodesk further increase, rather than limit or remove, functionality in a program that could best make use of one that was removed entirely from another? It seems that their closer involvement as an active member (and on the Strategic Advisory Council) of buildingSMART International, incorporating openBIM, could yield part of the answer in the IFC file format (Industry Foundation Classes).
Even though an IFC file seems to be a highly similar beast to an .ADSK file, inferences of unified development efforts may show that an IFC could, inevitably, have more to offer. Through strategic partnerships with other software providers, allowing design data to be portable and fully usable, IFC development could prevent Autodesk from standing in a silo filled with their proprietary file formats. As well, it is possible this all points to a plan that Autodesk may have in store for further development when it comes to consuming BIM data within the Civil 3D environment.
More information on IFC here:
https://www.buildingsmart.org/standards/bsi-standards/industry-foundation-classes/
BIM 360 Discussion
With the advent of, and subsequent push for BIM 360 adoption, Autodesk provided a method that allows team members of one discipline to access project data from members of another discipline. Most all of the legwork in facilitating the process and tying together of data being performed in the cloud. Since it has been suggested, wished for, and at times expected, accessing design data where it no longer goes through tedious workflow process iterations gets us moving more towards a fluid direction in design collaboration.
Where BIM 360 serves as the “handler” of design data between the software involved, each application must natively, as a destination application, enable the object to begin with. Add to that, the design information about the connected objects must be available in order to be useful, but not all of it is necessary. This sort of interaction is a natural progression in development but should come as a surprise that there is a slow movement to adopt this workflow. It can be presumed that users are awaiting more clarity, as well as features to be implemented and ironed out, before jumping aboard. Whatever the reason, the development has been moving along steadily, adding more ways for users to interact with the data shared by other applications.
The Capabilities of ADSK Files
With the ability to only import the model before, the capability where a user could access certain bits of data are now found in the Prospector in Civil 3D v2021. The various families used to develop the model are viewed by expanding the object listing. The top-level gives a summary and each family lists individual object data.
This is a considerable step forward in an effort to better consume BIM data inside of the Civil 3D environment. With some of this data, relying on the most mundane questions to be answered when the data is in front of the user is a game-changer.
Why remove the ability to export a Revit model to an .ADSK file for import into Civil 3D then? Based on the direction of development and the push for BIM 360 to be the main integral vessel for design collaboration, it seems pretty obvious. Importing a model is a one-time move until the model updates, then an execution of “Update Building Site Definition”. Though the process does not require repeating again with placement and stylization, it does require pointing again to a specific file. That is not a totally bad thing, actually. You can point to a different version of the same object through different file names. However, Autodesk may have realized they hit a snag somewhere with that limitation or others, based on their future direction. So, through BIM 360, the connection is made by associating to the project, maintained with updates pushed to the cloud, and only stylized within the workspace.
Conclusion
Though the capability of data access has been expanded to drill down into the BIM data of a model, imported as an .ADSK file, Autodesk has merely shifted the mechanism by which Civil 3D does so. Like many other technology steps and leaps they have made in the past, only time will tell if the move to force users towards BIM 360 is a wise move. It is possible that many companies, and users, will not graciously accept being forced away from a methodology of importing, and any workflows surrounding it, they may be more accustomed to and more open to using.
Comments