Wednesday, 30 December 2015

Scopeboxes

Just another trick about scopeboxes. Imagine you have a design from which a floorplan looks like this.
Setting up a project north to draw orthogonally is only going to help you for one part. But what about the other parts. Use scopeboxes!



Draw 3 scopeboxes
Rotate the scope boxes accordingly

Assign the grids to the proper scopeboxes
Create 3 views
Assign each scopebox to its own view 

Friday, 18 December 2015

Revit builds

Recently I received a family that was behaving strangely. Before putting it in a project it was only 552 KB big. After adding it to a specific project it and opening it from that project and saving it as a new file it grew to 45.052. Although many would argue that filesize means nothing I still thought this to be odd. I closed the project and I only opened this lovely family. Take a look at the screenshot of my memory usage.

After asking question I learned that people were using different builds of Revit 2015. It's always been advised to make sure that people who work on the same project use the same build.

You can use the journal files from Revit to find out which build has been used.
Typically you should be looking for the 3rd and 4th line:
' Build: 20151007_0715(x64)
' Branch: RELEASE_2016_SUNRISE

' Build: 20150511_0715(x64)
' Branch: RELEASE_2015_SUNDIAL

Notice that Revit 2015 and 2016 both start with 2015 I assume that it's the date of the latest patch.

Besides those build numbers it might in some cases also be good to take a look at the :< Document save history

This journal file indicates that the Revit project file has seen quiet a few of different builds of Revit.

     ' 7:< Document save history --> :
     ' 7:<   Revit 2013 2013 (2013.000) : 20120221_2030(x64)
     ' 7:<   Revit 2013 2013 (2013.000) : 20120716_1115(x64)
     ' 7:<   Revit 2013 2013 (2013.000) : 20121003_2115(x64)
     ' 7:<   Revit 2013 2013 (2013.000) : 20130531_2115(x64)
     ' 7:<   Revit 2014 2014 (2014.000) : 20131024_2115(x64)
     ' 7:<   Revit 2014 2014 (2014.000) : 20140709_2115(x64)
     ' 7:<   Revit 2015 2015 (2015.000) : 20150127_0715(x64)
     ' 7:<   Revit 2015 2015 (2015.000) : 20150303_0715(x64)
     ' 7:< Document save history <-- p="">
This family ended up with a more than 6500 standard materials in the file. I did manage to purge it but it took 4 hours for the analysis part of the purge commando to finish.

I was refered to a German site for instructions and a download to do this for you:
delete standard materials
Put it through google translate and you should get it to work.

Thursday, 17 December 2015

Revit file size

In a recently lively debat on twitter we were talking about Revit file size. Let's first state that file size in it self is not important. Performance is what matters. If performance can be defined as: The accomplishment of a given task measured against pre-set known standards of accuracy, completeness, cost, and speed.

Hopefully at the beginning of the project you have defined which BIM use you want to service with this information model you are creating. So the performance of the project will be measured against the intended BIM use.

So no word about file size yet. Why do I care about file size. I use the file size of families and projects for a small part of Revit projects health checks. I take a look at file sizes when I open new projects and see how they handle. I have seen huge Revit files that work like a charm and small files that handle like a hung over sleepy turtle on a holiday. So file size for first impressions. So if I get big files that handle very well than that often is a first good sign that that company has got their model authoring well under control. It's not a guarantee it's just one of the metrics.

Next I like to save the file as a new project and purge them. This tends to give me an impression about file maintenance. Proper file maintenance is good for performance. See image below, an example of a set of files that nearly got halved in size by doing some basic maintenance.
Take a look at this post from Toms hardware: gigabit-ethernet-bandwidth. Every bit has to travel the network. Also be aware that unnecessary big linked files are being turned into even bigger temporary files when a project is loaded. Another performance hit.

When I do a health check I tend to start with the biggest files as statistically I am more likely to find issues. I write reports for companies where they could make improvements. (these improvements can be things like view performance, family content, model management, drawing production, model authoring or others)

I also save all the families out of the project and take a look at their size. There are guidelines about what sizes a good families should be. BUT if you know what you are doing feel free to ignore them. I tend to start with the biggest families first. Big does NOT mean bad. Big families just have a bigger chance of modelling oddities that need to be addressed. Or they have a bigger change of speed increases when improved.

To come back about my definition about performance. If the file handles super fast but it does not serve the intended BIM use than it's performance is bad. If it serves the BIM use spot on but it handles slowly, it performs much better. Of course we all try to find the sweet spot where the handling is great and the BIM uses are being served.

To conclude file size can be interesting for some of us. But I advice you to focus on models that serve the intended BIM use.

Wednesday, 9 December 2015

The future of design is code!

Recently we gave a Dynamo workshop to an architectural office. Quiet a few architects were curious what this visual programming could mean to them.

At one point when we were doing something rather complicated. I was trying to help out this one architect and she looked a bit confused at me. To tease her a little I told her the following: The future of design is code. She looked absolutely horrified at me, specially after I told her she would show this to the head architect and ask him to review the elegance of her scripts. :) Of course that will not be the case. But it will be very important for architects and engineers to know about coding. I am not saying you all have to start C++

I think it's important you acquaint yourself with a language that will facilitate and prove your designs. A tool like Dynamo can help you design, change and modify your project and still complying to specific project constraints.

At AU 2015 in Vegas there were at least 28 classes about Dynamo. Dynamo is getting huge momentum now and is rapidly moving forward.

Start simple!
But consider this, every action that you end up repeating is worth considering automating.

For Revit, Dynamo is only the start of what to come. Many more exiting things are coming. I am very curious of what these start-ups from flux.io
will enable us to do.

I started with dynamo quiet some time ago. One of my projects was to design a bridge. At that time I had to rely heavily on excel. Now with more knowledge I can do more and I can do it without excel.I'll blog about it again soon.
A sneak peak:

Happy coding!

Google+ Badge