New exciting Revit API solutions and continued furious pace of LLM development:
Christopher Diggins published Bowerbird for quick and easy C# tool and plug-in development by dynamically compiling C# source files, and a request for feedback on it in the Revit API discussion forum, saying:
I've released a new open-source project for Revit C# developers called Bowerbird. It uses the Roslyn C# compiler to allow users to create and edit new commands directly from C# source files, without having to go through the process of creating and deploying a plug-in, and re-launching Revit.
It is inspired by pyRevit by Ehsan Iran-Nejad and Revit.ScriptCS by Sridhar Baldava.
I'd greatly appreciate any feedback or contributions in the Bowerbird GitHub project. Thanks in advance!
Many thanks to Christopher for creating and sharing this helpful tool!
A while ago, I took a look at determining the doors traversed by a path of travel and shared some thoughts on that in the PathOfTravelDoors GitHub repo.
They were picked up again in the Revit API discussion forum thread on doors traversed on path of travel lines.
Question: I want to list all the doors that are crossed by a path of travel line.
I tried to code that, but it seems that the ReferenceIntersector finds more doors that are not on the path of travel, because the introduced ray is reaching them.
I looked at the Revit SDK sample PathOfTravel, but that does not help.
The ReferenceIntersector documentation is illuminating, and the FindNearest method ought to ensure that I only get a maximum of one single intersected door.
Answer: Hmm. Maybe, this task can be addressed simpler. How about this approach without using the reference intersector at all?
Afaict, that should solve the problem right there. What do you think?
Response: Just cracked it an hour ago! I tackled it with this trick: For each curve in the path of travel line I did once from the start point following the curve's direction, and once from the endpoint with the reversed direction. Then, I accepted the points that appeared in both.
I also thought of another approach as you mentioned: generating an imaginary line at each door location and checking whether the path of travel line segments intersects that. However, this method required finding the two points of each door, possibly by examining the geometry of a wall for its opening. While it seems plausible, I decided against pursuing it initially due to its complexity.
Later: Unfortunately, the described technique fails to yield the intended results across certain models, resulting in a null output from the ReferenceIntersector.
As a workaround for those specific models, an alternative approach was employed:
Answer: Glad to hear that you found an approach that works reliably for all door instances.
I cannot say for sure why the reference intersector fails in some cases. One thing to consider, though, is that a content creator has complete freedom in the family definition. So, some content creators might choose to represent doors in a completely unconventional manner. They might define the door geometry so that no solids or faces exist for the reference intersector to detect, which might lead to such failures. The infinite flexibility provided for Revit family definitions can make it hard to ensure that an approach always covers all cases. This makes unit testing on a large collection of possible BIM variations all the more important.
The approach you describe is very generic: every door opening is defined by one single line from start to end point, and that line must be crossed to pass through the door. That sounds pretty fool-proof to me.
In 2019, Eason Kang shared a very helpful explanation on how to map Forge viewer camera back to Revit.
However, some aspects changed, and some were left uncovered back then, as discussed in the new Revit API discussion forum on Revit 3D view camera settings.
So, Eason took another deep dive into the topic, researched, tested, organized all the material and published it in two blog posts:
The associated sample code lives in the
Ever so many thanks to Eason for his very careful research and documentation.
Claude 3 LLM AI model was released, now vision-enabled and with scores in several intelligence tests:
Another announcement introduces Devin, the first AI software engineer, a fully autonomous AI software engineer.
Meta Imagine generates images, cf., Meta launches web-based AI image generator trained on your Instagram pics.
I briefly tested it myself, trying to approximate an image of the real-world scene in front of me, and was unable to tweak the prompt to generate a satisfactory result. My impression was that it very quickly ignored important aspects of my prompt, e.g., specific colour requests, etc., even when I repeated them, so I quickly gave up, unsatisfied.
Yet another use of LLM, LLM4Decompile: decompiling binary code with large language models, with its LLM4Decompile GitHub repo.
On another ever-present and looming topic of our days, BBC shares a nice and simple comprehensive article explaining What is climate change? A really simple guide.