Allow Users to Extract Physical Properties On Demand Outside the Autodesk Fusion 360 Canvas

ANKUR KUMAR: All right. Welcome, everyone, to this AU class about extracting Fusion physical properties outside Fusion 360 Canvas. Let's begin with quick introductions. My name is Ankur Kumar, and I'm an engineering manager for the MFGM team. And joining me as a co-presenter is Patrick Rainsberry, senior product manager from Fusion 360.

All right, so let's start with an exciting safe harbor statement. Essentially what it means is that please do not make any purchasing decisions solely relying on the statements made during the presentation. We are going to assume that all of you have read it and understand it.

With that said, let's get right into the presentation. Starting with the learning objectives. Based on this class, you will be able to learn about Fusion physical properties, about how it's integrated into FusionTeam, how you can extract physical properties once and reuse it later, and what workflows trigger the extraction from Fusion 360 and FusionTeam.

My colleague Patrick will cover all the cool stuff related to the GraphQL. You will gain an overview on our API developer documentation, step by step tutorials. You will be able to explore GraphQL syntax and usability. You will learn about sample queries. And since you will be calling the MFGDM API through GraphQL to trigger the extraction and read physical properties in your third party applications.

So the introduction to Fusion physical property. So Fusion 360 can extract mass as well as position dependent properties, the mass properties being the mass, volume, surface area, and density. And the position dependent properties being the bounding box, moment of inertia, position coordinates, and the center of mass. Overall, this set of properties is referred to as physical properties.

OK, so physical properties in Fusion 360. Until now, the physical properties were extracted inside Fusion 360 Canvas. It was hard for users to access the physical properties outside Canvas. Every time the user wanted to view the physical properties, they would need to select the subassembly or the assembly. Any component that they wanted to view the physical properties, they would need to select it and then open the Properties panel to view the physical properties or the selected components.

We'll talk through this demo. I'll show you how the physical properties are extracted inside Fusion 360 as of today. As you can see, the physical properties of an assembly. You select the assembly. You click on Show Properties and the physical properties mass, area, density are visible on the Properties panel.

You want to view the physical properties of a subassembly, you select that subassembly and the physical properties are extracted for that subassembly. Even for a smallest part such as a screw in this particular subassembly, you select that part and the physical properties are visible for that particular part.

All right. So we will now talk about physical properties extraction service. Physical properties extraction service, short form as PP, is a scalable cloud based solution that enables users to extract physical properties on demand without the need of Fusion 360 Canvas. For a given Fusion design file, physical properties can be extracted just by providing the root component information. And physical properties will be extracted for every subcomponent and stored in the MFGDM database so that it can be reused.

What you see on the screen is very high level simplified architecture of physical properties extraction service. And physical properties extraction trigger is also integrated with Fusion 360 workflows such as milestone creation so that it can extract and save physical properties for later usage.

All right. We will talk about how physical properties are integrated in FusionTeam. As you can see, FusionTeam is one of the second party web interfaces where user can fetch and view the physical properties for a Fusion design. For root level component, the physical properties are available in Properties tab. And for subassemblies, even the smaller parts, physical properties are available in Components tab.

We'll talk about this in this demo where I'll be able to show you how a Fusion workflow such as milestone creation triggers the physical properties extraction service trigger and it extracts the physical properties for the design.

So as you can see, this is an assembly available in Fusion 360. The V2 version is latest. And when we go to FusionTeam, you see the same version available in FusionTeam. If I go to Properties tab, as you can see, there are no properties extracted for design as well as no properties are extracted for any of the components of this design.

Now we will go to Fusion 360 and I'll just trigger a milestone creation on V2. I just created a milestone on V2 version. And the milestone creation will now trigger the physical properties extraction. Now we will go to FusionTeam and we will fetch the latest milestone. Quick refresh will fetch us the milestone. Show the milestone.

And now we go to the Components tab to see that all the properties are extracted for this particular design. You can drill down to the components level. And you will be able to see the physical properties, mass, volume, density, and area, extracted for this component. As you can see, the mass properties are extracted for all the subcomponents which are part of this design.

So as you can see, all the properties are available for subassemblies as well as root level component. To view the root level component properties, you can go to the Properties tab and the root level component properties are available over there.

Let's talk about the use cases. The physical properties can be used in use cases like sustainability where physical properties like density plays an important role in selection of the lightweight or the high strength material for aviation industry. This helps in increasing the fuel efficiency and in turn lowering the carbon footprint.

Another use case being cost analysis, where physical properties like material type, mass, total surface area along with the fabrication related data points, it can help an accurate estimation of a job's machining cost. eBOM generation. It is very important for the engineering teams to know the mass components of subassemblies to evenly distribute and achieve the desired center of mass. Also knowing the desired center of-- knowing the total area to be painted comes in handy to float the RFQs efficiently.

On the logistics side, physical properties like bounding box and mass are necessary information for a logistic partner to accurately define and packaging requirements and to efficiently plan the lot size and outbound shipments. With that, I'll hand over the slides to my colleague, Patrick. He will walk you through the GraphQL [INAUDIBLE] part.

PATRICK RAINSBERRY: All right. Thanks. So you guys saw just now how to use physical properties, how to view them, how they're computed, how they're triggered to be computed on demand. And it's one thing to be able to compute them on demand through the standard interfaces that we have, like FusionTeam and other places where you might want to interact with the actual Fusion 360 products.

But where this gets really interesting is when you want to extract this information from a third party application. So from maybe a web app that you're building as a plugin. Maybe it's just some sort of automation that you're building in your own company to integrate this information with an ERP system, et cetera. So in all these cases, you're going to want to be able to extract this data through an API.

And to do this, we're going to use the manufacturing data model API, which is built on GraphQL. And so I'm going to go through a little bit of the background on GraphQL and why we chose GraphQL and what the advantages are. And then we'll get into some of the specific usage of the manufacturing data model API.

So let's first talk about GraphQL. So if you're not familiar with GraphQL at all or maybe it's something you've just heard, it's kind of a trendy term in the industry right now. It was originally introduced way back in 2012 they started working on it. Public release in 2015. Facebook at the time, now Meta, was responsible for it.

And the point of it was to be able to get exactly the data that you want very explicitly for these kind of nested data structures where the data might be coming from different places and you want to just have a single kind of clean way to just get the information that you want for the particular view.

And so what it lets us do is when we define the query, what you use in GraphQL very much aligns with what you would see in the user interface of Fusion 360. So you have something like a project inside of a project. You have folders inside of folders. You have designs inside of a design. You have components for a given component. You have that component's children. And it just kind of maps to what you would expect to see when you look at it in the UI.

It also allows you to just specify exactly the information that you want. So rather than in a traditional kind of REST APIs where you would just make a request to get some piece of data and you just get every possible field and all of the nested possible subfields, in GraphQL you're very explicitly defined what you want and then that's what you get. So for example, I want to get just the item number for all of the components in this project or in this hub. And then that's all that will be returned.

And it really reduces the amount of complexity in your queries. It also reduces the number of maybe API calls that you have to make. Whereas if you look at this example, in the past, you would have first gotten hubs. That'd be one REST endpoint. Then projects, then a specific project. Then you might get the contents of the project and then you might get the designs. And then from the design, you get the contents of the design, et cetera, et cetera, et cetera. And you kind of usually-- REST APIs you kind of go one kind of layer at a time, whereas in GraphQL you can do it all at once.

GraphQL is very widely adopted. I would say a lot of it is where companies are sort of using it as the layer to power their own applications. But also you're starting to see more and more companies doing what we're doing where we're actually using GraphQL for our public API interface. Some other examples like Github's doing it, Shopify. There's some other big API kind of use cases out there with GraphQL as well as lots of companies using it for their own internal applications. And so now, yes, Autodesk.

So if you think about GraphQL, so I'm going to assume that you're relatively familiar with using regular REST API. You think about the CRUD operations. So Create, Read, Update, Delete. One of the things that's different about GraphQL is that there's really only two types of operations. There's query and mutation. So you're either reading data or writing data.

So a query is what you're going to use for anything that has to do with reading. And that's pretty similar. But then whether you are creating new data, updating existing data, or deleting data, those are all going to be considered different types of mutations. So you're either using a query or a mutation at any given moment.

Just in terms of the ecosystem of GraphQL, there's tons of resources out there. It's hard to just pick a few things to highlight. But there's kind of a GraphQL nonprofit sort of organization that is dedicated to just all things GraphQL and information and resources where you can just learn a lot. If you're going to really be getting into this, I highly recommend reading some of their articles on just the general usage of GraphQL. Not so much in the context of code or any specific library integration, but just the general implementations. You find a lot of that on their website, graphql.org.

Then also there you'll find all kinds of tools. You can use tools like Postman or Insomnia if you're used to using those for just making quick tests of different REST APIs. They have really good GraphQL support for just doing quick testing. But then also there's really, really good integrations into most of the popular IDEs. So whether you're using VS Code or some JetBrains, WebStorm, something like that, I cannot emphasize how important it is to get an extension.

So Apollo's GraphQL extension's perfect just because of all of the power of the syntax highlighting. One of the things about GraphQL is that the schema of the API is self discoverable. So as soon as you start using it, you just kind of tell your IDE what the endpoint of the API is, and it will just extract the whole schema. And then it'll give you all kinds of really nice code complete and syntax highlighting and code checking, query checking, and all these things. So super important step. Get the GraphQL extension for whatever IDE you use.

So let's take a look at actually what these queries look like specifically in the context of our Fusion manufacturing data model API. So earlier Ankur showed you guys the interface in FusionTeam where we can drill down into components and we can see their names and part numbers and the mass properties, maybe mass volume, et cetera. And that's what a user experiences when they use our FusionTeam web interface.

But with the power of these APIs, you can build something like this. So this is just a sample application that I've put together to just test these APIs. But the GraphQL API really lets you do everything from the hub down to the component and down to the physical properties of that component. So you can relatively easily build an interface like this that gives you similar data and similar access and similar views just by querying the APIs.

And then in this case, what we're looking at is on the left, you are looking at, say, a project. And then within a project, you have a design. Within a design, you have components. And then in the big table view in the right, we're seeing that assembly and then its subcomponents. And then you could keep drilling down into layers of subcomponents. And then for each component, we're extracting the physical properties.

And again, I wanted to reemphasize this here. So when we look at a GraphQL query, so this is using another tool that you can find on the GraphQL website called GraphiQL. And it's just a nice little quick tool for just writing GraphQL queries and testing them against some endpoint.

And so on the left, you will see I've got a query that says I'm going to get some information about a particular component version. And then we'll pass in the ID of that particular component. And then we're going to get its name. And then we will get model occurrences, basically its children. And then for each of those occurrences, we'll get the associated component and the name of that component. So just kind of like one layer of the assembly.

And so when you look at this, you would run the query and you can see the results here on the right. And you see you have the top level steering wheel assembly and then you have its children. So you have the base and steering base and the PCB and the horn battery, et cetera.

And one of the things that just is really nice about, again, working with GraphQL and the way that the object model is defined is that you see that the results of the query just very much match what you expect to see in the browser. A similar API with REST, it would probably be something like for a component get an array of its children, which would probably just be a bunch of IDs. And then for all those IDs, you would go fetch the information for those components. And you'd be responsible for reassembling that in your client. And here we can just very explicitly define what pieces of data we want and it matches to what you expect if you were used to using Fusion itself.

So let's take a look at some queries in more detail. So I'm going to go to just a very, very generic top level query, because I think it's really simple to wrap your head around. So we'll say that I want to get a listing of just all of the projects that are in this hub.

And so similar to the way you would work with a REST resource based API, you still are going to say, given some item that I know the ID of, I want some information. So let's say I have a user has maybe picked a hub from a list. Now you have a reference to the hub ID of interest. And now you want to display all of the projects within that hub.

The query on the left is really-- that's it. That's the whole query. You just would say in the subspace of navigation and then we'll say we want to get a hub by its ID. And then we want to return the name of that hub and then we want to return all the projects and the name of those projects.

And you see that one of the things that's kind of cool about the way that GraphQL syntax works is that projects, for example, is an array. And we don't really have to deal with that in the query itself. We're just going to say projects is an array that has a return type with results. And then results will have all of the projects. And so then what we're saying is that in the results for each item, we just want the name.

So in every kind of substep, whenever the schema would show you that it's going to return an array, it's almost like there's this implicit for each, if you will. And so it's basically saying for each project, give me the name. And it's really clear when you look at what the results object looks like, you see I've got the results are always returned to you in the exact same structure from the left. So you see it's nav, hub, the name of the hub, projects results, which is the array, and then it's now an array of objects, and for each of those objects, the only field that I've asked for is name. And so you see the names broken out here.

If you break this down, which I think is good to think about just in terms of the structure, this is also one of the reasons why it's kind of nice to have a plugin for your IDE. The query itself is considered a GraphQL document. That's what a query is. And it's usually use this syntax GQL when you're defining it in your code.

But basically if you're using one of these client side libraries, like say the Apollo client library, rather than just using generic fetch, you could do it with a generic fetch, but it's much easier if you're using one of these client side libraries as well. You will basically have just a string, big string that is the query itself in GQL format, and then separate variables, which would be typically just JSON or JavaScript Object. And then the response will also be JSON. So you can just decode the JSON into a JavaScript object as well.

And what's really nice is that when you start building your applications, you'll see that you define-- you have a certain set of queries that are common. So I just have the generic projects and hubs. But every time you-- which will be kind of fixed and that you'll reference. And then every time you're using it, you're just going to change what variables it's being called with. And there's a bunch of implications on how the data is cached with some of these client libraries that's beyond the scope of this presentation. But as you get into it, you'll see the beauty of this three piece puzzle that they have here.

So if the query that you were calling all of a sudden the ID of the hub that changes, then it knows it needs to refresh the local data, et cetera. It makes it very easy to-- it makes it very powerful to integrate with things like react where it's all sort of state based and you need to know when things are changing. We want to react, et cetera. But again, a little bit beyond the scope of this class.

So let's look at very specifically physical properties, which is the scope of this class. So this is what the GraphQL query would look like. We want to access the physical properties so we can get, like we mentioned before, mass, volume, density, surface area, bounding box for a given component. And so here's the query on the left. And we're going to call this just the component version query.

And then here you see where previously we were in the nav subspace, we're now in the MFG subspace. And we'll say we want to get the component version by its ID. So you've got component version by component version ID. And you would, again, pass in the variable for component version ID. And then we're going to have it return ID name, part number, description, material name, and then of course, most interestingly is the physical properties.

And for physical properties, each of these mass, volume, density, et cetera are all kind of named items in the physical properties object. So it's not something like where you would have an array of just all properties that are actually each one is named. And then so you'd say for the mass, I want the value.

And then you'll see this notation here, property definition, which is what I really kind of wanted to dig into just a little bit here. So physical properties is sort of the first place that you're going to see this in the manufacturing data model. But as we expose more and more data from within the file through GraphQL, we wanted to keep things very common. So you have these very common types. And so one of these types is a property definition.

And so regardless of whether it's mass or volume or it could be in the future things like dimensions or whatever other parameters and properties we put into the system, there will always be this notion of a property definition. And this is what's going to say what is the name of the property? What are the units of the property? In the future, there might be other things like UI indicators like is this hidden? Is it read only? Is it editable? What is the expected behavior of the property? Does it update on milestones? Who knows? All these other behaviors and things that are common.

So regardless of which component you're looking at, the property definition for mass, that schema of a mass property definition is always the same. Volume is always the same. And this way you can see the units and everything. So it might look a little complex. But as you start to think about the scale of all the different types of data that we want to put in here, this one common unit of property definition is what makes it really clean so you know that regardless of whether you're reading a string or a float or an integer or a Boolean, you're always going to have this thing called property definition.

And that's going to essentially tell you what is the type, what is the name, if it's got units, et cetera. And then that is what's going to tell you. So you're basically in your client code, you can use that to react to how that value should be displayed or whatever other information you're trying to glean from the definition of the property itself.

So that was a little long winded, but here is the result. And so this is what it looks like when you actually execute the query. So again, you would through whatever mechanism and client code or through some Postman or whatever it is, you would write that query on the left. You'd feed the variable for the ID in. And then this is what the response would look like. So you can see, again, that one to one mapping where you have the fields defined on the left and then all the values defined on the right.

And you can see all this information and we can see, for example, the mass to a ridiculous precision apparently. And then we can, importantly here, is to see that the name of the property is mass and it has units of kilograms. We have another one where the name of the property is volume and its units are cubic centimeters.

So I wanted to talk about a couple of just quick just tips, I guess you'd say, best practices, things to consider and think about. This is by no means a comprehensive overview of using GraphQL in a client and all of the other things that come along with that. There's so much to learn. You'll find that it's so powerful, it's hard to get it all into a short class. But this is one that I really wanted to emphasize, because I think it's something that you could get a little overambitious, I think.

So with GraphQL, one of the things about GraphQL is that you can define a query to as much complexity as you want. So it's very powerful in that way. But as Peter Parker says, with great power comes what? Great responsibility. So very specifically I'm telling you do not do this. Do not run the query that I have on the left.

If you look at what that query represents, it says for all hubs, for all of my hubs, give me all of the projects in all of the hubs, then all of the folders and all of the projects, then all of the designs in all of the folders, then all of the root components in all of the designs, then all of the children of all of the root components. Give me the physical properties. So you're basically in one query you're essentially asking for the mass and volume of every single component in every single design in every single hub that you're a member of.

And don't do that. You will not be able to write a client that can respond to that kind of timing. You really need to think about is what are the boundaries of what makes sense to separate the queries? I'll tell you right now that you're not going to get a result for this. It's going to time out. We're going to reject it as soon as it sees how complex it is. There's a timeout limit of something like 30 seconds, 60 seconds. And in this case, the amount of data that you're asking for is completely unreasonable.

And so you really want to think about what is the context that you're really trying to display. So in the case if you were trying to display the information for in that table of all the children. You might be saying, OK, well given a root component, I want to get its children and their mass properties. Or if you were trying to display maybe just the root components of a bunch of designs within a folder and they're just the rolled up mass properties. Maybe it's something like that.

But you don't want to try to do-- just you don't want to do is you don't want to try to over fetch. In the beginning is just to think about what's the context and then just get the data you need and rely on the fact that, again, if you're using some good client libraries, the local cache will continue to update. And once a particular piece of data has been fetched once, it won't need to re-fetch it from the server.

And so just thinking about what the appropriate boundaries are and not letting these things get so out of control. It's better to segment them into layers. And one of the ways that you can think about doing that is really as soon as you get to a break point where you have some level of pagination, that's a good indicator that you should break the query there.

So another thing I wanted to talk about real quick is just the fact that this is kind of an asynchronous process. So it's very much likely that you might be requesting data for a given assembly that has never been computed before. Maybe it's not a milestone. Maybe it just has never been-- no one's ever asked for this particular level of components because you figure every level of the assembly depends on all of the children below it to compute its mass properties.

So if you think about this just more generically, you think about a traditional kind of REST API workflow when you're dealing with some kind of essentially-- Ankur showed you our system diagram earlier. If you think about the way you would typically interact with some kind of a job processing, compute something in the cloud for me type of an API with a REST API, it would probably look something like this. And if you've used some of the other APS APIs like Model Derivative API, then this format on the left would be familiar to you.

So you would typically do something like I know that I want the physical properties. I'm not saying that this is how it works. But I want some piece of data. I would have a POST request where I would submit a job based on the ID of whatever it is I'm interested in. Maybe it's the root component of the assembly. And then I would get back something like a job ID. And then I would hit a different endpoint to check the status of that job. And then once I see that the status is complete, then I would go to step three and I would probably have some other endpoint that says for this job now give me the results object for whatever piece of processing asked for.

And that's fine. It's just it means that in your client code, obviously you have this kind of step wise function in the client code itself. It's kind of hard to wrap that sometimes. It gets a little tricky when you're trying to actually implement that in a client. Know you're using these use effects or something like that. So if there is a job ID, if there is a status of done, et cetera. And then you kind of make a different call and now that data is what's feeding whatever maybe UI component that you're displaying.

And with GraphQL, there's a number of places where we're using this kind of notion of asynchronous call it asynchronous read operations almost. So if your physical properties, thumbnails is another example, if you're exporting BREP data into something like step or STL, it's also a similar workflow. And so what you do is just like the queries that I showed you before where you have that for a component version, give me the physical properties.

You only ever just make that one query. So if you're managing the state of your application based on the results of that query, you're always just using the one query. So you're going to say, give me the physical properties. And if they have not yet been computed, you immediately will get a response, but mass, volume, et cetera will just be null because they haven't been computed. And there's a status in there that will say in progress.

And then basically, the way a lot of these client libraries work is you can set a polling interval on the query itself and it will just refresh the data that's being displayed in the particular react component. And so you're just going to make the query. And then if the response has a status of in progress, you just basically start refreshing that query and just keep repolling until you see that the status is complete.

And at that point, it just means that then the data will be filled in. So when you see a status of complete, you will also see the mass and the volume and everything else. So that's one of the things I think it's really powerful in GraphQL is that-- or in the way that we've implemented some of these asynchronous workflows is it makes it really easy to deal with on the client side because you're only ever making the same query.

And if you don't have results yet, you can show a spinner or whatever you want. And when there are results, then you would show the result, like in a table or something. And so yeah, that's very nice. And so I think it's good to just have a good mental model of how that asynchronous behavior is working.

So you could see here this is an example of what that really would look like. So you can see, again, there's just the one query. I'm just going to get the mass and the values of the mass and volume just to keep it really concise. So for this component, when we make the request the very first time, you'll see in the response the status is in progress and the mass null volume null. What that means is that process that Ankur showed earlier, excuse me, that process that he showed earlier, our back end processing pipeline has basically kicked in.

So now the data is being extracted. It's being computed on demand given the current state of the data in that file in that design. And you could essentially begin polling with just basically just saying refresh the query. But I'm still using the results of that query in my front end application. And then a few seconds later, maybe 10, 20, 30 seconds later, all of a sudden there is values for mass and volume and the status will be complete. And then you would just set the polling time to be 0. No more polling. And you're happy and the client-- I would assume that your UI reacts to that and refreshes the display.

So that is mostly what we wanted to cover here in this session. I'm just going to make a couple of quick references to some documentation. So there's quite a bit of documentation on the APS website. You can go and you can get a lot of specific information about actually using the API.

The overview documentation I recommend reading thoroughly just to get a sense of how it all comes together. And then depending on the type of data you want, there's a lot of step by step tutorials that will walk you through the workflow, which is good, I think, when you're first starting. And then once you're more familiar with it, at the bottom of this page, there's just the standard object model documentation.

But again, I'm going to go back to the idea that if you have a good IDE plugin for GraphQL, you basically never even have to go to this site because GraphQL is, as you would see, is it's self documenting, basically. So once you're in the IDE and you're just hovering over any of these objects, you're just going to see the documentation floating in front of you, which is very nice.

Then also on the APS website if you were just looking for more benefits, use cases, customer success stories, you want a little bit more information about what we're doing, where we're going, there's a roadmap there. Just learning about more of the value and why you'd want to use these APIs. You can check that out on the solution overview page as well.

Once you get in there, you'll see we've got some pretty nice tools for creating or for exploring these APIs. There's what we call the GraphQL Explorer where you can try the APIs out in an interactive sandbox playground. There's also this tool that's implemented in there called Voyager that allows you to visualize the schema.

So this is just an example of using that playground or sandbox where you have the query on the left and then you're just able to quickly make live requests. And you can just kind of play around with the schema on the left. Maybe you want to say, in this case, you're going to just extract an ID and then you can change the query and paste it in. Now we'll look at the information for that particular project ID and then we can look at, again, we can look at, say, the folder ID, et cetera, and start digging around. So maybe go back, get this project ID, and keep querying.

And actually what you're seeing there, what's embedded is that same tool I had referenced earlier, which is GraphiQL, which is just this open source tool that's really easy to embed. This is the Voyager interface. So it's a little overwhelming. It's kind of crazy. But once you're more familiar with the API and you really want to understand some of the dependencies and structures, because you will have, say, a folder returns designs and designs have root components and then there's all of these different-- in GraphQL it's just very much object structure.

And so you can see where lots of fields in different objects will reference return types of other objects. And Voyager lets you see this whole crazy map. So that's another really nice tool if you want to really dig in and understand those dependencies.

And so with that, thank you very much on behalf of Ankur and myself and Autodesk. That is the end of our presentation. I hope that you enjoy the rest of the classes at AU. And thanks for sticking with us.