The way Dynamo interacts with units will significantly change in 0.8 starting with any pre-release build afterDynamoInstall0.8.0.20150312T1814.exe. Read all about it in this blog post. Of course feedback and discussion always welcome.
Brilliant change in my books! Many thanks. Especially the bit that pulls your units direct from Revit.
Is this just for length, area, volume only? Or will it also apply to units of force (kips), pressure(psf), etc? Right now there are some crazy conversions that you have to do when dealing with those types of values in Dynamo.
I haven’t tested the 0.8 builds yet. But it looks really great that the units issue seems to be solved. Thanks
Ben, please test this out–the intended behavior is that no conversions are necessary to get the number as it appears in Revit, with whaterver units, to be the same numeric (unitless) value in Dynamo. So if you have your project units set to read force as kips, then 5 kips will be read as “5” in Dynamo, etc.
The back-end bookkeeping is that Dynamo reads the value stored for a particular parameter, then looks to see how that parameter value is being displayed to the user and performs any necessary conversion (with the same conversion methods Revit uses) from the base Revit unit to the value as displayed by the user. The opposite should work with setting parameter values, with the result that regardless of the unit you use in Revit, Dynamo should read and write it directly without the need to convert. Then, within Dynamo, how you deal with the data is up to you.
Glad to see that the latest daily build has also fixed the copy/paste from file to file issue as well as the screen capture issue.
I haven’t tested any of the 0.8 builds for more than five minutes yet, but a couple of questions regarding units come to mind:
-
What’s the new best practice for Python interaction with the Revit API? Will there be convenience functions like the previous Area.FromSquareFeet for both directions (to/from Revit API)? (Here’s my wishlist: Number.FromFeet, Number.FromSquareFeet, Number.FromCubicFeet, Number.ToFeet, Number.ToSquareFeet & Number.ToCubicFeet for starters…) I know I can do that conversion myself by querying Revit’s project units and converting them to/from Imperial if need be, but it would be nice to have that kind of stuff available as built-in functionality (like ToDSType method and other methods…).
-
What’s the new best practice regarding import and export of geometry (SAT files)? Will we be able to specify the units of the geometry? (Also, when running Dynamo in standalone - wouldn’t we have to be able to still set a project unit in order to meaningfully import/export geometry?)
I’d appreciate one of the developers commenting on this…
Andreas- on import/export: we are planning on convenience nodes to help get your model to be the rights size, but haven’t implemented them yet. Will talk to Dev about python convenience functions.
- Lilli
Thanks Lilli, that’s good to know.
Does the latest build of 0.8 open as standalone? nothing happens if i try to open as a standalone. it only opens if accessed from revit
The latest 0.8 should open in standalone. Can you try uninstalling and re-installing? You might try deleting your Dynamo folder after uninstalling as well. Let us know if you can’t get it working.
Something doesn’t seem to be working with this, or maybe I missed something.
I imputed 1 (units are m^2 for area) so it should read 1 vs 0.093m^2.
See attached
It looks like you need the decimal “1.0” in the code block and works as expected.
Hum. This should absolutely not be the case and I can’t reproduce it in 0.8.0. Could you post your files?
Dynamo 0.8 is a very good release in my opinion. I actually just tried to look up how to import a Length from a Revit family in 0.7.5, and use that in an If block. Glad no more conversion is required now! What does appear a bit odd to me though, is if you use a code block instead of nodes, a list will be generated and somewhere downstream I have to declare that parameterValue = input[0] to not get a Null value.
The new icons really put the command into context (when ambiguous) and I like the different styles for Create, Query and Action, however the distinction might be clearer still if it had a background hue. Going by that same logic, the Nodes themselves might benefit from that distinction as well. But that’s just my opinion, once you know what everything does the textbased tree structure works fine as well. Both are as compact as they need to be for such a huge and powerful toolbox.
Thanks for the hard work, I’m excited for the future of this program 