Autodesk Research

  • It's been a great few days in Rome, at the Forge team's first ever Roman accelerator. Things kicked off on Monday morning, as we occupied the conference room at Rimond's office in Rome's Trastevere district. As is usual at these events, there are a number of companies doing really interesting things: several of them have specifically mentioned Dasher 360 as their inspiration for visualizing additional (even IoT) data in the Forge viewer. Very cool. Yesterday I joined Peter Schlipf to visit Roma Tre University, where we spent some time with Stefano Converso from the Architectural Design department, as well as…

  • I spent the latter half of last week at ETH Zurich, attending a conference entitled "Robotic Fabrication in Architecture, Art and Design 2018", or Rob|Arch 2018 for short. This is the biennial conference where luminaries in the AEC industry get together and plot how robots will replace millions of construction jobs over the years to come. Not really, of course: the big thrust of this conference is to work out how robotic fabrication technology might (or must) be applied to meet the housing needs of a planet whose population is expected to increase by nearly 30% over the coming 30…

  • The integration of the MeshLine library into the Forge viewer – which we're using for the display of skeleton data, as we saw last time – has opened the door to displaying all kinds of other cool stuff. Back in 2014 colleagues in Autodesk Research published a SimAUD paper entitled "Towards Visualization of Simulated Occupants and their Interactions with Buildings at Multiple Time Scales". It explored the use of various visualization techniques to display how a building's simulated occupants interact with it. One of these techniques was called Speedlines (we also use the term Streamline): The original visualizations were created…

  • Right then… now it's time for the really fun stuff. Looking back over this series of posts, we introduced it then looked at adding simple geometry to the Forge viewer, followed by animated skeletons and animated skeletons with fixed meshes attached. Today we'll dig into making our animated skeletons properly visible. Having given up on using a SkinnedMesh, the remaining option was to tweak the underlying display of the SkeletonHelper object. This proved challenging for all sorts of reasons. Back in Chrome 55, it seems the ability to show lines with widths broke in three.js. This was fixed in three.js…

  • We introduced the series, then looked at adding simple geometry to the Forge viewer, followed by animated skeletons. Now it's time to look at approaches for making these skeletons more visible. As mentioned last time, today's post is a bit of a "non-post": it talks about adding a SkinnedMesh to be animated alongside an underlying skeleton, which we already know doesn't currently work inside the Forge viewer. But it's instructive to see the process in case either the situation changes or someone wants the code for a pure three.js application. Basically it's possible to add a SkinnedMesh into a render…

  • After introducing the series and seeing how we can add simple vertex and edge geometry to a scene, today we're going to start digging into the guts of the problem of how to display skeletons in the Forge viewer. This proved to be a really interesting process: I ended up learning a lot about how the Forge viewer and the three.js library it uses both work. I don't recall the full history of the Forge viewer's use of three.js, but recent releases have all depended on r71. This can present challenges, largely because three.js is (at the time of writing)…

  • In the last post I introduced the series where I'll be talking about the journey I've been going through to add skeletion data inside Dasher 360 (which is, of course, based on the Forge viewer). The first step I took along this path was to find a way to add simple 3D geometry into an existing scene inside the viewer. This is something we do in a limited way inside Dasher – we use point clouds to represent the locations of sensors, for instance – but I wanted to work out the right approach for doing this for data that…

  • It's been a strange few days. It's the very last week anyone will be working from Autodesk's Neuchatel office. This really hit home when the Autodesk name and logo were removed from the building, last Friday. Photo credit: Estelle Ormrod I salvaged an A (the were signs on the front and back of the building, so this wasn't the only one) for my daughter's bedroom. It'll be some kind of reminder of the wonderful years we've all spent here. The staff departures have been staggered, over the last 6 months or so: there have been leaving aperos for people on…

  • Last month Fast Company published an article about an interesting project Autodesk Research has been working on for a number of years: internally the project was known as LEGOBot, but now that it's being talked about publicly it has understandably been renamed to BrickBot. BrickBot is a really cool project that's built on two core ideas: robots are stupid and engineering is expensive. Robots need a lot of help to be told what to do, but telling them what to do is neither straightforward (today) nor flexible: you need to code for specific conditions, and if those conditions change you…

  • One of the highlights of last weekend's AEC Hackathon in Berlin was getting to meet Michael and Keith from the Dynamo team. They'd delivered a pre-event workshop on the Friday and stayed on to tutor the many Dynamo-centric teams participating in the weekend's Hackathon. On afternoon on Saturday Keith and Michael presented an additional session that briefly mentioned Refinery (the optimization engine for Dynamo that's currently in Beta) but focused mainly on the API infrastructure that enabled its integration into Dynamo: the View Extension API. It was really helpful for me to see how it's possible to extend Dynamo with…