When you get to read this, I will be sitting in a plane at 30'000 feet over the middle of the Atlantic Ocean... or somewhere over Greenland, whatever.
Thursday was the third and last day of Autodesk University.
I went out for a quick beer with some of my ex-Autodesk-colleagues from decades ago on Wednesday evening, and a very nice time was had by all.
It turned out to be not quite so quick, however, and not just one beer, and I woke up next morning suffering dire consequences.
I would strongly sustain that they were due to the fact that the brews I sampled to not adhere to the strict and sensible purity rules. I would never have expected such a huge difference in after effects.
Luckily, though, I did wake up, initially thinking that my cloud-based round-trip 2D Revit model editing class would be later in the day. Even more luckily, I decided to switch on the computer and look at the schedule.
Imagine my shock to discover that it was scheduled for 8:00 am.
Anyway, I made it, and everything went really well, and now I am sitting at the airport and the plane is delayed.
These are my main activities of the day:
I presented my class DV1736 – Cloud-Based, Real-Time, Round-Trip, 2D Revit Model Editing on Any Mobile Device.
This is the second time I present my super simple solution open source based solution for this task.
The first was at the Autodesk internal Tech Summit in June (overview, 30-minute pre-recorded video and live recording).
This time around, I had 90 minutes – instead of 30 – to discuss the topic in much more completeness and detail, which felt very good.
Here is the class handout and slide deck.
A recording will come later, once the AU technical staff have completed and made it available.
During the Revit API roundtable on Wednesday, I finally realised what I should have been doing all along instead of fiddling with the Idling event.
I wish someone else would have noticed, thought of this, told me much earlier, and we would not all have had to wait until I finally thought of it myself.
This planet sure can feel like a lonely place sometimes.
Anyway, I now realised that I can significantly reduce the overhead and sluggishness of the Idling event by using an external event instead that I define myself.
An external event would allow me to vary the number of checks I make per second freely, relinquishing control in between, and only bother Revit when there really is something for it to do, i.e. a pending database update to be integrated into the BIM.
I can't wait to implement and test this!
At the last moment before leaving for the return flight, I discovered the class by Stephane Negri, Software Development Manager, Autodesk, RC3176 – Put Your Mind at REST: Extend Your Application to Reality Capture:
The reality capture group at Autodesk is working on ways to acquire, manipulate, or analyse real scene data using laser scans or photos through Autodesk ReCap products. While several AU classes demonstrate ReCap use and workflows associated with these products, this class focuses on how to programmatically access the reality capture web API to create or extend an application. We start with a quick overview of basic photogrammetry concepts and image parameters, then approach the reality capture REST API and discuss how to define a photo scene from multiple photos and create a dense 3D mesh, also covering some of the advanced features that are available to customize and refine the process. The class concludes with a complete example written in PHP.
I already mentioned this topic in my overview of the cloud & mobile platform web service APIs provided during the ADN DevDay conference on Monday.
Here are my notes from Stephane's class, with absolutely no guarantee for correctness:
Autodesk offers several different browser-based user interfaces for different reality capture scenarios.
They all use the same underlying ReCap REST API.
You need a special developer key to make use of the API. To obtain one, please contact ADN and ask to become a pilot partner.
Stephane presented a manual demo to clarify the user interface, available functionality and usage workflow.
You sign in with the standard Autodesk single sign-in.
The project gallery presents impressive examples of the kind of models that can be achieved.
He created a new project using only three photos.
Very simple workflow: create a new project, upload photos, wait and retrieve the result.
Photos must be of high quality, good lighting and equipment and overlapping, e.g. with each point visible in at least three pictures.
Quality is more important than quantity.
ReCap is built on Amazon web services, using queues to manage jobs.
The basic API workflow matches the manual approach: create photoscene, upload files, progress check, retrieve results.
Authentication using Oxygen, and Autodesk service based on OAuth 1.0, a three-legged authentication based on HTTP header data.
Documentation is public and embedded in the service, generated by the Swagger framework for describing, producing, consuming, and visualizing RESTful web services.
You can easily try out the UI workflow via the API using manual REST calls.
The results of each REST call are returned in either JSON or XML.
For more information, please contact firstname.lastname@example.org.
Stephane also presented some of the current pilot partners and their work, some of which was also being shown in the AU exhibition:
Tilo Pfliegner of Kubit demonstrated easy integration of calibrated photos, point clouds and ReCap models into AutoCAD.
Point clouds are sometimes too imprecise for modelling needs. Using photos directly instead is better, because they are often more precise, and the photo quality is often better than the generated point cloud. He listed the following applications:
Chris Bumgardner of SkyCatch presented their Recap API integration for fully autonomous unmanned flying vehicles.
A typical use case might be the generation of daily 3D models for construction customers.
You can use a viewer such as Sketchfab to view the resulting OBJ model. Sketchfab is a web service to publish and display interactive 3D models. No plugin required: upload your model, embed it, share it, done.
This makes it extremely easy to embed the resulting model into web browser, for example.
Again, high quality images are more important than quantity, e.g., four images may be perfectly sufficient.
Use high-resolution images. The resulting accuracy may reach down to one single pixel level. Go closer if you use low resolution.
How to scale the resulting model properly to the real world? You can use a template file, have known camera positions, set GPS coordinates, measure the real-world sample, etc.
GoPro has a fisheye distortion; switch it off with
StitchingCreateInputFile = 1.
The Exif data within each image tells you the source of it, e.g. to recognize GoPro images.
You don't have to add any marker points, just make sure the surfaces are not too bland and uniform.
Many thanks to Stephane, Tilo and Chris for the interesting presentation.