A birthday celebration, a forward-looking statement or two and observations on geometry, AI and emissions:
We celebrated The Building Coder's 15th birthday yesterday, August 22.
It has soon passed its puberty now and is almost a full grown-up blog now, preparing to stand on its own legs. And, in case you didn't know, this is blog post number 2005. We silently crossed into the third millennium in July.
On LinkedIn: and BIM Experts:
Thank you all and the entire Revit add-in developer community for your appreciation and support!
A number of questions were raised in the Revit API discussion forum on Revit API support for .NET Core, e.g.:
More significantly, we have a Revit Idea Station wishlist item for .NET version 6 that has now been accepted:
Sol Amour has covered most of what can be said on this topic in his overview of Dynamo upgrading to .NET 6.
Madhukar Moogala and Kean Walmsley have already published some information about the situation in AutoCAD and Civil3D:
AutoCAD and Civil3D have published preview versions with .NET Core 6 support for developers to explore. However, it is by no means clear yet which version of .NET Core will be targeted by their next major releases. Microsoft may release .NET Core 8 in November.
So, as you can imagine, we will probably be facing a similar transition in the Revit API as well. The situation for Revit is complicated by dependencies, addons, and other components and relationships to consider. The development team is still working out the details.
So, basically, all we can say about this at the moment is that we are working on it, and it remains a moving target.
Please keep your eyes peeled for the Revit preview releases. There is no guarantee yet by when the internal dependencies will have settled enough to include a version of the Revit API supporting .NET Core in a Revit preview release. It may take until the end of the year.
What can I do right now?
Above all, if you are interested in this topic, please ensure that you have joined the Revit feedback community and have access to the upcoming preview releases for evaluation. Then, you can also participate in the feedback forum discussions. Familiarise yourself with the Revit feedback portal now. Then you will be ready to jump in and actively join the fray as soon as possible.
In the course of revamping the Revit API, the development team also took a look at the macro environment. Support for .NET Core will obviously affect that as well. Last year, they asked for feedback from the add-in developer community on how you use Revit macros and shared back the results.
As a result of this and other usage analysis, the current plan is to drop support for document macros. Converting a document macro to an application macro is easy, and I hope to share some simple instructions on that anon.
Moving on from plans and speculations about what the future might bring, Richard RPThomas108 Thomas shared some valuable hints and examples of polygon area algorithms answering a question on how to obtain the area of a wall opening:
Question: How can I calculate the area of a wall opening? I cannot delete any object.
Answer: You can delete an object temporarily inside a transaction that is never committed, so the changes are never stored in the database:
Response: I cannot delete elements, even transitory.
Answer: Here is a possible solution, except for ruled faces (for ruled faces, there must be a mathematical approximation similar to below):
Generally, for other types of faces you can find the inner loops of the face and use Edge.GetCurveUV to create a loop in the dimensions of the face parameters.
Unfortunately, there is no tessellate for CurveUV, but you can evaluate points along the loop to get a set of ordered UVs.
Each U and V can then be multiplied based on how the face is parameterised in that direction, i.e., for a planar face, it 1 in both directions, but for a cylindrical face the U is based on angles, so, instead you have to multiply it based on radius to get the segment length (V is still in length, so you can use 1 for that).
Prior to the existence of CurveUV, you would likely have had to have used Edge.EvaluateOnFace to create the tessellated points.
Once you've multiplied the UV's, you can create a polygon and use the shoelace formula etc. to find the area of the polygon and so the surface area of the opening.
It is hard for faces with normalised parametrisation (such as ruled faces), because the multiple used to convert normalised to raw in one direction changes along the other direction.
For example, if you have a ruled surface between two lines of different length, one at the base (Vmin) and one at the top (Vmax), the length varies from base to top, so how you convert U to raw parameter isn't constant, but varies according to the height of V where U is being measured.
How we measure openings in surfaces can also be a bit subjective to a degree. If you have a cylindrical wall, then the area for the same opening on the outer face will be larger than the inner, but neither, I suspect, will likely be the thing that is useful to an MEP engineer. I assume they would likely want the projected (flat opening area). For this, you would probably have to take the worst case (inner area) and project it onto a plane to establish what can fit into that 2D area (or how much ventilation you have).
Another method I used in the past for 2D is to tesselate the perimeter and fill the opening with a grid of points, then use Delaunay triangulation etc., adding up the sum area of resulting triangles. The area is always slightly underestimated for concave edges and slightly overestimated for convex edges. Using smaller triangles obviously improves that but also increases processing time.
Another option is to create a single faced solid over the opening with one of the shape builders. Some surface types are not supported by all shape builders, however.
You can then extract the surface area of those.
I think walls are quite simple compared to floors. In shaped floors, especially, you don't always get inner loops. For example, in the below there are no inner loops. The thing you do know however is that the actual outline edges always have vertical faces adjacent. Therefore, fold edges always contain two horizontal or quasi-horizontal faces. So, by elimination of those that way, you are left with the outline edge curves and it is then just a case of ordering them into loops and determining if they are outer or inner. You can't rely on direction of curve for that because in reality they are all outer edges to their face.
So, there isn't a universal solution to these things.
Many thanks to Richard for sharing his thoughts and extensive experience on this!
Let me briefly point out two AI-related news items that I found interesting:
For a lengthier discussion on how ML can be used or misused, check out the several hundred comments on Allie K. Miller's post on LinkedIn: You can now write one sentence to train an entire ML model:
How does it work? You just describe the ML model you want... a chain of AI systems will take that...
Please compress stuff!
It is worthwhile paying attention to the carbon footprint of today's widespread and growing usage of the Internet and digital devices.
Some estimates deem it comparable with the pollution generated by airlines and flying.
I just checked out the effect of reduction of resolution and compression (using compressjpeg.com) on an image that I emailed to some friends:
The shrunk and compressed image was virtually indistinguishable from the original – it was even a bit easier to read due to slightly higher contrast.
The combination of lower pixel count and compression reduced the size from over 1.7 MB to less than 100 kB, by a factor of over 18.
Some supporting articles that I checked out:
Did you know that writing an email can send 17 grams or more of carbon dioxide into the atmosphere? Or that going audio-only on Zoom calls reduces carbon emissions by up to 96%?
