We continue patrolling the well-trodden paths of BIM, AI, Revit precision and RevitLookup:
Last week, I mentioned the momentous AI news that AlphaGo has now conclusively beaten mankind at the game of Go and is retiring from competitive play.
AI is not the only exciting thing happening with computers right now.
Much cheaper and more accessible technology with immediate and potentially revolutionary impact is provided by cheap sensors and connectedness, as explained in the Redshift article by Nicolas Mangon on the end of BIM as you know it – are you ready for connected BIM?
It discusses the combination of cheap sensors with GPS and connectivity, ending up with an outlook on AR and VR.
This in turn plays well with Maurice Conti's TED talk on The incredible inventions of intuitive AI, which also turns to the topic of connectedness towards the end:
What do you get when you give a design tool a digital nervous system? Computers that improve our ability to think and imagine, and robotic systems that come up with (and build) radical new designs for bridges, cars, drones and much more – all by themselves. Take a tour of the Augmented Age with futurist Maurice Conti and preview a time when robots and humans will work side-by-side to accomplish things neither could do alone.
Back to the Revit API:
Question: I don't understand why the end point of one curve and first point of next curve are not in exactly the same place when I examine the edges from the top face of a curved wall.
The curve endpoint coordinates differ in the last digits. As you can see, the last three digits are 655 and 612, respectively:
Due to this, I cannot get a closed curve loop.
Any solution or it is bug?
Answer: You need to implement a fuzzy comparison operator, since real-valued coordinates will almost never be exactly equal.
Here are a number of previous discussions of this topic:
- Nested Instance Geometry and the first implementation of the
XyzEqualityComparerclass – I implement this container by using a generic dictionary class and attaching an equality comparison class which ensures that almost equal points are regarded as being exactly equal, allowing for some fuzziness due to numerical imprecision... The sorting process requires another fuzzy comparison routine, a
Comparefunction which determines whether a given point is larger than, equal to, or smaller than another one, and correspondingly returns 1, 0 or -1.
- Top Faces of Sloped Wall – Obviously, like all comparisons of real numbers, that requires us to add a fuzz factor, since real-valued coordinates will almost never be exactly equal. -Retrieving Unique Geometry Vertices – For this, we need to implement a fuzzy method to distinguish between points that really are different, but detect that points that are nearly the same should in fact be treated as identical.
- XYZ Vertex Lookup – As discussed so many times in the past, the point comparison has to include some fuzz.
- Sort and Orient Curves to Form a Contiguous Loop – Its end point matching comparison relies on the standard Revit precision, which is around one sixteenth of an inch. Since the built-in Revit database length unit is feet, I define the following fuzz factor for that...
- Never use Direct Comparison for Floating Point Numbers – I would recommend never doing that, because they could always be off by an infinitesimal amount, in which case the comparison would return false, even if they are almost equal, within the possible precision. You need to use fuzzy comparison for floating point numbers. Look at this discussion on real number equality testing.
- Extracting Unique Building Element Geometry Vertices – implement a fuzzy point equality comparer and then add the points as keys to a dictionary.
Alexander Ignatovich, @CADBIMDeveloper, aka Александр Игнатович, once again added several enhancements to RevitLookup, our beloved and invaluable interactive Revit BIM database exploration tool to view and navigate element properties and relationships, in his pull request #34 – bugfixes and improvements.
Here are his commits:
- Add ability to explore geometry of view specific elements such annotative families that have no model geometry, but only view specific
- Display properties and methods returning
IEnumerable<ElementId>as lists of elements, not of element ids
- Improve usability – show name property (if available) not only for
Elementclass objects; show parameter definition name not only in specific case for
- Add ability to view byte values (for example, for
Many thanks to Alexander for his continuous and efficient enhancement work!
Also note what a lot he achieves by modifying a very few lines of code.