Deep Dive with the Model Derivative API

SHARMILA PHADNIS: All right, everybody, welcome to the class on Model Derivative API. My name is Sharmila. I'm a little nervous. But more than that, I'm very excited to be meeting with all of you and sharing the information on this API today.

To give a little bit of background about myself, I started as a software engineer in Autodesk four years ago in the office of the CTO. I was a back end services engineer, writing code in C shell before I move to product management last year.

When I moved to product management last year, I was partnering with the engineering teams to design the APIs for, basically, Model Derivative API and making its launch a success. And today I am working on the Forge platform.

So let's start. Let's take a look at the class summary to see what we will cover in the class today. We'll start by giving a quick introduction to Forge. Why Forge? What are the different available APIs we have today?

Followed by introduction to Model Derivative API, we'll take a look at different features of the different API endpoints that are available. We'll do a code walkthrough in Visual Studio to take a look at the code snippets, right from uploading a file, to translating it, to extracting data, and extracting geometry.

We'll conclude the class by showing a couple of customer samples, and then we'll call it up. I hope this is what you're looking for in the class and, yeah, let's take it forward.

So why was the reason we created Forge? In the past, Autodesk IP was locked inside its software, libraries, and components. We wanted to provide a set of APIs so our customers and users can leverage these APIs to not only build custom solutions, but to share data and to collaborate on this design data easily, anywhere, anytime, be it desktop or mobile.

So that is Forge.

The different APIs that we have available for Forge are listed in the slide. The Viewer, many of you in the class must have used the Viewer to upload your CAD files, and view in it A360 Viewer.

The authentication API is used to get access to a beta token, which is subsequently used to call the rest of the APIs. The Model Derivative API is used for translating files and extracting data.

Data Management API provides a single unified way to connect to multiple day sources, be it Fusion, be it a Design Automation API to work with your CAD files, AutoCAD files, and then 360 API for the Data Models.

Now let's take a look at Forge Model Derivative API. As many of you may have used the A360 Viewer to view your CAD file in the browser, what happens behind the scenes is it's the Model Derivative API which is doing that translation for you.

It's translating the CAD files into a viewing format called SVF, which is a Model Derivative API.

Now when we took a look at it, we started thinking about, basically, it's acting like a translator. Why don't we expose more translation formats that could be used by our customers to translate from input, from one input file format to another.

So it started growing into a translation API engine. And then we started talking to our ecosystem of partners and developers. They came up to us with use cases around what if you provide the CAD data that is residing within these models as APIs, so we could integrate them with other solutions, ERP solution, Costing Systems, et cetera.

So that was the second use case.

The third use case was let's say you wanted to build a chair. You're building a chair, and we wanted to extract the legs of the chair and translate that into an SVF file for 3D printing. So that requires you to isolate those pieces of geometry, extract them, and basically, convert them into an OBJ file format, an SVF file format that you like.

And the customers wanted the ability to have a CAD design gallery where they could view the families of each of the CAD files before the preview the file and render the model itself. And that's where the thumbnail feature came from.

So at its core, the Model Derivative API is used for file translations. It's used to extract the thumbnails. It's for getting the geometry, and it's also for extracting the data.

Now let's take a quick look inside what are the different supported translation formats. Did you know that we provide more than 60-plus different file formats in our translation. Some of them are listed here.

So we support translating from any of the Autodesk file formats, or even some of the competitors' file formats, into STEP, STL, IGES, SVF, thumbnail, OBJ, et cetera.

To get a complete list, go to developer.autodesk.com and take a look at the supported translations page there, or you could also invoke the formats endpoint to understand what the input file formats and what you can translate to.

OK, so this is a screenshot when you upload a model into an A360 Viewer. What happens when you load the model into the Viewer is on the left hand side, you'll see an object hierarchy which shows the model parts within the model-- which shows the model parts as a hierarchy of objects.

So as you can see, the hierarchy here shows suspension model. It has front-side plates, mounts, et cetera. And then you click on a part, and what it's showing you are the properties associated with it.

Here it's showing you area, density, volume, mass, et cetera. So as you can see, what we have-- the essential features of this is we have the object hierarchy. And we have the properties of a part model that we are extracting from it.

So at its sense, the features that Model Derivative APIs supports today are the following endpoints. I have summarized them as set of features that you can use.

The formats endpoint is used for getting the latest and greatest translation formats that are supported today. We use the job endpoint to translate a file from one input to another. So as part of the job, you specify what is the input, what is the file that you're trying to translate, and what is the output that you're trying to get out of.

We use the thumbnail endpoint to extract thumbnails from a CAD file. We use a manifest API to poll for the translation status to check if the file has completed, or if that's failed, and what is the progress of that. Alternatively, in the future, you, should be able to use webhooks for the same.

The metadata is used to go through the object hierarchy of the model and then get the rich, specific views and associative properties of those objects.

Now that we have seen the features, it's time to dive a little bit into the code. You are going to use Visual Studio C shell. And we'll do a walkthrough of each of the code snippets, right from authentication, creating a bucket, translating a file, and extracting geometry.

So first things first, I hope all of you in the class have gone to developer.autodesk.com and created an app and have access to your client ID in secret. How many of you haven't?

OK, it's time to create an app. All right, let's do a code walkthrough. What we are going to do first is create an auth token, a beta token that authenticates an user's credentials and helps you to invoke the rest of the APIs. And that's the auth snippet we have.

What do we specify are the scopes to invoke to create the right beta token. What we have specified here are the client ID and secret. With the help of this, a token gets created.

Now let's take a look at how would you create a bucket. What I mean by a bucket is a storage depository wherein you store your, you upload your design files, and you also store your derived assets that are created out of translations.

And that is the code snippet for creating a bucket. So it's pretty plain simple. This is using all C shell SDK. So as you can see, we specify the bucket ID. The bucket ID is the name of your bucket. And we specify the region in which the bucket exists. It could be a US or European region. And that's what gets classified there.

And after this, you have a bucket that you can upload your design files to and store your derived translations.

Now let's take a look at how we would upload a file. The next step is uploading a CAD model. Select a CAD model and invoke the upload method, upload object method on it to specify your bucket name and the file. And this uploads your CAD model to the specified bucket.

So now that we have a model that is uploaded, let's try to translate that file into an SVF file format, which is basically what is viewed in an A360 Viewer.

So as I mentioned, we use the job endpoint to specify what is the input and what is the output. Here the input is our CAD file, to which we have a file ID or an identifier, and then we have an output format, which is the SVF, which gets specified here. The output is SVF.

And once you submit this job for translation, we have to call the manifest API, poll it, to find out if the translation is successful. And that's when we call the verify job complete method.

As you can see, we call the get manifest endpoint there, which is checking for the status of the file for translation. And once it's complete, it writes it to the console if the file was successfully translated or not.

So let's go back to the browser to take a look at how a Fusion file is translated and shown in the Viewer. So when it's done, want it in SVF file format, this is how it's rendered in A360.

Now let's try to convert it into a STEP file format. So when you convert this file into a STEP file format, it pretty much remains the same. You use the same job payload to specify what is the input. The output differs. The output here would be a STEP file format. That's what gets specified here.

And once again, you do the same thing. You poll the get manifest API to check if the status is complete, and when it's complete, what I've shown here is a STEP file uploaded onto the browser. And this is the output of that.

Let's try to convert it to another file format, OBJ file format. So again, the core pretty much remains the same. What changes is the output. You specify what is the output file type, which is OBJ out here. And when you look at it in the A360 browser, the OBJ file is displayed here.

After that, I've done the same thing for converting your models from Revit to an IFC file format. So this is the Revit file, which I converted to on IFC file format using the same job payload, but by changing the payload to IFC, which is shown here.

So as you can see, we are translating the design data into many different file formats.

Now it's time to take a look at how will you extract the data. Because not all of the data resides within a model. You could have a Revit model, but it maybe talking to Cost Information Systems, or ERP, or other billing information systems.

So you want to extract this data and connect it to other different data sources. But how do you extract the data from a CAD model? So let's take a look at the extraction endpoint.

As part of the Model Derivative API, what we provide is a method called get metadata. And when you call this get metadata, you get access to the views that exist as part of that model.

So what happens is when you're dealing with a manufacturing model, you may just have one view, a design view. But when you're working with an architecture model, you may have more than one view. You may have HVAC. You may have MEP.

So the metadata endpoint gives you access to the different views that you have within the model. And you're using the hierarchy endpoint to go through the object tree structure of the metadata.

Once you have the hierarchy, you can extract the properties of the objects by calling the get model view properties.

OK, so now that we have used the metadata endpoint to get the hierarchy and get the properties of a model, let's take a look at how the output looks like.

So when you call the metadata snippet example, it's showing you the output of the json. Here it's showing that this particular model just has one view, and this is the identifier of the grid. And when you pass this grid, you get the object tree structure for it.

Now let's take a look at the example to show the hierarchy of the object. So this is the json response of the different object IDs and the embedded tree structure of the objects within it.

Now when you identify that this is the object ID for which you want to get the properties, you would call the properties endpoint, right. And this is the output of how the properties endpoint looks like. So you may want to extract this data out and use it in different, disparate data sources for connecting.

Now that we have seen how to extract the data, it's time for us to check out how we can extract isolated pieces of geometry from a model and use them effectively.

So the code for extraction of object depends on calling the metadata and identifying the object for which you want to get the properties and for which you want to get the geometry.

So here you need to parse in the model grid and the object ID as part of your advanced job payload. As part of your job payload, you firstly specify what is the output type, which is OBJ. We currently only support OBJ for extracting geometry. And we also specify what is a model grid, and what is the object ID.

That's pretty much it. After this, after the job is submitted for translation, we poll the manifest API again to check if the status is complete and extracted out.

For the purposes of demonstration, I have extracted a shaft from the motor, the Fusion sample that I have just shown. And this is extracted for object ID 36 on a polygonar model grid, this is how it looks like in OBJ file format.

I've done the same thing for an architecture model. I've provided an object view, I think, I've provided object ID of 36 or something. We specified a model grid, and it's extracting the revolving doors from that model into a separate field.

Now let's go back to the presentation.

So now that we have done a code walkthrough to understand how to create a beta token, how to create a bucket. We uploaded the model. We converted the file to SVF. We converted to STEP, OBJ. We have seen how it trained us in the Viewer. And also we extracted the properties and the object hierarchy, and we extracted isolated pieces of geometry.

So that's all good stuff. Now, it's time to take a look at how our customers are leveraging the Data Management API, the Forge APIs, the Model Derivative API API to create their solutions.

The first example that I want to talk about is NBS. NBS offers specification and information solutions for engineering, architecture, construction.

Their customers wanted the ability to move the data from paper to online to help coordinate project team members for thinking they're Building Information Solut-- for thinking their BIM data with specifications, anytime, anywhere.

So what NBS did was they leveraged the Forge platform. They leveraged the Data Management API, Model Derivative API to sync the models to the specifications.

Let's take a code walkthrough in the NBS sample. As you can see, what they have done is they have loaded a model in the Forge Viewer. And once you click on the roof, it's showing the specifications on the right-hand side. It's showing not only the model properties, the object properties derived from Revit, but it's also showing you the specifications on the right-hand side.

So it's allowing that linking. And this is accessed anywhere, anytime. So that's the first example.

The second example is of simulation hub. CC Tech developed a simulation platform app that helps their customers to run CFT simulations in the cloud. It allows their customers to analyze the flow, the airflow and the fluid flow.

They have it for both manufacturing and architecture apps. What I'm trying to show here is a control valve performer app, which generates the performance curves, and it also runs a the fluid flow vectors.

The usage of Model Derivative API here is they have to run these flow animations, they extract the data in OBJ. They translate the file into an OBJ format, and they superimpose that to show the flow animations into the model. So that's the second example.

The third one will be discussed by my friend, Augusto. Augusto is a Forge evangelist working with the Forge Developer Network Team.

AUGUSTO GONCALVES: It's here, right? Yeah, so this sample is the last one. It's actually getting the data that is hosted on Autodesk data management.

So at the left side, it's showing you all the files you have hosted on your account, after the sign in, of course. And the user can then select the file that is available on data management.

In this case, the user is selecting a building that has a file available as part of Revit. And there's a button right on the bottom right that is going to call the derivative endpoint and get all the hierarchy and all the profits of all the elements of the model, run through that hierarchy, and create a spreadsheet file from that.

Note that when we have the hierarchy, we have the top elements and the child elements, but only the leaves of that tree are actually elements on the model. So we have to isolate all the leaves on the tree.

And once we have all the leaves, we can then get the profits and organize by the category. In hierarchy of the elements, we can organize the elements on types. So I can see all the elements that are doors, all the elements that are walls, and then create a spreadsheet with all the walls, all the doors, all the roofs, et cetera, et cetera.

So the sample that is running on this animation is available as part of our GitHub and also on the Bing 360 App Store. So if you go to GitHub.com/AutodeskForge, you can see the source code and the link to run the sample.

So, yeah, that's the sample that is using Model Derivative to create the spreadsheet, basically with all the data part of the model.

SHARMILA PHADNIS: OK.

AUGUSTO GONCALVES: Oops, don't do this.

So there are a few points on the API that are coming. The next thing that we are planning to have is the webhooks. Actually, webhooks are available as part of Data Management, not part of Model Derivative API.

So Brian Roepke showed this morning a sample using Twilio, and email, and this classification that is coming from Data Management webhooks. Webhooks will also be part of Model Derivative APIs soon.

But the main idea is that you can register an endpoint with our service, and whenever something happens with Data Management or Model Derivative, Forge will call your application, telling you, OK, this job is done.

This file was created. This job is completed. So your application can react to that, and you don't really need to call Forge all the time for updates.

So webhooks come to solve this trouble. And the Reality Capture API is also moving from beta, private beta, to a more open beta. That's We're increasing the number of photos you can upload to Recap Reality Capture API. And now we can do up to 1,000 pictures. Before it was 250.

And now its more stable and faster than before. So, yeah, it can also use Recap APIs. I know Recap APIs is something that everyone is really looking for to have to create 3D models from something, right. But as word of experience, Reality Capture is better when doing capture of big areas like a field or a construction site.

Don't try to do Reality Capture inside of an area like this, like inside a room will not work. You need to take pictures around the object, not inside the object. It's not good with shiny or places with lights, et cetera. So it's good to capture like a few like construction sites. Others, it may vary the results, so yeah, give it a try.

SHARMILA PHADNIS: We have more upcoming APIs. We have the Design Automation for Revit and Inventor coming up. That's pretty much it for now.

Let's take a look at some of the resources that are used for this class. It's a good idea to go through those resources. It had a lot of code samples. There are a lot of customer success stories that have been mentioned.

Take a look at GitHub samples for Forge, which shows right from-- there are very simple samples, too, which shows you creation of a bucket, uploading your files, and getting into the details, such as uploading your files, and connecting to your hub to translate a file right from the capacity of the app that was created.

So you can specify what is the output that you want from an a CAD file and download them as needed. I've also given the link to the demonstration, to the apps that I showcased in the class, the simulation hub.

Take a look at NBS Viewer, too. It's in beta. But there are a lot of, there's a lot of press and blogs around that, too. With that, I call it a wrap. I believe I was a little nervous.

I may have spoken faster and kind of completed it in 30 minutes or something.

- It's good to have part time for questions. Open this up for questions.

AUDIENCE: With Derivative APIs, there are features for downloading [INAUDIBLE] files and [INAUDIBLE]

SHARMILA PHADNIS: No, no, we do not have that ability now. You need to convert it first and then download that and store it locally on your machine.

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: No, you would need to upload your model first and extract the data and then download the results back via local. So it's all in cloud today

AUDIENCE: [INAUDIBLE]

--just one piece of geometry, you have to send it again to the cloud, convert it again. It's like one big geometry to download.

AUGUSTO GONCALVES: So, I think, just a point of, OK, when you upload the file into the translation, the default translation is to translate the file from SVF, which is Viewer, right. That translation, it will translate the entire file, and it don't have to translate again.

If you want to translate to a different format, let's say OBJ, then you need the seed file, the source file again to translate to OBJ the entire file or just pieces of the file.

So in this case, what do you want to translate, do you want to translate the entire file or just pieces of the file to Viewer or to OBJ? What really are you looking for?

AUDIENCE: [INAUDIBLE]

The geometry's there. We can see that in the Viewer. Why should it be extracted from the seed file when it's there? I mean when I want just one piece of a thing, whatever, from the currently exported model, why should it be done on the cloud? What did this solve by storing the geometries here?

AUGUSTO GONCALVES: OK, so he is asking why do we need to upload again to translate the file again if we had the translation already offline and then download the translation. The SVF or the Viewer format of the file is not the actual, solid, or actual element of the model. It's just a bunch of faces of that model.

So let's say you have a wall, right, on the Viewer, you just have the faces that define the wall. You don't actually have a solid that defines the wall. So if you want to get that same wall to translate to OBJ, there is no information about volumes and solids, or what's inside, or anything else.

The Viewer is just the faces that we create the geometry. So if you have the full file on your local machine, you can view the entire file or view pieces of the file. But if you want to extract OBJ, you need to get to the seed file again, so the translator engine can then look at that wall and get all the solid and volume information inside it.

The Viewer is just faces. There is no solid, or volume, or anything like that.

SHARMILA PHADNIS: But it's a good idea to think in terms of the potential for upcoming features in the future and give it a thought to check, if you're in the context of the Viewer, and you want to isolate pieces of geometry and download them, it makes for an use case, so I'll give it a thought.

AUDIENCE: [INAUDIBLE]

--I wondered why that is not by default provided for us?

AUGUSTO GONCALVES: I think as Sharmila said, it is a good use case for it. We need to discuss that deeply what you are really looking for on that feature, so we can get back to development and look at this. But then you--

SHARMILA PHADNIS: Let's connect. Yeah, let's definitely connect.

AUDIENCE: Can you talk about the cloud credits it takes to do the translation?

SHARMILA PHADNIS: That's a good question. So as of today, the support for Revit and Navis files, because they are huge, we charge 1.5 cloud credits. For any other file format, we charge 0.2 credits.

AUDIENCE: So the example that you did, you took a file and you converted it to Viewer, so that's $0.25 or something like that. Then you exported that to a different format, and then you convert it into Viewer. So that's basically uploading STL and saying [INAUDIBLE] basically what we saw on the screen. Is there any difference between a hundred-meg Revit file versus a 0.5-meg Revit file? I mean $1.50 for translation seems like a lot of money.

SHARMILA PHADNIS: Today, we do not have that. We may in the future. But as of now, we have segregated the different file formats for every--

AUDIENCE: This is purely a file format.

AUGUSTO GONCALVES: Actually, I just explained why, actually, we do have server lists or applications running, and it takes a long time for us to launch the machine to translate the file. Once that machine is up and running, translating the file is really fast. What we're doing, those clouds credit costs really reflects the costs we have to translate the file within an address.

So what we are doing inside, back home is to improve the engine we have so we can reduce that cost and then reduce the price for you. But as of today, if you translate a Revit or Nav file for Viewer or OBJ, any job you post is 1.5 cloud credits or 0.2 cloud credits for the other formats.

SHARMILA PHADNIS: But certainly we are analyzing the data to check how much, what would be right costs for translating depending on the file sizes.

AUDIENCE: And one last followup, if you were to replace that original file, so if you took a Revit file and uploaded it and then did a translation for the Viewer, and then you made a change to your model and you upload it again, and it overwrote that same file. What happens to that original Viewer, that original translation? Does it get destroyed when the original gets replaced? Or is it always there as an old version of it?

Could you explain how that persists?

AUGUSTO GONCALVES: There are two pieces actually. There is the seed file and the manifest file. You can delete just the seed or just the manifest. If you delete the seed-- OK, so if you re-post a job, there is a header attribute to overwrite everything. If you don't overwrite, it will be the old translation. So it's really up to you what you are to do.

For instance, if you have big files, and you don't want there to be charges on the storage, you just translate, and then you raise the seed file and just keep the translation, for instance. But you can decide what you are to keep. Or you can just say that the bucket is, it's temporary, and everything will be erased after 24 hours.

AUDIENCE: With the ISD network [INAUDIBLE] from an user perspective in Revit, there's a lot of options related to generating this ISD content and being able to map elements to ISD use and things like that. Are you supporting any of that? Or are you just like here's an ISD file and maybe it'll be ready, maybe it won't?

SHARMILA PHADNIS: As of today, we do not have the way specify the different options for conversion. We plainly converted to IFC.

AUDIENCE: So do you have documented what IFC you're-- Do you have documented anywhere what we should expect, what IFC is coming out of that translation?

AUGUSTO GONCALVES: Well, it's not documented, and that's blame on us, sorry. I will put a request for that, but it's using the default options. But it's not documented, and, yeah, I'll put it on our list to fix it. That's a good point, yeah. Thanks. So, yeah, it's not clear today what are the default options on that. Just to get-- he's waiting.

AUDIENCE: Just to clarify, if I upload a seed file that makes the Viewer file, is the seed file still in the cloud?

SHARMILA PHADNIS: Yes.

AUDIENCE: So then, if I go to convert to an OBJ to do a polygonal model from a solid model, is the OBJ derivative of the Viewer faces, or is it actually tessellating and translating from the seed on that operation? And the second part of that question is can I influence that tessellation or alleviation, all that standard stuff. Say if I want to use it as like a transmission tessellation service?

AUGUSTO GONCALVES: OK, on the first question, if you upload the file and extract the OBJ, that OBJ is no longer connected to the original file. So you need to upload again and translate again to view it on the Viewer. So they are complete separates.

So once you have a Revit file and translate to OBJ, IFC, you have a completely disconnected file, which is just an instantaneous or momentary, one-time view of that file. And in this case that Sharmila showed, she's uploading again and translating again to view it on Viewer. So we have different options.

So on the second question?

SHARMILA PHADNIS: The second question is, well, you would have to do the translation to SVF and then convert it to SVF file format. Is that what the second question is?

AUDIENCE: That's OK, we'll take it off topic. That's product visualization. It's different, so.

AUGUSTO GONCALVES: OK, come to us then.

AUDIENCE: Yeah, can I just do a quick follow-up on the question back there about cost. Can you give us an idea for how much to expect for the cost for doing one of the queries would be? Like so if I query out of the object model, is there going to be a cloud credit cost at all?

SHARMILA PHADNIS: So as of today, as of today, the pricing is you can start for free, and you get 500 cloud credits. And with those cloud credits-- you get 500 cloud credits, and you get 500 gigabytes of storage as well.

So we charge today for translating files and design automation API. So if you're translating between models, you're getting charged for that. Or if you're using the Design Automation API for batch processing of your big files, that's all we charge for today.

We do not charge for downloading or uploading your files to storage as of now.

AUDIENCE: And that is a query. So you showed you query the objects--

SHARMILA PHADNIS: No, we don't charge for that. Go ahead. I'm sorry, you think I should take--

AUDIENCE: [INAUDIBLE] file support,

AUGUSTO GONCALVES: Revit payments are not yet supported, just because it's very complicated to extract the geometries, because it varies, right. So let's say you have very complex family, how to extract that?

We are trying to understand more what you need and what you want about families. And I would suggest that you come here after, because I will connect you to-- and I forgot her name now. I will remember, but she's collecting feedback on that.

But if you really need just the family, the best way right now is create a Revit file with just one family and translate that. Right, so let's say you have a wall-- sorry, not a wall, a door, right.

How to translate a door? What about the wall? What's the type of that family translation? So there's a lot of questions there. That's why we don't have support for that yet. And Sasha, yes, Sasha, what's her last name?

SHARMILA PHADNIS: Sasha Krodi.

AUGUSTO GONCALVES: Yeah, Sasha Krodi, she is collecting feedback on how you to handle families.

AUDIENCE: So if we want to download the bulk of translated bubbles, is there any possibility that we can get one endpoint to do that, instead of calling all the endpoints of the files, having it download to view online.

SHARMILA PHADNIS: You call one endpoint to get access to the manifest, and the manifest has different children for each of the derivatives. And you download each of them individually. So what you're asking for is bundled that downloads all of your deliveries at once?

AUGUSTO GONCALVES: We don't have that yet. Yeah, we don't have that yet. We just have the samples that are doing that. But the samples are just, you know, wrapping around, downloading everything you need. We do have a request for that. There are some discussions back home how to support that workflow.

We do support offline viewing, but we don't have the APIs to support that, so there is discussion going on. But, yeah, we don't have a solution for that yet. As of now, use the samples to download all the pieces you need and create the file locally.

SHARMILA PHADNIS: Question out there.

AUDIENCE: So, it seems like there is a concept of translating a file from SVF into [INAUDIBLE] and then a separate file extracting geometry for the file from the SVF? Am I right in saying that the difference there is just that you're, rather than [INAUDIBLE] the geometry, you're selecting a specific subset of it?

SHARMILA PHADNIS: Yes, that's exactly right.

AUDIENCE: So how exactly is the structure of [INAUDIBLE]

AUGUSTO GONCALVES: I think there is just one confusion, right. All the translations are happening from the seed file to a different file, not from SVF or any other to any other, right. So if you want to translate to SVF, which is Viewer, you gain for free the profits in the metadata.

If you want to translate to OBJ, you need the seed file to translate to OBJ. If you want to translate to IFC, you need the seed file to translate to IFC. So all the translations will happen from the seed file to whatever. And the only variation, the only special one is the SVF that you get the Viewer plus some properties which are connected together.

So, yeah, keep that in mind. You always need the seed file to translate to something, and then you get all the other properties. The OBJ is just one exception, because you can translate to OBJ the whole thing or just one piece. But that one piece is just, we are just getting that specific object, that specific element, and creating one OBJ for that element.

But, for instance, we don't have yet a way to create one OBJ for each element, which is a problem.

AUDIENCE: My question is just how do you set which case you want?

AUGUSTO GONCALVES: Oh, that's the sample she showed, right, let me--

SHARMILA PHADNIS: So you load through the object hierarchy to--

AUGUSTO GONCALVES: Which one is it?

SHARMILA PHADNIS: It's the metadata snippet. Metadata.

AUGUSTO GONCALVES: Not this actually.

SHARMILA PHADNIS: Yeah, that's exactly the one. That's right. So you call this metadata endpoint to get the specific views, and then you call the hierarchy endpoint to get the object tree structure, and you select the object IDs. And that's what you would use as an input when you call the extraction geometry.

This will be published, so you can make use of this. There was a question in the back there.

AUDIENCE: Yeah, just a quick question. You mentioned [INAUDIBLE]

AUGUSTO GONCALVES: So you are asking how the Revit, as part of an automation would behave, right? So it is running right now as a private, like a very restricted data. The endpoints for Revit IO as part of design automation are the same as the AutoCAD IO design automation.

So the same source code should work, except that you need different jobs to translate. But if you're interested in that, you can, again, talk to Sasha. She's managing the Revit IO private data.

Yeah, it's basically the same endpoints as the AutoCAD design automation. I can show how it works, or how it's specific. Just come back to me, I can show you some samples.

AUDIENCE: If you do some functionality similar to the Model Derivative?

SHARMILA PHADNIS: That's a great question. Unfortunately, I don't know the answer to that, but I'll get back to you.

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: Right now it spits out entire metadata at once. There's no way to get partial--

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: What if you-- do you have multiple views within that model? OK.

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: That's something that I should discuss with you offline, so that we can think about it and try to--

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: So this is a great platform to hear out your use case and then work with the engineering team to make that possible.

AUDIENCE: Yes, is a way to accommodate the translated model? Like most of the time a huge model gets translated [INAUDIBLE], and I don't want to do it every day. I just want to push the updates, what was changed.

SHARMILA PHADNIS: Right now we don't allow updates to the model. Right?

AUGUSTO GONCALVES: Yes, no. So if you have a big file that has just changed like one property, you have to create a new version of that file, upload again, and translate again.

AUDIENCE: Pay for the whole file?

AUGUSTO GONCALVES: Yes, unfortunately. But even if you have separate files, it's still one file, because when you translate the file, if you have one Revit file with a lot of linked files, that would be translated as a single file. So it is not about the size but about starting the engine, right.

What we are working towards is to have the high frequency data management that Brian mentioned this morning. That's a solution for that problem, because as of today, or as how we design our applications, we have single binary files. And that's not working in that environment, right.

So that's why we are redesigning how we keep data, and as soon as we release or have something running on high frequency, we can do that better. But as of today, that's almost impossible, because we don't have a way to handle those files.

Collaboration for Revit is a way to work around that, but it's not a perfect solution yet. But what I'm saying is this is a problem. We are trying to address that problem. We don't have a solution yet.

AUDIENCE: I'm looking forward to [INAUDIBLE]

SHARMILA PHADNIS: Right now, as of today, we do not have that.

AUGUSTO GONCALVES: So the best way to support additional data on Viewer, if you have a custom, or you have your own instance of Viewer, is that you keep that on your local database. So you keep that extensive data on your local database and then translate that.

I do have a sample that I wrote, maybe one year ago that I have a Revit file, sorry, [INAUDIBLE] file. And I created a plugin inside AutoCAD that creates a special DWG with additional attributes, keep those attributes on a database translated to DWG, and when showing, put the two pieces together.

So you have a custom instance of Viewer showing data from the original data and your custom data. So that's the best way of doing that today. We don't yet have support for x-data or other types of data, just because the range of possibilities is too big.

I was talking to Albert [? Siovotsy ?] about that. That's the guy who designed the translation for DWG. And the range of possible options we have on x-data is too complicated to support in a generic way. So that's why we don't have a support yet.

So if you have a custom instance, you can just override the property palette and show your properties in there. Would that work?

AUDIENCE: [INAUDIBLE]

AUGUSTO GONCALVES: Yes.

AUDIENCE: [INAUDIBLE]

AUGUSTO GONCALVES: Yeah, no--

AUDIENCE: [INAUDIBLE] with the data [INAUDIBLE]

AUGUSTO GONCALVES: Yeah, let's discuss that offline. I'll try to connect you to this guy Albert. You may provide some feedback on the x-data, how to support that. That would be a way to-- Oops.

AUDIENCE: Just to echo the general comments, why does Autodesk automatically create a Viewer file for every file that that we upload? I mean, I don't think [INAUDIBLE] So it just seems like if you're going to put it out on Forge at all, would want to look at it, right? Can you explain why that isn't automatic for everything we do? What's the use case of not ever converting to an SVF file?

AUGUSTO GONCALVES: I'm not sure if I'm following. Can you--

AUDIENCE: So if you put the seed file onto Forge, you do have to do a translation to the Viewer, and you have to pay for that, right? So what's-- It seems like that should just be an automatic process. You put it on Forge, why would you not look at it? I'm trying to understand what the use case is for never translating to the Viewer.

AUGUSTO GONCALVES: Actually if you upload the file to a hub, to a project on B360 or A360, the file will be automatically translated.

Those are user files. If you upload the file to a bucket, that's a developer perspective. In that case, it's not automatically translated, and you can define how to translate the file. So that's the difference.

So when you upload to a bucket, you may just want to extract as an IFC, for instance, there is no reason to translate to SVF. But if you're to upload to A360, B360, it will be it will be translated automatically.

OK, so there are two cases, right. Two-legged and three-legged, so that's the difference. But, yeah, that's how it works.

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: That's a great question. We've only been releasing it in phases. We'll probably import our Core Data Management API first--

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: Not at the moment, but we are working on it. That's on our radar.

AUDIENCE: [INAUDIBLE]

AUGUSTO GONCALVES: So if you have a Revit file with 3D and 2D views, they have the same ID on the Viewer. They may have different properties depending on how the sheet was designed. For instance, on Revit, you may redefine the sheet in that case, but the properties will be the same.

Because the properties are separated from that. So we have the geometry database and the properties database. And the properties are linked by the ID of the element.

So they are the same element, and you can connect them. We have a few samples connecting 3D and 2D elements on the Viewer. So if you have two views of the model, you can select on one and select on the other, zoom into both of them. They are the same element. Just with different representations of the element.

AUDIENCE: [INAUDIBLE]

AUGUSTO GONCALVES: I don't have an answer for that. I don't know. The Revit translation to IFC uses the Revit translator. So it will be whatever Revit's doing. I guess it's Revit, it's IFC standard 3-point something.

So I would say that would be IFC, with the geometry plus the properties available as part of IFC, which are not the same as the RVT files, but all the IFC properties.

AUDIENCE: [INAUDIBLE]

AUGUSTO GONCALVES: No, the IFC translation is only from Revit to IFC. We don't support Novis to IFC yet.

AUDIENCE: [INAUDIBLE]

SHARMILA PHADNIS: We do allow uploading Inventor assembly files as ZIP. And then the Model Derivative API in the back end tries to resolve those references, and then converts that into an SVF file format. So it is available through the API. I'd urge you to take a look at developer.autodesk.com and take a look at the compressed option there. And take a look at how to upload Inventor assembly files.

AUGUSTO GONCALVES: I think we're out of time, oh, just one more over there.

AUDIENCE: Just one more question, on the terms of the 2D versus 3D sheets, what it looks like right now in the translators after you've translated two-dimensional your annotations lose all of their properties if you write any type of extensible storage on it, the Revit side of things. Is there any future development to bring across parameters or properties on annotations as well?

AUGUSTO GONCALVES: Do you know? I know the extensive storage on Revit is like the same thing, x-data. There is no standard way of showing that data, because it can be anything. But if you have like shared properties with Revit that should go through the translation.

AUDIENCE: They don't at all.

AUGUSTO GONCALVES: They don't do it?