AngelHack Athens, Sustainability and Precision versus Tolerance

AngelHack Athens is in full swing, Autodesk has committed to 100% sustainability, Scott Conover explains some Revit export precision and tolerance aspects, and I am leaving on vacation next week:

AngelHack Athens Hackathon

We held the second I love 3D – Athens meetup yesterday with 19 interested and enthusiastic participants:

Angel workshop Athens

I posted the full details and links to all the important View and Data API resources in The 3D Web Coder discussion on the Angel Workshop I♥3D.

Now we are getting started with the AngelHack hackathon:

AngelHack Athens Hackathon

Check out my new AngelHack Athens Hackathon album featuring a 360 view of Athens from the hotel roof, the participants and lots of cool street art in the immediate vicinity of The Cube:

Face and a bird spread across several pillars

Autodesk Commits to 100% Renewable Energy

I am happy to announce that Autodesk has made the commitment to power its business with 100% renewables:

Autodesk renewable

At the same time, we released the 7th sustainability report.

Revit Export Precision and Tolerance

Back to the Revit API and an important question that recently came up on the precision of the face edge curves generated by exporting a Revit model.

This has been discussed several times in the past, e.g. in this explanation of gaps in shells and the TessellateSolidOrShell method.

Here a couple of important general aspects of this issue brought to you by Scott Conover, Revit API Software Development Manager, and the Protractors Revit product development team:

Question: I am having problems with gaps in the geometry returned by the Revit export.

Any application which wants to read the B-Rep information from Revit for their downstream use cases will have this issue of geometry and topology mismatch.

Answer: As discussed previously, this is working as designed for Revit.

Edge curves are derived from the coordinates and parameterization on the associated surface, and thus are an approximation from the original analytic geometry.

The group that works with Revit geometry is wondering how this is causing a downstream impact of significance to your application. You mentioned 3D visualization issues. They are also wondering about the tolerances expected of the application, because in reality most 3D data you encounter will always have small discrepancies. Your application must always be enabled to gracefully handle these. For instance, the approximation of an ellipse by a Hermite spline should result in a small discrepancy, e.g., a difference of 0.01% or so for the area contained within similar curves.

You say that 'this impact will not be limited to our use case, but to any application who wants to make use of Revit B-rep information for their downstream analysis purpose'; that is only true of applications that either use a finer 3D tolerance than Revit, or that use no tolerance at all. You don’t say which category your application belongs to, but the repeated use of the word 'exact' makes me think that you might not be using any tolerances, or an excessively small tolerance, such as Revit’s DOUBLE_EPS = 1.-e-9. If that’s the case, you will not be able to handle much realistic data, and you will need to improve your application to do so.

Is the issue related to tolerancing of the downstream application? What tolerances does it expect?

There is no one-size-fits-all recommendation to the kind of questions, or how to handle export. There are many flavours of export, e.g., 3D BRep, 3D faceted, recipe-based, 2D raster, 2D vector, and more. Also, because Revit can represent the entire building design across multiple disciplines, an export may or may not include all of the elements, and an export for something like MEP systems might be very different from structural export for analysis and from the visual appearance of an architectural model.

I really only have two recommendations for understanding how to make a reasonable export from Revit:

  1. Use the IExportContext for 3D export so you don’t have to wade through the 35 different ways an element can be hidden in determining what to export.
  2. Look at the IFC export open source. A lot of effort has gone into that to make it robust and useful, and it currently incorporates examples of 3D faceted and recipe-based export for some types. In IFC4 there is a BRep representation as well so I imagine that will also make an appearance in the future. Note that this contradicts #1, as it doesn’t use IExportContext. This is because the API-based export predates the context and thus there is some logic to handle visible elements or to export the 'whole' 3D model.

Many thanks to Scott and the Protractors team for their helpful overview and recommendations!

Vacation Time

The best news comes last, and is brief:

I am leaving Greece now to fly home and take a week of vacation time in the beautiful Swiss Emmental region.

Yay!

Have fun, and take care!