We recently addressed aspects of interacting with the Revit API from a modeless context. Let's continue in the same vein, and also look at AI and nuclear power news bites:
Modeless context is basically synonymous with a background process, as explained in the Revit API discussion forum thread on background processes:
Question:
I am starting to venture into the Revit Background Processes.
My goal is to be able to timestamp each placed element (Fab.Part) with the date and time.
I have read the post
about background process API access on
creating background processes.
I am familiar to external events and handlers and understand why they have to be used; the only thing I cannot figure out for the life of me is how to implement the custom process into the document.
I have it loading with our ribbon but without a document being opened or an implementation of the process I can't use the DocumentChanged to find recently added element ids and continue testing.
Documentation and examples for this topic are really hard to find.
Answer: Congratulations on all your work and understanding so far. Then, you understand that the Revit API is single-treaded, and all Revit API calls must be made from a valid Revit API context residing in the main thread. A background process is a process that executes in a different thread, a background thread. It cannot access the Revit API, so all interaction with Revit and the BIM needs to be marshalled back and forth in some way between the background thread and the main thread. That is all I can say really. Background threads are not part of the Revit API, so this is not the right place to discuss them. For more information, you can start out by reading up on something like .NET background thread.
Two more notes:
timestamp each placed element (Fab.Part) with the date and time.
This cannot be achieved in a background process, since the element lives in the Revit database, so access and modification will require a valid Revit API context.
Documentation and examples for this topic are really hard to find.
I disagree. The Building Coder has discussed related issues with great frequency, and they have also come up a lot in previous discussions here in the forum; a background process is basically a modeless context, so the interaction between those and the BIM are covered by the discussions on Idling and external events for modeless access and driving Revit from outside.
Christopher Diggins of Ara 3D is looking for feedback on performing long running background computations using Idling event:
Question:
We are experimenting with performing long running computations in the background of Revit by using the Idling event, and breaking the work up into a queue of many small tasks.
We built a small open-source library around it:
Early experiments seem promising, but the real test will be when it is used by actual users in various tools and plug-ins. I can't tell yet how reliable the technique is when Revit has a lot of work to do, and whether it could cause a bad user experience.
We would like to hear from other people who have used this technique, or similar techniques, in the past to extract data from Revit, without blocking the UI. Specifically, do you know if this technique works well in practice? What other techniques could be used? What are the pros and cons?
Answer 1:
If your code is running inside the Idling event or IExternalEventHandler, that code is running in the Revit API context and gonna block the Revit UI.
If the code is fast, the user will never notice, and if the code takes a long time to finish, it will make Revit laggy.
Answer 2: I did quite a lot of work implementing similar functionality for my RoomEditorApp way back in 2013.
There, I did indeed encounter and analyse certain RoomEditorApp Idling issues.
I hit some limitations of the Idling event, especially controlling the timing and frequency of interaction with Revit, affecting how strongly the external code affected and blocked the Revit UI.
In the end, I resolved them by replacing an Idling event handler by an external event.
You may be able to implement significant improvements to your approach by following suit.
I suggest you check out some of the other discussions on this topic in The Building Coder topic group
on Idling and external events for modeless access and driving Revit from outside
and the related posts listed in
the FireRatingCloud documentation.
Maybe things have changed nowadays, but I suspect Revit still decides internally how often to call the Idling event handler, whereas an external event enables you to control the frequency yourself.
So, I would suggest that you explore the use of external events for your purposes as well.
Unless everything is running so impeccably and smoothly that no improvement is required, of course.
Never change a running system!
Roman @Nice3point Karpovich, aka Роман Карпович, shared a new effective solution on how to know if Revit API is in context:
The previously suggested solutions for determining Revit API context throw an exception when the API context is not available.
The preview version of RevitToolkit provides a new way to do this more efficiently without throwing an exception.
Throwing an exception costs quite a bit of time, and creating an additional empty EventHandler<IdlingEventArgs> for it increases memory allocation.
RevitToolkit now provides the property Context.IsRevitInApiMode that determines whether Revit is in API mode or not without throwing an exception.
Here are benchmark median results in nanoseconds comparing 1000 iterations using the old approach versus the new method:
| API Context | Exception | New Method |
|---|---|---|
| Inside | 24122 | 413 |
| Outside | 9522531 | 550 |
The difference in speed is 58 times in context, and 17313 outside.
Here is the RevitToolkit.Context documentation
Many thanks to Roman for discovering and sharing this huge improvement.
Luiz Henrique @ricaun Cassettari and Mauricio @Speed_CAD Jorquera provide a solution to why API queue command "CommandId" cannot be invoked in this context
Basically, certain built-in Revit commands require a valid active view and the view must have focus.
Therefore, in order to use PostCommand to launch a built-in commend such as "Select by ID" with the command id ID_SELECT_BY_ID, you first need to ensure that a graphic view has focus.
Many thanks to Ricaun and Mauricio for all the research they put into this!
Procreate provides creative tools under the motto Art is for everyone. They go against the current mainstream with an unequivocally clear statement that they do not plan to support the use of AI in their tools:
On the other hand, the AI act is here:
The European Union enabled the Artificial Intelligence Act, the first-ever legal framework on AI, addressing its risks and positioning Europe as a leader in AI legislation.
On the other end of the scale, making full unfettered use of it, Sakana.ai is working on creating
The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery
It is interesting to examine the example papers generated by The AI Scientist, especially The AI Scientist Bloopers:
... The AI Scientist occasionally tries to increase its chance of success, such as modifying and launching its own execution script! We discuss the AI safety implications in our paper. For example, in one run, it edited the code to perform a system call to run itself. This led to the script endlessly calling itself. In another case, its experiments took too long to complete, hitting our timeout limit. Instead of making its code run faster, it simply tried to modify its own code to extend the timeout period...
Moving to a different field of science unrelated to AI and computing, Cesare Mencarini of Cardiff Sixth Form College built a nuclear fusion reactor capable of achieving plasma:
Phase 1 Complete – Achieving Plasma. This is an Inertial Electrostatic Confinement Fusor which will be capable of achieving fusion once complete. For more information, check out the fusor.net thread on plasma achieved!.
Don't miss reading the very impressive LinkedIn comment explaining the low project funding.
