mercoledì, ottobre 28, 2015

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?

giovedì, settembre 10, 2015

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.

lunedì, agosto 31, 2015

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!

domenica, agosto 30, 2015

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.

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.

sabato, luglio 04, 2015

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?
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!

venerdì, gennaio 09, 2015

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). 

sabato, novembre 29, 2014

Insert Excel worksheets as Revit Schedules

I'm ve been away for a while, I've some news too.
Since October the 1st 2014 I'm part of the Autodesk Consulting AEC EMEA team, and I'm really happy! I'm sorrounded by very talented people and I'm learning everyday something new. Unfortunately I wasn't able to blog for a long time.

But anyway I'm here now and I want to share with you what I couldn.t over a year ago. During the first session in the very first RTC Europe in Delft, David Conant showed us a very interesting application of the new feature in Revit 2014, the highly customizable schedules!
Back at the time I had little knowledge of coding since I had just started the course by Harry Mattison of Boost Your BIM on Udemy, which by the way you should totally check out if you haven't yet.

I had time these days to test my understanding of how Revit API can work for me and made a little experiment to mimic what I saw at RTC, it's still a work in progress but I think it's been one of the highlights of that a RTC and shows pretty well what can be ddone if you just think out of the box, so my big thank you goes to David and Harry.

Here it is.

giovedì, settembre 25, 2014

Export Sheets in shared coordinates

When working with consultants or clients it's fairly common to ship PDFs and DWGs of the sheet sets along with the Revit model, however DWGs are the weakest part of the overall process.
Revit is not able, natively, to export DWG in shared coordiantes from a sheet view, but from a regular model view it does although it will never be a native DWG file. So I wrote a macro (see a previous post) that collects the views on a sheet and exports them in a separate folder to have them organized and in shared coordinates.
What was missing was the ability to include the title block, which was ok for consultants but not for the client.
So here's a video that shows how this issue can be solved using both Revit and AutoCAD.
DWGs are still X-Refs and they are not clipped like in the previous version, each view is then rotated accordingly to the Revit file. Each viewport only shows the layers of the corresponding x-ref. For further enhancements the views could be locked automatically, there could be a batch file that will open AutoCAD and do the job for each sheet file, etc... I'm still working on and testing it. I hope to find a way to run the whole thing from Revit with the press of a button. Suggestions and critiques are appreciated as long as they are constructive.

lunedì, settembre 22, 2014

Super Tag - Parameters grouping

In this examples I'm trying to retrieve the parameters of a generic model representing a person (a generic model smile shaped) in a room with all the equipment that belongs to his/her such as the workstation or the phone (each family has its own parameters).
In the previous example parameters were just listed in a certain order hard-coded in the Updater, this time the order needs to change slightly so that the parameters referring to a spefic person are all consequential.
In order to do this an additional step must be included in the process.
The best way I could think of is to group the families involved (the person, the workstation and the phone), retrieve the parameters for grouped objects first and then the remaining outside of groups.

mercoledì, settembre 17, 2014

Super Tag - Dynamic Model Update

I've been wrapping my head around dynamic model update in order to push my code further to be more "Revit-ish", so it updates instantly and has no longer a "fire and forget" sort of behaviour.
I've implemented an IUpdater interface that loops through the family instances, reads their parameters in a certain order and then pushes them into the comments of the room.
It's not perfectly Revit since it's not bi-directional at the moment, anyway it gets the job done nicely.

Technically the oddest part in developing this idea was to realize that an IUpdater doesn't need a transaction to work.

Applications are endless, this one I called "Super Tag", it would give the ability to the users to push calculated values into tags (finally!), embedding a piece of code in the template file assuring that everyone on the team has the same tools available.

There are considerations to make on performances, but it sure is a great thing we have to suit our design.

sabato, settembre 06, 2014

Dynamo - Document Nodes Confusion

In addition to Marcello's post  on confusing node names for selection in Dynamo, I'd like to point out what I've just discovered about the Document nodes.

In the API the document that is shown to the user is called Active UIDocument (for brevity uidoc), this element has a property called "Document" that refers to the data base level document (for brevity doc). Any time we want to edit a file in Revit we need to open a transaction that points to a specific doc, while the user interacts with the current uidoc.
In a Revit session there could be multiple docs opened at the same time at a database level (think for instance to a host and links scenario, linked files are documents somehow opened at a database level but not directly editable by the user in the current session; similarly, with multiple editable docs opened, the user is allowed to edit just one at a time, the active document, the uidoc), they could be project or family documents.
The API allows access to those docs without the user interaction and for this reason it's important to have clear in mind the differences between the two: for example, object selections belong to the uidoc (because they require the user intervention), walltypes belong to the doc (because their definition doesn't depend on variables such as the active view), etc.

In the picture above you can see that Document.Current is referring to the UIDocument since I got the active view name, while the Element.Document is referring to the Document since I got the title.
Hope this is gonna be fixed or cleared up in releases to come.

Are you kidding me???

venerdì, settembre 05, 2014

Dynamo - Rooms Solids - Color Scheme for any parameter

This is a further development of previous Dynamo definition, now it can apply the color scheme for any parameter, there's a little bit of coding in there because I couldn't figure out why a cross product lacing over a List.FilterByBoolMask returned a null list for the In and Out output ports.
Anyway I did it myself using a very simple script in Python.
I'm trying to avoid them as much as I can, really, but when I'm tight on the dead line and I need  the get the job done, coding is always my best option, even if I don't feel particularly comfortable with Python, but I guess it's how my brain works, I know for a fact that amazing things are achievable just using the OutOfTheBox set of nodes, so I hope to have enough time to obtain the same thing using a "pure nodes" approach instead.

I guess that the beauty of Dynamo is that everybody can play with it and  make his own tools, no doubt about that.

Here's the code I've used to collect rooms in the project:

Here's the code I've used to retrieve indexes evaluating the elements of ListA against the elements of a ListB, the output is a list of integers, as long as ListA.
In this example ListA contains Department values for each room in the project (11 rooms gives 11 items) while ListB contains the same values but derived from the Color Scheme file (5 department entries gives 5 items).

The outcome of this python script is used to determine which color has to be used to override each one of  the solids derived from rooms.

Solid extraction and ListA:

Color override and ListB:

Here's a .Zip file containing the .Dyn, .Rvt and .Csv used in this example.
In action:

giovedì, settembre 04, 2014

Music as a Language: Victor Wooten at TEDxGabriolaIsland

One of the greatest musicians of our times, Victor Wooten gives a speach at TEDx on what music is for him, sharing his experience and some interesting thoughts on life.

mercoledì, settembre 03, 2014

Dynamo Room Solids

I've been asked today by a collegue how to replicate an axonometric view of AutoCAD spaces into Revit for a preliminary design.
In the past I've tried to do something using IFC but the result wasn't that good after all for many reasons.
This time I tried a Dynamo approach to the problem since it allows access to data and particulary to the solid representation of elements.
What I needed was a little bit of code to select rooms in the project but I still suck in Python, I happend by chance in a package by Nathan Miller called LunchBox and one of the custom nodes inside this package retrieves a lot of room data. What I did in this case was to copy the import statements from this node and write a few lines of Python code on my own to filter objects belonging to the Room Category.
After that it was fairly simple extract the solid representation for each room, I created a list to keep the geometries distinct because I wanted to be able to control the color of each room to match the color scheme in 2D views.
Here comes the sloppy part: unfortunately the API (Revit 2014 as far as I know) still doesn't give access to the color scheme parameters, so not even in Dynamo it shouldn't be possible to retrieve those parameters.
To keep it simple I decided to write a CSV file containing the paramter value and the components for the colors in the color scheme (this one was based on the name of the room, but it could be done for every parameter availible, just keep in mind that room solids have to be grouped as one big object for each value of the color scheme (I know it's not very handy but I couldn't figure out another way to do it, suggestions appreaciated).
Here's the definition for those who want to have a closer look to it.

martedì, settembre 02, 2014

LOR - Level Of Reliability

Using acronyms is not really in my culture since I'm not an english mother tongue, it's fairly common though in the rest of the world and I happend to get used to it. I had to be explained what "RAF" stood for in a project based in London, since for me it was Royal Air Force, but the other BIM Manager on the phone told me it was Raised Access Floor, just to name a funny episode that happend to me not too long ago.
Right now the usage of these "magic words" is spreading also in the AEC industry (here's another one).
If everybody understands these acronyms, such as BIM, BEP, VCD and so on, and everybody knows precisely what they refer to there's absolutely no problem with using them.
Unfortunately this is not the case for the subtle LOD (Level of Development), which is sad to note that still too many people tend to confuse with level of detail, which is a completely different concept.
I'd say to shift the attention from the model to the results of the analysis that can be performed on a model at the certain stage of its development.
LOR Level Of Reliability would measure the reliability of those analysis (in a general kind of way), less people would confuse the terminology and the key concepts behind it.
I think at least it is worth a discussion.

domenica, agosto 31, 2014

practical BIM: The Nature of Naming

practical BIM: The Nature of Naming: BIM is by nature a shared environment. For example in the context of Revit each discipline team work together in one file. This new paradig...

venerdì, agosto 29, 2014

Change Elements Workset Macro availible

This is the latest version of this macro that moves objects from one workset to another and let the user check the results via a report button.
The user can copy and paste the Id's in the report for further editing using the Select by Id tool in the ribbon.
There's a check box that allows to move also hidden objects that don't belong to any categories visible to the end user.
Here's the solution to copy in here:


If you're happy with my code please show me some gratitude paying what you want via PayPal to:

giovedì, agosto 28, 2014

Move Elements to Workset - WIP

This macro opens a little form with two drop down  menus listing the worksets in the project and then try to move all the possible object from the source to the target workset.
There's a Log button that opens a read only dialog listing the Id's of the elements and the types divided by workset and the number of objects in parenthesis.
I've used two different techniques to list the worksets in the project, the FilteredWorksetCollector and another one using the WorksetPreviews.
Right now I'm thinking about adding a check list for the categories to move between worksets, so the the form would be something more like the one in this other video:

Implementing the category check list produced some undesirable side effects: Analytical Surfaces and Structural Trusses return an error when selected, categories such as "Other" and "Legend components" are no longer taken into account when performing the macro.
I guess it's best to keep the possibility to control each and every object in the model for the next version.

Dynamo Language Guide for Code Blocks is out!!!

At a first look it seems pretty much the same old Design Script Manual, but it's still crucial in understanding how code blocks work.
Thanks to the team that put this documentation together, you guys are amazing!!!

mercoledì, agosto 27, 2014

Align Topo Macro attempt

Today I've found an interesting Topo add-in by Mustafa Khalil and here's a video demonstrating how it works.

So I decided to understand how it could be done and I tried to mimic the core of the add-in.
My attempt here is really basic, there are no parameters exposed to the user to set for instance.
This exercise gave me the opportunity to understand better some of the topography features in the API, for example the implementation of an interface to manage preprocess failures since it is needed to commit the transaction group necessary to edit a topographic surface.
Another interesting aspect is that Revit won't allow you to process points with the same XY values for topo surfaces, that's why I' decided to add a point at a time while editing the surface.
It would be fun to do the opposite: having a topo and edit the floor secondary element back... oh wait, Marcello Sgambelluri already did it :)

Anyway here you can find the code I've used if you want to have a look at it, if you are happy with it please show me some gratitude paying what you want via PayPal to:

martedì, agosto 26, 2014

Dynamo - 4 Points adaptive component along two lines update for version 0.7.1

When I tried to update the previous definition to the 0.7.1 release something went wrong and Dynamo was stuck.
I took the opportunity to rethink the definition and I found a slightly different approach to the problem: this time I keep the curves as distinct elements almost to the end, this way it's easier to check the orientation of the curves and get rid of the special node for opposite direction of the curves.
After selecting the model lines in the Revit environment Dynamo automatically places the Adaptive component accordingly to the maximum width specified for the subdivision.
If the orientations of the lines are opposite, Dynamo reverses one of the two and perform the definition anyway.

There's always need to delete the panels manually once created like in previous version, it would be nice to have a "dispose" node for this particular goal.
Here's the custom node definition and here's the test definition I've used.

sabato, agosto 23, 2014

Images from the past, hopes for the future

I was looking for some images for a presentation and I came across these pictures of some works I've done at the University prior than 2008, way long before adaptive components came along.
It was definitely fun! but really soon I realized that what I was doing was much, much more than just a 3D model, I saw the potential and what eventually the AEC industry was going to be in the closest future.
That's when I moved my focus from modeling and representation to BIM. Unfortunately most of the people that I know from the University still haven't even approached to BIM and they're just starting now to consider to move, for instance, to Revit because they're blinded by the 3D model and the rendering.

Using Revit to just make a 3d model is like having a Ferrari and use it in the backyard.

So please double check your willingness to learn something new (a BIM approach to design and not just how to use an instrument like Revit), both for productivity on a specific project and in the long run, keep in mind that it can be really painful if you're doing it while you're already working full time but it hasn't necessarely to be a blood bath if you ask for help to competent people.
Break problems into smaller ones, read forums and blogs to find answers to your questions, don't take "no" for an answer and never give up.

martedì, agosto 12, 2014

Dynamo - 3 points Adaptive Component

Today I was emailing with HyunWoo Kim of Enjoy Revit about a possible workflow involving adaptive components.
I made this quick Dynamo exercise on multiple elements selection and a specific 3 points adaptive component.
The 1st and the 2nd point of the family are attached to the ends of the curve while the 3rd is attached to the mid point. The tricky part was to get Dynamo understand the corresponding parameter for the mid point, infact if you insert in the list the value "0.5" directly it returns an error because somehow 5 is passed instead.
But if you use this simple formula c=(a+b)/2, everything seems to work properly.
It also works on curves in a linked DWG.
Here you can find the definition.


The error with 0.5 is no longer an issue since I changed the Operating System settings of the decimal separator for numbers changing them from comma to point.
In order to change it you have to go to Control Panel and click for the location settings, then customize the formats for numbers specifing a point instead of a comma as decimal separator.
Thanks to Colin McCrone and a reader who actually gave me this tip in the comments below.

giovedì, luglio 31, 2014

Family Management Utils - Linked Family Browser

I'm in New York on vacation these days, and the jet lag is still difficult to manage, so I woke up really really early this morning and I did a few experiments with the code I was working on.
I thought it would be nice to have a family browser for linked files, letting the user choose which family types copy into the control file etc...
With this kind of browser the user can visually see which family belongs to each one of the linked files, it would be great to have a search field to filter the tree (just have no idea how to do it right now, I'm still learning).
Next major step will be implement a tab interface for group of settings and objects such as System families, Other families (I've to find a way to separate annotations from model families as the tendenency is to get rid of annotations in linked files), Materials, Filled patterns, Keynotes, View Filters and View templates... of course I know that most of these features are already there with the transfer project standards but, what I'm trying to do, is to reverse the process: instead of doing the transfer for each one of the linked files, I would like to do the same thing from one control file to all the linked files, just once, extending control over non system families and their parameters.
In addition to that there's the visual control of the contents of the model (walls and floors detailed sections, material swatches, doors and windows assemblies, management of family names and type names accordingly to a user defined sequence of parameters/codes).
There's so much to do to make it work properly though.
So here's a my first attempt, what do you think? please let me know in the comments below.


venerdì, luglio 25, 2014

Family Management Utils - WIP

This tool I've developed works on door and window families between different files letting the user edit them inside a single control file and pushing the edited families back to the other files. I've collected a few lines of code and put it all together with a very simple interface.
This is the workflow I've imagined:

  1. Link the different projects into a single control file (CF)
  2. Acquire the families from the linked files cliking on Copy Types
  3. Delete duplicate types if necessary
  4. Create assemblies with 3 main views and dimensions for each type, assigning a unique Type Mark automatically, each assembly is named with this syntax: (TypeMark)_Family_Type
  5. Edit the components as necessary, fill in the data where needed and then update the linked files with the new version
  6. You can finally create assemblies in each linked file for documentation purposes, each assembly is created in the first phase and demolished right in the next phase of the phase sequence, so to not interact with the actual project.
During the process the linked files have to be unloaded, keep in mind that also the family type names shouldn't change before the update, otherwise the tool won't be able to perfomr the update as expected.
For the sake of this example I'm using two linked files, a simple one and a workshared one.
In both cases there are the same door and window families and I'm showing the steps of the workflow, when the linked files are loaded the type mark for the family type in common between the CF and the links can't be changed, this is true for any other parameter such as width, height or material finish.
Once in the linked file a purge unused is recomended.

I still haven't figure out how to dismiss automatically the dialog when reloading families and override the parameters. Any suggestion is appreciated.

lunedì, luglio 21, 2014

Cad Digest

When I started to use Revit in 2006 there were almost no places to find tutorial in italian except for 3dsmile forum, which has now become, and I had to find as much material as I could on the internet, basically that's how I learned english.
One of the website I visited the most at the time because it gathers a huge amount of Revit topics, and I still do, was, and, surprise surprise, this morning I've found a post I wrote a week ago on my blog.
Thanks, really appreciated!

venerdì, luglio 18, 2014

View Depth Override External Command - Bugs Fixed

You can downlaod a zip file containing the .DLL and the .Addin manifest for the external command.
I've to thank a reader for pointing out some issues with the planting category (because previous version didn't take into account categories with no material quantities just like planting).
Also there was another issue with 2D views because the override was performed on a polar distance like in 3D views, now it's been fixed using the distance between the center of the bounding box of an object and the plane of the view.
I discovered that CGS has copied my first idea, and that was basically the goal of me starting to publish the code: to make companies develop better add-ins, but unfortunately this is not the case.
Now you can choose to pay a subscription to them for this tool (along with many others of course), which by the way doesn't work on perspective views while mine does, so why don't use just mine instead of waisting money? please if you're happy with my code show me some gratitude Paying What You Want via PayPal to:

*UPDATE 2015
The command for Revit 2015 works just fine, there's still need for the .addin to reside in the correct folder and the paths inside the file to be eventually updated.
Anyway the addin file should be copied in here:


here's the addin file with paths updated for 2015 version.

giovedì, luglio 17, 2014

Delete Family Type Duplicates Macro

when dealing with a lot of copy and paste of objects among files is fairly common to end up with a project browser overpopulated by family types with equal parameters but a different type name (something like 1200x2400mm and 1200x2400mm 2, quite frustrating isn't it?).
For some category such as Doors and Windows the Type mark parameter is automatically changed to be unique to avoid  possible conflicts but all the other parameters remain the same.

Using this macro at your own risk, you can get rid of duplicates in family types.
If you're happy with my code please show me some gratitude Paying What You Want via PayPal to:

lunedì, luglio 14, 2014

Auto Assembly Macro - WIP

In this video I'm showing the results of a macro I'm working on these days that allows to create an assembly for each door and window type present in the project.
It's still a work in progress though, but what it does is pretty clear:

  1. create a generic wall sample to host a family instance of the door / window type
  2. create the family instance
  3. create an assembly with the family instance, its nested shared families and the hosting wall, whose category is after the family category and the name is a combination of the family name and the family type
  4. increase the mark type and assign it to the family type
  5. change the phase of creation and demolition of the assembly to be respectively the first and the second in the sequence
  6. create three assembly views (plan, elevation and section)
  7. create two major dimensions in the elevation view (I'm thinking of an early stage door/window schedule for this development)
There are still issues with curtain wall components though, need to fix that.
Using this method it's possible to create a source file that contains all the families and manage them with type marks, materials, and so on very effectively. Then the necessary editing can be extended to other project files really easily with the concept exposed in the previous post. Getting closer.

Family and Type parameters coordination between documents

Working with linked files brings some advantages on the performances of the computer but it introduces also many coordination issues. Even the same firm can use multiple linked files of the same discipline linked together to split the project into more manageable parts. In that scenario when a component family has to be updated in the geometry and/or the type parameters such as the Type Mark, the Description and so on, it's required the user intervention.
Some operations are really easy to do (for example reload a family), let's say it's just time consuming to open the file, reload and save for each one of the linked files where the family is loaded.
Some others such as filling in the type parameters can be tedious and unfortunately can also introduce coordination errors between the files. This means there's a lot of double checking going on and when there's an issue the user has to manually update the values as many times as the number of the linked files or at least the number of the errors catched by his eye during this process. The basic idea of BIM is to insert data in the model only once and possibly in one place in order to avoid this kind of mistakes.

In the example above I'm demonstrating how it is possible through the API to coordinate two different documents, a source (File1) and a destination document (File2) that share a family (for the sake of the examples it's a furniture family called GEN-1).
In File1 the GEN-1 family has just one type (Type 1)  with all the parameters filled correctly, while in File2 the same family has a different shape, has three types but their parameters have to updated. There's also another family GEN-2 with a Type 1 just to show that it's not involved in the process even if it is a furniture component and has the same Type name.

Notice that the macro can be run even with no document opened. What I'm gonna do next is to create a private method that updates the family content for specified categories (doors, windows, furniture, and all system families such as walls and floors) for all the files linked in a source project.
It's something close to the idea of  the Transfer Project Standards but extended to external families with the ability to override type parameters too.

After the macro has been launched the files are saved, the definition for GEN-1 is the same for both files (rectangular shape) and only Type 1 has been updated to comply with the source file.

This is a little step closer to what I believe to be an ideal tool for Revit project management.

venerdì, luglio 11, 2014

Align Scope Boxes Macro

Every once in a while it happens to deal with small rotations in the project, from structural grids to anything else when the design intent has changed and a new alignment in the building has been introduced.
If you had already set up all your scope boxes for your views it's fine to rotate them but snapping to objects sometimes can be messy and can introduces errors. So I wrote this macro to align a scope box to linear objects such as grids, reference planes, walls or lines. The rotation is performed around the center of the scope box.
This time the code is not that elegant but it gets the job done.

Here you can find the macro. If you're happy with my code, please show me some gratitude Paying What You Want via PayPal to:

giovedì, luglio 10, 2014

Copy Links macro

Inspired by this post by Luke Johnson of What Revit Wants, I thought I could write a macro to achieve the same goal but in a cleaner way, without doing copy/paste gymnastics.
Running this macro will copy all the Revit links from a source document to a destination one from which the macro has been launched while having the documents both opened in the same session.

Here you can find the macro. If you are happy with my code, please show me some gratitude Paying What You Want via PayPal to:

Little Revit to Blender tutorial

After last post I was asked by Julien Benoit to do a tutorial, so here we go, it's not a complete guide but it's a quick overall look of the process, from the installation of the plug-in to the set up of a couple of materials in Blender node editor, hope you like it.

Here you can find the Blender files.

mercoledì, luglio 09, 2014

Free plug-in OBJ Exporter for Revit

I was about to start thinking of it on my own but it's already been done and it's free for 2014 and 2015!

Inglegreen has developed this exporter for Revit, now it is possible to use Blender as an open source external render engine, using the amazing capabilites of the Cycle Renderer (real time rendering) that allows you to do also animations and video editing.

Here's the link to the zip file containing instructions and .dll and .addin manifest.
With this plug-in you'll be able to render your scenes within seconds without using any credits and developing even real world phisics inside your model letting your client exploring it like if it is a video game!

Re-posting: How to deal with Legends in Revit by Mark Twain

I've found this very interesting and useful article by Mark Twain on blog

I simply report it because it's another step closer to what I believe is a real standard usage of the Revit platform, headed in the same direction of the tools I've been developing lately. There are fair margins for further developments here.

So many thanks to Mark and the Revit community for sharing your knowledge.

How to deal with Legends in Revit

Edited due to remarks made by Forum users. Some pitfalls for the use of Assemblies added in light of honest comparison between the different options.

First of all:


And breathe...

But seriously: It's an insult to all of us working on real projects needing to do real documentation. I have been on Revit since version 5.1 and it has been useless as long as I can remember (don't even know if there were Legends on that version, but if there were: they sucked back then too).

Why are legends bad?

1. You can only have a few different views: plan view, front and back elevation. How about sections? How about 3D views?
2. No tagging, no way to extract data from the elements (THAT is the freaking purpose!!!)
3. NO connection to the elements actually used in the model. If an element is deleted, it will remain in the Legend. No way of counting elements.

See image 1.

Image1: Useless crap 

So: useless crap it is... The question is: what should it be like then? There are a few options, listed in order of usability:

1. Phases

The easiest to set up, but also the hardest to manage and check for model compliance.

Image2: Adding Legend Phases 

Image3: Creating Legend Views and setting component Phases 

Image4: Creating a coordination schedule 

- Create two extra Phases: Legend and Demo Legend. Place them before the regular Phases, see image 2.
- Duplicate a Plan View, set Phase to Legend and place your Legend components. Select all Legend components and set the options to Demolish in phase Demo Legend, see image 3.
- Create all Legend views you want and Tag away happily.
- Create a Door schedule with 3 columns: Family and Type and Count. In the Properties screen, Sorting tab, sort by Family and Type. Check off "Itemize every instance". You now have a overview of all types in the model. Now duplicate that schedule and set the Phase to "Legend". You can now compare both schedules side by side to see if all elements are accounted for see image 4.


- Total control over Legend views, tagging, and so on.
- No influence over the model, no need to hide things in regular model views
- It's possible to create schedules to check whether all types are accounted for in the schedule.


- Lot of work to set up views.

- No way of distinguishing different instances, there's only a limited amount of parameters that can be used to sort the schedule.
- Needs working knowledge of Phasing
- Needs two schedules and the ability to check them side by side. This could get difficult in large models with lots of types.
- Needs extra "space" in the model to place the Legend components.
- Not very suited for Legend views of multiple components (for instance a room layout, windows with ornaments, window sills and such).

2. Design options

Image5: Adding Design Options 

Image6: Adding elements to a Design Option 

Image7: Setting up coordination schedule 

Image8: Coordination schedule 

A bit harder to set up, but has better ways of checking for Legend-Model consistency:
- Set a Design Option Set called "Legend". Add 2 Options: "Model" and "Legend". See image 5.
- Duplicate a Plan View and place all elements you want to create Legends view from, somewhere outside the model's extents. Due to the setup of the Design Options, they will not be visible in the "normal" model views. See image 6.
- Create all Legend views you want and Tag away happily.
- Create a Door schedule with 3 columns: Family and Type, Mark (or any other text instance parameter) and Count. In the Properties screen, Sorting tab, sort by Family and Type and then by Mark. Check off "Itemize every instance". You now have a overview of all types in the model, see image 7.
- Go to the Legend door, select it, fill out the Mark value as shown in image 8. All the "normal" doors have a blank value.
Image 7 shows us that there is one type in the model that does NOT have a Legend component... This is a fast and reliable way to check whether all TYPES have Legend components. It does not help with instance based deviations...


- Total control over Legend views, tagging, and so on.
- No influence over the model, no need to hide things in regular model views
- It's possible to create schedules to check whether all types are accounted for in the schedule.


- Lot of work to set up views.

- No way of distinguishing different instances, there's only a limited amount of parameters that can be used to sort the schedule.
- Needs working knowledge of Design Options
- Needs extra "space" in the model to place the Legend components.
- Not very suited for Legend views of multiple components (for instance a room layout, windows with ornaments, window sills and such).

3. Assemblies

My new favourite, and very close to what the Legend feature should be:

Image9: Creating an Assembly 

- Place your components in the Model. Select a component and choose "Create Assembly" from the contextual tab. Choose an appropriate naming strategy (I use the family + typename which can expand dramatically when you're creating Assemblies from multiple elements), see image 9.

Image10: Selecting Assembly Views 

- Select the Assembly and choose "Create Views" from the contextual tab. Select which views you want, and if they should be placed on a sheet, see image 10. Tag away happily.
- Select next item, repeat the steps above. IF your element matches an existing assembly, it will turn into the same one, see image 11. Best part: this is on instance level! So if you have different instance parameters, it will be a new Assembly. Only problem: when using a unique Mark value to differentiate between different elements of the same kind.

Image11: Duplicate Assemblies are recognised 

- You can tag the Assembly in the model to refer to these Assembly views. Which solves the Mark problem...
- Create a Door schedule as shown in option 1 and 2. Add an extra field "Assembly Name" to check whether all components have been added to an Assembly.


- Legend Views with the click of a mouse button.
- Total control over Legend views, tagging, and so on. Crop Regions can be rotated to meet specific needs
- No influence over the model, no need to hide things in regular model views
- Simply add a column to your object schedules to check whether all types are accounted for in the schedule.
- Recognizes differences on an Instance Level.
- No extra "space" needed in the model to place Legend components
- Suited for Legend Views of multiple components.
- Easy to use workflow.
- (Shared) parameters can be added to assemblies to allow tagging and scheduling.


- Instance parameter awareness can be a problem, however this is manageable by adding those parameters to the Assembly itself.

- There's no way to port parameter values from the objects inside an Assembly to the Assembly itself without using the API.
- It would be nice to be able to create Embedded Schedules for Assemblies to have both the Assembly AND the underlying objects in one schedule.
- Most annoying one: you need to manually place all elements in an Assembly one by one. No way to batch-create an Assembly. No way to properly place an Assembly when it's (wall) hosted (try placing an Assembly door...)
- MAJOR BIGGIE: Assemblies do NOT update when changes are applied to instance parameters. WTF??? It recognises differences in instance parameters upon creation, but not when changing them? I thought Revit ALWAYS updated modelled stuff? What the hell kind of cad solution is this?
- Adding objects to an Assembly (for instance, adding a windowsill to a window) creates a new Assembly type. Which is in some ways logical, but also a shame. Verdict on this one is still out...
- Groups cannot be Assembled (is that the correct term?). I get this, I think, because Groups are in many ways similar to Assemblies. I can imagine that these two might collide, but it's not perfect.

Legends suck. They suck for text notes, they suck for diagrams, and they suck big time for building components. The first two options described here are at best mediocre workarounds with lots of pitfalls and tons of extra work.

Then there were Assemblies... And all was better.
Provided Autodesk fixes a few minor bugs, it is the documenting feature we have been waiting for, for a LONG LONG time.
As far as I'm concerned, Autodesk can delete the Legend tool all together. I will be sticking with Assemblies for Building components from now on (and Generic Annotations for anything else).

HOWEVER: when you're on big projects with lots and lots of types, this solution might not work for you. Because whenever an INSTANCE parameter changes, you'll need to update all Assembly instances in the project. Which sucks big time. It's doable on smaller projects, and it works well when you're changing type parameters. But not when changing INSTANCE parameters. And that is a shortcoming well worth noting. (off course, you could do a "select all instances" > change, but it's the principal of things)

O, I added my sample files to this thread on

Happy Reviting,

Mark Twain