As mentioned last week, I’ve been having fun with Fusion 360 to prepare a model to be displayed in the new Autodesk 360 viewer. The sample is now ready to view, although I’m not yet quite ready to post the code directly here, mainly because the API isn’t yet publicly usable.
Here’s the app for you to take for a spin, as it were.
The Autodesk 360 Viewing & Data API is currently being piloted by a few key partners, and hopefully we’ll soon be broadening the scope to allow others to get involved (we first have to iron out any issues that might impact scalability, of course).
But let me give you a few pointers about what I did and what to expect when developing your own web applications that connect with this technology.
Firstly, as a classic set of web-services that require authentication, there’s a need to request and provide an authentication token. You do this by calling a particular web-service API with your client ID and secret: standard authentication stuff. But this means you’re going to need some kind of server-resident code to get a token: it’s a really bad idea to embed your client ID & secret in client-side HTML or JavaScript.
To implement a server-side API, I’ve used Node.js. It’s the first time I’ve done so, but it was really easy to do (and I’d been meaning to give it a try).
For my hosting infrastructure, I went with Heroku (thanks, Cameron!). This is a lightweight, scalable hosting environment that has some really cool integrations: you host your code on GitHub and deploy directly from there to your Heroku instance via the command-line. Integrating Node.js and NewRelic (for application monitoring) took just a few commands and minor code changes. It was really easy to do.
Heroku provides a basic level of usage per application for free – 750 CPU hours annually, I believe. I’m running this app right now on a single instance – it’s really only performing authentication and serving up static HTML, the heavy lifting is done via the code hosted on AWS that feeds data to the connected viewer – but I can scale this up according to usage. It will be interesting to see how the site gets used: NewRelic will provide me with that level of detail, I hope.
I found the Steampunk HTML UI for the sample on this page, making heavy use of CSS transforms. I contacted the author, Dan Wellman, who very generously provided the PSD file he’d used to generate the various web assets. Which meant I didn’t have to tweak the generated files, I could use PhotoShop directly to re-generate my own assets with the required changes. This was really nice of you, Dan – thanks for the kindness!
We’ll take a look at the code in more detail in a future post, as well as the steps to get the model accessible from the embedded viewer. (A quick outline: you need to upload the file – in my case a .F3D archive exported from Fusion 360 – and then fire off a translation request, all using an authorization token generated using your client data, allowing an app using the same client data to access it in future. All this can be done using cURL at the command-line – if doing a one-off translation as I have done – or programmatically if you need something more dynamic.)
In terms of my use of the Viewer API: I had hoped to use component isolation to highlight different parts of the model, but as the original model was imported from Alias with a very flat component hierarchy (with tens of thousands of bodies), there was basically no hope of me doing this without a large team of modelling specialists at my disposal. So I opted for swapping the view when the various buttons are clicked, instead. Which actually works reasonably well, so I’m happy sticking with with this approach, for now.
