Bridging Revit and Inventor Using Autodesk Data Exchange to Make Configurator

VIVEK MAHAJAN: Hi, everyone. Today we are going to have a plus on topic Bridging Revit and Inventor Using Autodesk Data Exchange to Make Configurators. I am Vivek Mahajan with my colleague Nem Kumar.

Before going ahead, let me introduce ourself first. We are coming from a company called Center for Computational Technologies, private limited based company. Our vision is transforming human life by democratization of technology.

Talking about me, I am Vivek Mahajan, currently working as an account head of Autodesk Platform Services at CCTech. I have contributed in developing scalable software applications for CFD, CAD, BIM, and oil and gas industries. I have the deep expertise in conceptualizing meaningful solutions to real-world problems in the engineering domain.

I have led a team that builds solutions using cloud computing, Autodesk Forge services, and machine learning. I consider myself as a technology evangelist and believe that new advancements in computing can help resolve problems in engineering domain more effectively. Now Nem, it will be good if you introduce yourself.

NEM KUMAR: Thanks, Vivek. This is Nem Kumar from CCTech. I head consulting division at the company. I've been associated with Forge for past-- since it starts, since its inception, and still we are part of Forge platform in different ways. Thank you. Thanks, Vivek.

VIVEK MAHAJAN: We will discuss the data exchange services and its Autodesk [INAUDIBLE] GPS and daily desk. We will demonstrate our applications around solar panel configurator to help viewers think about possibilities of how they can solve their business logic by making effective use of data exchange and its related Forge services.

To start, with we will see what is Revit it and what is Inventor. So let's see what is Revit. Basically, Revit is a building modeling software.

So we're talking about that being BIM is the foundation of digital transformation in the architecture, engineering, and construction industry. The role of BIM is to gather and link data related to design, construction, and operating of a building to produce a comprehensive 3D model.

Revit helps to create architectural design, structural engineering, MEP engineering, and construction. So this is the basic idea about the Revit. Let's move further towards the Inventor.

What is the Inventor? Inventor is a software, which helps us to do the parametric modeling, assembly modeling, product design, simulation, and do the analysis of the design and documentation. So these are the two subjects which we are going to discuss in further detail. Nem will guide us why we need both the softwares collaborating. So New, towards you.

NEM KUMAR: Thanks, Vivek. So why do we need Revit and Inventor together? Today, whenever we are making any model, usually you would have to interact with multiple CAD softwares or multiple softwares. This is an example where we're trying to make a home or a hospital, which would need either railings or plumbings to be coming from Inventor.

Currently, how this happens is, it happens through file exchanges. So whatever you're making in Inventor, like plumbing sets, or the chairs, or the railings, they would actually be exported into a step format. And this step format will actually be imported into Revit.

And when it comes to Revit, it's more like a blob object, with some properties lost. Geometry is there. Some things are there, but still, the properties which we require, they get missed.

So what are the challenges? I mean, this flow has a lot of challenges. Let's go through these challenges. The first one is, any today's challenging world we are making big models.

These models come from different softwares. You might be using Rhino for facade design. You might be using Oracle plan for some piping-related, or AutoCAD MVP for piping-related stuff. You would be using some of the third-party software for stair design or railing design.

Whenever these softwares-- they do not interact automatically. So you have to export information from these files, and these files need to be imported into Revit kind of software. When these files and information get imported into Revit, they are not accurate informations. Many informations get lost, because Revit is not able to understand the exact nature of the file, so that's why these transfers are very lossy in nature. They lose information.

Going towards the second one. Yeah, I mean, going to the next, second one. They are very, very important part of the information is whenever you're sharing your models, your models are very huge. And you want to only share a part of it.

For example, if I'm making a home, you want to just share the MEP model to the vendor. Or you want to share only the bed design in case of hospital to another vendor. Today, what happens is, you have to actually share either the whole file, which is pretty huge, which you do not want to share, because there are some IP rights you do not want to share from the company. The other side is that if you're-- the other way to share it is, you actually have to download that particular subset, save it into, as a view or save it into a STEP file, and then do it, which is kind of a not a good way to share information.

The third part is, while you're sharing information, you do workflow in which these kind of big models are constructed. They use multiple softwares. You might be doing something in Rhino, then you might be taking that information to a Dynamo or Grasshopper, and then you would be getting some information which you want in Revit. This all takes a lot of time, and downloading, uploading, importing, correcting, these translations are actually, as we saw, these are very lossy. And hence, the time and money is invested in collaborating with these softwares.

So how can we correct this? What is the new way to actually share information? Forge data exchange is the new way to share information. It is part of Forge data platform. It's a one service, where you actually can share a subset of information, a subset of data across your design, and then make application which can actually scale.

So how does it work? Let's see this example. On the left-hand side, you have multiple apps, which are, for now, coming from AutoCAD, from Autodesk, AutoCAD, Revit, Inventor. These actually are saved to a third-party software, again, by Autodesk which is cloud-based, cloud information model. And then from this cloud information model, information is actually then only subset of that information would actually travel to either Rhino, or Power Automate, or some third-party softwares.

Now the beauty here is that a subset of information, which is needed, is shared with Rhino, because we know Rhino is more better in services, So only that particular information is shared with Rhino software. We want to do some costing-related analysis. So only we need some properties to be extracted from Revit, or CAD, or Inventor and travel to Power Automate, where we can do cost-based analysis. Now in Power Automate, we do not want the whole Revit information through files to be coming in, because today, it's actually not possible. So it is breaking the silos which is there in the softwares while we are trying to transfer data from one software to another software.

So a very important part of this is data exchanges. What is exchange? What is data exchange? Data exchange is a subset of information. It would come, in general, if I take an example of a Revit-- so Revit has business logic, it has data, and a lot of other things. We are trying to extract information which is relevant, which is only data and not the business logic. So this subset of information can travel from any of the software from Revit, for example, to Inventor or any third-party.

So what benefit it gives us? It would actually give us bi-directional integrations to the softwares, whether it's desktop, web, or mobile, consistent user management and auditability, because you can control what is actually seen or what is shared with the people, with the vendors.

And the third very important part, whatever is shared is actually very granular. It's not file-based transfer actually. It's a granular information, which is a small file, so you can see to which it gets transferred.

I'll talk a bit about the terminologies. I would prefer the documentation, which has been in private or public, in the public on the Forge platform. We have not taken the whole terms actually. I've taken a subset of it. The important subset.

For example, the collection. The collection is what? It's a group of data, which actually represents probably information which you want to share to the vendor. For example, a room in which multiple beds are there from a hospital.

Space is also similar if you're sharing multiple rooms. Then one room would be part of that space. Inside that space, there would be assets, like bed is an asset. You would like to share only the bed with the vendor. Now this bed would have relationships with the space or with other assets, which you want to share. So assets would be having relationships between them.

This all is captured into one small snapshot. The snapshot is a change that you do on the model, which gets saved. So every time, whenever you want to save anything to the cloud information model, only a snapshot of it is saved-- a revision of it, which is saved.

So these are the terminologies. These terminologies are very near to developers actually. GitHub is that kind of place where the whole code doesn't get saved every time. Only a smaller set of change are actually saved, and those snapshots are helpful for recreating the exact information.

OK, now how does this look when a file gets saved on ACC, or Autodesk Construction Cloud? So in Construction Cloud, what happens is your files and information in it is actually broken down into objects. Now objects are like nodes here.

These nodes have relationship. So it will give you a structure like something like a graph. It's like a social network, but it's not a social network, obviously. It's a network of objects and the relationships between them.

Doors. So a door would have multiple instances. So whenever you create that, you would have a family of door that you're using in the model. Then you're in those instances will replace the different parts of the walls. And they would represent this kind of very interesting and logical relationship, which is the actual relationship. Which, in our mind, this is represented. So graph representation of data exchange is a very natural way to represent information.

We saw what is data exchange, a very high level view of architectural. So let's go through it. As I said, the Revit models or the Inventor models they will actually be saved onto ACC, Autodesk Construction Cloud. When you save it to it, the source area, if you see on the left-hand side, it's Revit file. Whenever you make any changes, they would become a kind of a contract, a software contract is made, a snapshot is saved. This is called exchange.

This snapshot would have connections to versions, instances, and actual assets. So that every change is able to have versions, and revision, and even the assets, which are like, for example, I had said about doors. So these doors would be instanced and placed on multiple walls. So instance assets will be having assets with information attached to them. It's a very high level overview of the architecture of data exchange service.

So display, I hope you're able to get some sense of what work Forge data exchange is. This service will is taken in other classes also, by Autodesk also. Now what we'll move towards is we use this Forge data exchange to solve the current problems in making a solar panel configurator. I will now ask my colleague, Vivek, to go towards the whole making of solar panel configurators, what kind of problems it solves, and how it can be solved through software. Thank you. Over to you, Vivek.

VIVEK MAHAJAN: Yes. Thank you, Nem, for giving us the whole brief idea about the Forge data exchange services and how it is relevant in our current domain to solve the connectivity problems and collaboration problems. So let's move forward.

So using the Forge data exchange, we have created a solar panel configurator. So the purpose of creating the solar panel configurator is that solar panels provides a way to create an on-site clean energy. Why we need on-site clean energy? Because we have ample amount of sunlight coming towards the Earth every day, but we wanted to use it to create the energy but while designing any building or creating the architecture of the building, the architect or designer does not have any idea or understanding about the solar panels, and how they can model, or how they can design it. So to help them, we have created a solar panel configurator, in which they can provide their solar energy requirements and some other parameters to get the early idea about their design. And by using those ideas, they can update or do some required changes in their design.

So to consider this, there are three functional requirements to create a solar panel configurator. The first thing is that need to share granular data, because we want to place the solar panels on the roof, but we don't want to share the whole building model with the solar panel engineer. So this is the need, which we have to solve.

The second part is that we have to, as the Nem has mentioned, also there is the older way and conventional way. We used to send a geometrical data using the neutral file formats, like STEP, OBJ, but in those geometry properties are not attached to it, the properties like what type of area of that roof is there, what is the material, what is the color about it, because color and material can contribute in the solar designing.

And the third part is the updates. If the building is getting changed, the model is getting updated-- how those changes can be sent to the vendor. To give the full functional requirement, let's consider one case. Suppose there is the building that needs to be powered by solar energy.

Usually, that client would connect with one of the vendors, but the problem is that vendor used Inventor, and they face the issue of sharing. They have the current option of sharing the whole model of the building with the vendor, but they want to protect their IP.

And also, the vendor also don't want the whole model. He's only interested in the rooftop geometry of that building. So to solve this problem, we are going to use updates to solve and share the only roof geometry with the vendor, and do the energy calculations, and do the placement of the panels on the roof. So let's move further.

Going in detail, let's consider these are the four parameters which solar designer will need from the architecture designer. So location. Why we have considered this as a parameter? Because on the Earth, based on the location, the amount of sunlight we see is varied and the energy generation is directly connected with the location, so that's why we wanted this as a parameter.

The second is sunlight exposure. The more directly sun shines on the solar panels, the more energy they will generate. The normal general rule is that the angle of the solar panel is estimated likened to latitude at that location. So that's why, again, the location also comes into the picture.

Going forward, area availability. Area of the panels may be limiting factor for the system, because if you use the higher efficiency panel, you will need a lesser area, but the cost of higher efficiency panels is high. But if you use a moderate efficiency panel, you will need a larger area. So solar designer needs this kind of information, how much area is available for designing their system.

The third part is the solar panel efficiency of the panels. It is also needed, because the cost is directly connected with the efficiency of the panels. It varies which type of panels which you want to use.

So moving forward, this is the whole idea how we are going to complete our workflow. So here, architect will upload roof geometry to the Autodesk Construction Cloud using the Data Exchange connector and a Revit plugin. After that, a Revit engineer will receive the location plus its metal properties from the ACC through a data exchange connector. And using those property and the roof geometry, our plugin will place the solar arrays on that roof and generate a report in which we will provide the information, like how many number of panels are required, how much electricity is going to be produced from need. All those things are covered in it. So without wasting time, let's have a demo about our system.

Here we have created a plugin in which the user has to provide the electricity requirement, its solar hours, and all those things. After that, the plugin will develop rooftop geometry, which we will share without using the full data exchange through the Inventor plugin.

So this here, we are going to select a folder in which we want to share the roof geometry. Here we are going to provide a name for that exchange, which will be identified into the Inventor. And we have created a exchange. Now let's move into the Inventor.

Here in Inventor, you can see the list of exchanges. This is the same name, which we have created into the Revit. It will-- while upon clicking it we have imported the only roof geometry into the Inventor and also the provided parameters from Revit.

I've done here, we are going to place the solar panels based on the requirement. So these are the whole solar arrays we have added to the geometry. And this is the report in which we have added the image, and we can see that there are a total of 107 panels are required. So this is the oral demo of our Revit application. So let's move further and go in detail.

So what is our solution? We have created two plugins. One is the Revit plugin and another is the Inventor plugin, which talks with each other using the full data exchange services.

In Revit plugin, what we have done, we have created a separate view of the groups. Also, we have created a UI in which we access the solar load requirements. And after that, we have created an exchange, which has to be consumed into the Inventor.

In the Inventor plugin, we have listed down all the exchanges which are shared with the Inventor designer. Then after clicking one of the exchange, we only open the roof geometry in it based on the requirement of the-- we create the solar panel array and generate the reports. Let's go more deep into this.

So what is the plugin? In Revit plugin we have used Revit API, also there is a plugin you have, and the Revit updates connector, which uploads the model to the Autodesk Construction Cloud. So this is the high level. Inside the Revit plugin, what we have done is, we have created a frontend in React UI using the hosted browser with the help of CEFSharp library. To communicate the browser and the solar panel API on the back side, we have used a SignalR technology [INAUDIBLE] UI communicating for the purpose of interprocess communication.

And on the top of solar panel APIs, we have also used the Revit APIs to generate the view of the roofs or to gather the properties, like area, the location, all those things are captured using the Revit APIs. So this is the order of the Revit plugin.

Similarly, I will also want to go deeper into the Inventor plugin products. In the Inventor plugin also we have used the plugin using the inventory API, and the plugin you are using react. After that, we have used the inventory objects connector to fetch and upload the model to the Autodesk Construction Cloud.

Inside Revit plugin, we have created frontend in the react UI, which lays down the whole list of exchanges. Plus, there are some forms which will show the properties and requirements provided into the Revit. And we can also change them. To communicate between the browser and the solar panel backend we use the SignalR messaging system. And using the Inventor API, we have developed a logic to play the solar panel based on the location, it's orientation, and how optimally they can be exposed to the sunlight.

So this is the whole idea. So from this whole journey, what we have learned. We have learned how to create a hybrid plugin. So let's talk about what is hybrid plugin. Basically in a conventional way, there are only the-- if you want to create a desktop app, in our current case our plugins are desktop app, you have to use the desktop app development technologies.

But using the CEFSharp browser and SignalR we have created a hybrid application in which we have connected browser and desktop APIs, so that's why we are calling it a hybrid plugin. We also learn and go deeper into the full data exchange services. We also acquired knowledge about the solar panel designing, and its requirement and, some knowledge about the interprocess communications.

So let's move further. As in the objective, we have also mentioned that we want to give you the idea about the more connectors. So let's see what are those.

PRESENTER: Here is a quick demo to our Rhino Read Connector. The Rhino Read Connector enables users to read geometry and properties data from an exchange into Rhino. This will help our customers share a subset of data from their working models with the users who are leveraging Rhino. This will enable workflows like sharing an architectural Revit model with a designer who can use it to leverage the Rhino capabilities, such as create complex geometries and easy integration with other plugins for downstream analysis and automation.

For this example, our workflow starts with Revit, where the information that needs to be shared is defined through a 3D view. The user then creates an exchange using the data exchange connector for Revit. The exchanges are currently hosted on ACC, and you can select the project and folder where you want to post them given that you have write permissions to the folder. Once the exchange is created, we move to the next phase of the workflow in Rhino.

The Rhino connector can be found under data exchange tab. When a user clicks on the load exchange option, it opens a new that allows the user to select any exchange from the given project and load it into the open Rhino file. Users can also search for the exchange they are looking for. We can also preview the exchanges before loading, so we can view the elements that are included in the exchange and decide whether it contains the required information.

After loading the desired exchange, it will show up in the working area of the connector. Once loaded into a file, the exchanges will be held into the working area. This will make it easier for the user to refer to them later. The user can now decide which property types he wants to load from the exchange. This can be used to filter required property information from the exchange.

Moving forward, the connector also provides an option to map the Revit categories to predefined layers. This will give the user better control and categorization over the geometry that is being loaded. Users can also decide not to map categories to layers, in which case, all the geometry will be assigned to a default layer. The properties loaded along the exchange can be found under attributes. Once the geometry and properties are loaded into Rhino through a data exchange, this data can be used as native Rhino elements by the downstream user to support their ACC workflows.

VIVEK MAHAJAN: So this is the debut of the Rhino connector in which a user can share the geometry between white and Rhino with geometries as well as properties. So there are some future connectors in the pipeline in which Rhino, Grasshopper, some other kinds, of course, are also going to be happen. So I think next part is going to be taken by the Nem. Nem, over to you.

NEM KUMAR: Thanks, Vivek, for a good explanation. Nice videos to understand the first data exchange. I hope the people are able to understand, in totality, what Forge data exchange can do.

The next question I think is, where do we start? So I think we would suggest a couple of pointers that, first of all, we need to educate ourselves with the data platform services, like FDX, et cetera. You need to identify the gaps in the current workflows and the business problems that you are facing. Find the causes of the delay and the cost escalation and what can be done in those projects. Based on those, some data exchange connectors can be made if your team is capable of connecting the data exchange and your plugins. Well, if not, then work with us and/or the system integration partners who can actually help you to make something similar like the solar panel configurations.

I would suggest to you that we start the journey with a small task initially and slowly it will become big. The data would be part of everything we do. So this will be very helpful that we start with something small.

A couple of references, very important references, Forge data exchange on the Forge dev platform website. Tutorials-- tutorials are being released to understand more about exchange containers. The documentation is pretty good. One more important thing for required for connectors, that means the plugins, which actually does the connection with the Autodesk Construction Cloud. Its a geometry utilities SDK kit. That also is in the preview.

And one of the most important, GraphQL. Currently, these all queries happen through REST. That means saving an information to Autodesk Construction Cloud, currently happens through REST APIs, but very soon they're migrating towards the actual graph-based query language, which is more satisfying, and fast, and helpful. So learning about this is also a very good thing that your team should do.

Thanks to the team for listening so patiently. If there are questions, we can take it over, or-- and you can also come visit us at CON366. We are exhibiting there. We are exhibiting our solutions and services. So Sandip, Vijay, me, and Vivek would be there happy to connect to you again. Thank you.