Some months ago, I felt a disturbance in the force: a lot of people were talking about exporting Revit data (3D, materials, PBR textures, product structure and metadata) to 3D engines files formats or to their own file format.
It was at this time I decided to have a look at the Revit API and make a prototype using my own file format to be tested (successfully) in Unity. A few weeks later, a client asked me to write a Revit plugin.
Here are some interesting things I've learned in the process.
1 Simple plugin setup
Adding a plugin in Revit essentially consists in 2 files:
A plugin description file (.addin)
A Dll plugin
It was very pleasant to see that Autodesk did not invent a crazy way to add a plugin in Revit and it reminded me of the plugin setup I had already seen creating a Siemens NX plugin, for example.
One of the great thing working with software publishers like Autodesk is that a plugin creation process is very well documented. Furthermore, the Revit community is very active on the dedicated forum and Autodesk provided a LOT of code samples.
2 Very intuitive export interface: IModelExportContext
For this 3D data export plugin, the IModelExportContext is the central interface where the magic happens.
I "just" had to implement its methods to receive data from Revit. The fact that the received data tessellation level matches the current Revit tessellation settings is great. The original non-tesselated geometry can also be retrieved.
3 Debugging: Edit and continue at its best
The Autodesk Revit team has also made everything to take advantage of Edit and continue debugging. However, the Edit and continue feature does not work (rebuild needed) when adding public or protected methods (among other changes), so make sure to write empty methods and functions first and then fill them out.
I also used another trick a lot: if returning true in bool IExportContext::IsCanceled() the export process is, well, cancelled. I used a private member variable for debugging, and at any point of the debugging process, whenever, I wanted to check something, when done, I just had to set this member to true in a Visual Studio watch window to come back to Revit, interupting the export process gracefully.
4 Materials: This is where the fun begins
While evaluating the work to be done for creating this plugin, I had the feeling that material export would not be trivial. And it was not.
The more I read about materials in Revit, the more I had these 2 sentences in mind:
I had to put some effort in understanding how Revit handled materials and their appearance (in Revit UI, for rendering and thus which material setting to export).
This resource has been really helpful.
During the materials export test phase of the project, I spent quite a long time making sure that all types/schema of materials appearances were supported by the plugin for both "legacy" and the new Revit 2019 PBR materials. May be here, Revit could provide a .rvt sample file containing all the standard materials library materials.
The asset property representation of material is not intuitive but I just got used to it, even if properties are not very well documented.
Getting the right UV offsets and scales parameters was not very intuitive at first but not impossible.
I also realized that the way the mapping is done in Revit is very intuitive for AEC folks, especially using RealWorldOffset and RealWorldScale texture settings.
In conclusion, I had a lot of fun creating this plugin especially because, Revit is a very good piece of software and the API folks are very dedicated to help developers getting a good grip on the API. Thank you guys.
