Everybody loves Marcello, but...

It's true.
He is a brilliant man and he has done an astonishing work in the past with Revit, and most of all he shared his work and discoveries in multiple occasions and he became one of the most respected opinion leader in the world wide community through blog threads, Autodesk University Classes, RUGs and so on. So he's one of my superheroes and he knows it.

It's been a while now that he is on Dynamo, he has a course on CAD Learning and here's the latest class at AU named "More Practical Dynamo: Practical Uses for Dynamo Within Revit" that you should check out, it's been recorded and it's available for free.

I watched it on streaming and I was hoping to see some of his magic tricks in action but I was disappointed, very much, partially for the content of the class itself (I get that most of the people who attended the class hadn't the slightest idea of what Dynamo is and how it works but 20 minutes to change texts to upper case, seriously?), and mainly for a few false concepts here and there that will make people go "Marcello said it, so it must be true" because of who he is for the community.

I just couldn't turn a blind eye on it, for the sake of those who will approach to Dynamo and Revit API in general because they were inspired by Marcello's work, he's a good story teller, and I get that sometimes he needs to simplify concepts, like in this case, but too much simplification can lead to misunderstanding and unnecessary confusion, especially when it's going to be out there for a very long time.

Just a couple of examples:
1) [0:08:25] Element Types ARE NOT System families, they are the Base classes for all Types within Autodesk Revit (System or non-System family types), they simply are different animals.

2) [1:21:12] With this version of the Revit API it is not possible to create a "free standing" Railing but only hosted by a stair object and there are no exposed method to change the path of a Railing object. So NO, you can't create the fence example using an actual Railing object directly from Dynamo, something that you might want to change type later on per say, but you can use generic models, adaptive components, you could model the whole thing in Dynamo and import it in Revit using DirectShape...
Here's a question on the Revit API forum on the same topic.

What I'm saying is to keep up the good work, the creativity and the inspiration as a community, but in order to do that we should never take for granted what people tells us to be true (not even me, not even our heroes) and wrap our own head around problems, so if we look at the same problem from different point of views we might find a truly better solution.

I've tried to follow a very wise and simple ABC rule I've read somewhere, I think it's worth sharing:

Assume nothing
Believe in yourself
Check everything

Project BuildCity3D

Here is a brand new initiative by my good buddy Cesare Caoduro from his LinkedIn page: unleash all of your creative power and test your skills with the collaboration tools provided by the A360 platform!

You get to to pick your favourite Autodesk tools and create your own city for free!

So get an Autodesk Account if you don't have one already and be prepared to submit your models!

Like Cesare said on his page:

"...Imagine and design your personal city because the imagination is the only barrier for game designer, think like a game desiger or like a baby constructor..."

Read more here

I'll be there, and you?

Setting Active View Temporarily Disabled

Sad news, thanks to Alex S. I ran into what appears to be a by-design limitation in Dynamo.

The idea was to duplicate a Legend View since it is not possible to create a new one from the API, rename the copy and use it to set the Active View property of the UIDocument.

Turns out it's not possible to do that in Dynamo, for now.

Here's the Python script I've used, maybe someone has already found a solution to that.

Dynamo 0.8.2 is out!

Good news!

the latest stable release of Dynamo is out and ready for everyone to test, you can find it here in the DynamoBim official page.

Among other really awesome things that you can find in the release notes, one in particular caught my attention: the "Node to Code", which helps you to learn DesignScript converting (where it is possible) the graph into a very well organized CodeBlock.

This is a fantastic feature that adds clarity to a graph and opens the path for a Dynamo code compiler, that's one of the things I've been dreaming on for a robust firm-wide Dynamo implementation.

Plus from what I could see the development did a really good job in resolving clashing issues in geometry representation in the Dynamo environment.

Happy Dynamo!

Lacings in CodeBlocks

Today I stumbled upon this notation in codeblocks and I tried to figure out how it works because I couldn't remember any documentations on this particular aspect but I think is pretty useful because it helps having compact clean graphs.

I've used a range from 0 to 5 (I prefer to use the codeblocks for this purpose) and built some points, on the Point.ByCoordinates node there is the lacing strategy to apply but on codeblocks there is not (to be fair now you can assign the lacing strategy to a selection of node via right click, also the codeblocks but it doesn't seemed to work in my case) .

With this syntax though you gain control over the range and how to use it applying transposition directly.

a=0..5;
b=Point.ByCoordinates(a< i >,a < j >,a < k >)

Now i,j, and k have to be non negative integers, which means zero is allowed, what this does is to let you control how to combine the numbers in the range.

If i,j and k have the same values then the result will be a list of 6 points where for each point x=y=z.

When these indices are equal to 0 they return the first value of the range (in this case 0), otherwise the indices express the order in which the values in the range are going to be combined: the higher index is the one that goes through all the values of the range first.

When two indices are equals and bigger than  0, for instance 1,1,2 or 2,2,1, the geometric outcomes are going to look the same but the points will be listed differently just like using the transpose node.

When the indices are all different and greater than zero you a have a cross product lacing behavior.

Without further ado, here are some images that can explain better the results of the different combinations.

Demonstration of sonic fire extinguisher

Mario Is Unreal

Dynamo 0.8.1 is out!

Finally this stable release is out for every Dynamo user, I've been waiting for such new feature for so long, and finally they are here!

Many thanks to the team for the amazing work once again.

Now I want to talk in particular about the grouping feature, this is the first step towards a robust, well organized, easy to read and edit Code/Graph.

A group is a collection of nodes, this is the closest thing that we have in standard coding with private functions or subroutines or whatever they are called in other coding languages.

To create a group is easy: select the nodes and CTRL+G (yes, I know... too bad that it is the same shortcut to toggle between the graph and the geometry view until 0.8.0, get over it!).

To be honset there are a couple of ways more  to do that via the menu, right clicking... so stop complaining, you have been given a LOT more than just that.

If you select the group with a right click you can assign the color, and make the title really, REALLY visible with a huge font size.

Now the user can better understand what a set of nodes is meant for, so it becomes easier to orient inside a graph saving a huge amount of time. Love it.

If you want to remove a node from a group, right click on it and remove it from group, viceversa if you want to add a node to a group you need to select the node AND the group at once, right click and Add to group, that easy.

Anyway I wish it were as simple as "drag-and-drop" items over a group but hey, Rome wasn't build in a day.

Nodes inside a group move all together, so it is fairly easy to organize nicely your graph in a few clicks. A couple of issues are still there though: if you try to align two groups, what you are really doing is aligning the nodes inside the groups all together... so for now you don't wanna do that, maybe in the next releases such behaviour will be improved.

A nice thing to have would be the ability to "lock" a group, so no user is allowed to mess with it

We have colors, let's use them to organize our graph! Yes but how? We have 16 colors for now, let's say we start distinguishing main functions in our graphs:

• Input
• Data manipluation
• Output
• Debugging

I know it is even too much simplified, but what can be wrong with simple?

Nothing.

So, please, let's keep it this way.

It would be AWESOME to standardize the color meanings inside a firm, to provide consistency, so one can pick four different colors from the bottom row and assign each one of them to functions above.

It would be nice to follow an order too... from left to right, like when you are reading a book, so for instance:

• Purple -> Input
• Orange -> Data manipulation
• Green -> Output
• Light Blue -> Debugging

I feel that this approach can be really useful if we want a serious Dynamo implementation in our everyday processes, plus this would increase the possibility to make circulate these graphs between firms and open up to a more productive environment with multiple benefits for every one involved.

Next step? Dynamo templates of course!

Model freezing

One of the issues that designers are most concerned about is the protection of their intellectual property within a model.

In an environment where the exchange of informations is vital to the process, one can not refuse to cooperate and share his model with other stakeholders involved, plain and simple.

There are different ways to protect the intellectual property without affecting the data exchange, such as using a different file format (e.g. DWF, IFC, etc..) but there's nothing we can do when it comes to native file format for authoring platforms like Revit.

Or maybe not.

I've been looking to the new functionality shown by Jeremy Tammik in his blog, the DirectShape, intended to allow the users to import geometry created in other softwares through other formats like OBJ for instance.

What I was trying to accomplish instead was to create a DirectShape from the actual model, retrieving a solid and fill the voids left by the rooms for 3D printing optimization, I'm still struggling on this particular issue since rooms appear to end up as solids with negative volumes.

Then came to mind a possibile application, the model freezing: one can select a portion of the model that wants to lock and eventually use it as a component. in other projects.

In theory it is possible to freeze the entire model, obtain a generic model, copy and paste it into a blank project, and deliver that to a third party.

The odd thing is that the family created through this process has no Type and it is not even listed in the family browser, so it can't be edited and saved in anyway.

The generic model is not editable and won't even export to CAD for what it matters, the only workaround I found was to export it to IFC.

In this case all of the data is retained except for the 3D geometry and some material information (just the appereance because tagging won't work).