BimorphNodes v5.0.0 for Revit 2024 Released

Developers
1

BimorphNodes v5.0.0 for Revit 2024 Released

Hello Dynamites. BimorphNodes v5.0.0 for Revit 2024 has finally arrived and is available for download via the package manager.

There are no new nodes, its just a few bug fixes and a retargeting to the R2024 API. Its safe to upgrade as there have been no major changes to any of the nodes:

  1. Fixed a units conversion failure in R2024.
  2. Fixed an issue causing Curve.FindDuplicates to throw an exception.

Compatibility

V5.0.0 targets Revit 2024 API and Dynamo 2.17. It is backwards compatible with R2020 ~ R2023 and Dynamo 2.x. This version should also be compatible with R2018 and R2019, but its not been tested using these versions, so use at your own risk (or upgrade your Revit!).

10 Likes
2

BimorphNodes v5.1.0 compatibility fixes and performance improvements to Sheet.Duplicate

V5.1.0 has just been published on the package manager which fixes the following compatibility bugs:

  1. Using any node requiring a Category input threw an exception if used in R2023 or older, e.g. LinkElement.OfCategory.
  2. LinkElement.GetParameterValueByName would throw an exception if the return type was a Dynamo Category instance.
  3. ElementId value type compatibility container (DI container) wasn’t registered at runtime causing exceptions when attempting to access its ElementId.Value (R2024) or ElementId.IntegerValue (R2023 and older) property accessor methods.
  4. Improvements to the performance bottlenecks in the Sheet.Duplicate node.

The Sheet.Duplicate node is still slow and gets worse if duplicating a lot of sheets. There’s not a lot that can be done about it since the bottleneck is caused by Revit regenerating the document whenever a new view is created. Don’t duplicate more than 15 sheets at a time otherwise it can take an inordinate amount of time to duplicate and likely won’t ever complete. The node has been optimized where possible, just keep in mind the limitations.

Depreciations

LinkElement.LinkInstanceId is going to be depreciated by R2025 owing to Dynamo’s handling of Revit ElementId’s. You can still get this id however using the OOTB Element.Id node as LinkElements are compatible with all OOTB Element nodes. If you are using this node, I suggest updating your graph now to avoid any future disruption. The node is hidden from the BimorphNode library in this release so you’re graphs will still work - when V6 arrives after R2025 is released, the node will be removed.

DynamoGate

Some feedback on the conversation relating to the problems caused by the change to built-in enum types and ElementId’s from int’s to long’s (64-bit int’s) in Revit 2024 (read Jeremy Tammiks post here for details) and Dynamo following suit:

  1. It’s a problem with no solution ONLY if a package has nodes that output an element Id. Internally its not a problem for either Dynamo API or Revit API calls as the breaking changes can be easily abstracted away via wrapper classes and any call is handled via the wrappers (injected at runtime based on the version of Revit running - I’ll post the method BimorphNodes uses to do this sometime next month for those interested. The approach can be used for any app needing backwards compatibility, not just Dynamo or Revit).
  2. There is nothing Dynamo can do about it since enums are immutable value-types and element Ids are also value types - therefore changing from int’s to long’s is the same as removing one node class and replacing it with another. In contrast, the reason why Revit can facilitate backwards compatibility is because ElementId is a class (reference type) which has properties, so in R2024 the Revit dev’s simply added a new property to the class named Value which returns long and retained its depreciated property IntegerValue that returns int. However, one can’t add a property to a value type (stores data within its own memory allocation if you want to get technical) - its not a class and therefore doesn’t have properties - and that’s why Dynamo can’t do anything about it.
  3. It is for this reason I believe it was an oversight for Dynamo’s software architecture to store Revit ElementId’s as int’s instead of its own wrapper class. They made a rod for their back and have no other option but release Dynamo with breaking changes. If it had been a class, then like Revit, this change wouldn’t be to big of an issue. This is why LinkElement.LinkInstanceId is being removed as the alternative is to change the return type to object, break any graph using older versions, and hope Dynamo can unbox the value correctly at runtime. This isn’t something that sits well with me as applications should be predicable at runtime and not rely on hopium.
  4. From a Revit API standpoint, developers only have a years grace before ints are sidelined. While ElementId.IntegerValue can still be used, its unpredictable for larger models and doesn’t help at all if say you want to compare two Id’s or compare built-in enum types to one another or with element ids, so its really just a nod to a bygone era rather than a viable solution that should be used for practical purposes.

On the plus side, the change is obviously in preparation for the switch to .NET 8 which is a much newer framework than the current .NET 4.8 which is no longer in development. It means:

  1. Developers will have access to the latest C# language features rather than being stuck in a timewarp.
  2. The latest tech stacks can be used to create much better apps, e.g. Blazor hybrid.
  3. 64bit means everything will run faster and utilize more processing power.
  4. Larger models will run faster.
  5. The latest NuGet packages which target the newer frameworks can be used without the need for assembly redirects; e.g. Text.Json.

That to me is well worth the pain the breaking change is causing - its only temporary hurdle which will eventually disappear over future releases.

9 Likes
3

BimorphNodes v5.1.1 bug fix

V5.1.1 has just been published to fix the following bug:

  1. Element.IntersectsElement node would throw an exception in R2023 or older if used with LinkElements. The bug as caused by Dynamo Elements.Id comparison.
2 Likes
4

BimorphNodes v5.1.2 bug fix

V5.1.2 has been published to fix the following bug:

  1. Duplicating sheet annotations failed. Caused by a unpredictable results from the GetDependentElements() method.
1 Like