lisa-marie mueller

lisa-marie mueller

bullet pont

ViewFamilyTypeId link

October 18, 2019

Laptop with code on screen, toy bird, toy rocket This week we continue on the path to automating interior elevations. As a reminder, I have been building a plug-in that automates various parts of creating interior elevations, and I will continue to develop it. Since this project will evolve as I continue, I have determined to set my primary goal for each stage. With this goal in mind, I will develop a functioning piece of software to meet the goal. Then I will discuss topics that cover key aspects for each step for building the plug-in. At the end of each stage, I will move the plug-in to a public repository on GitHub so you can use it too.

if you missed it:

Part 1: filtered element collector [c#]

Part 2: finding centroids and considering exceptions

primary goal #1

Create interior elevations for all placed rooms, place the tag at the center of the rooms, place the tag on the correct level when multiple levels exist, ensure the tag is visible on the interior elevation key plans (already in the project), and ensure the interior elevation tags have the proper phase settings

FindFamilyTypeId

To place an ElevationMarker we need four parameters:

  • Document parameter - the document in which the ElevationMarker will be placed
  • ElementId parameter - ViewFamilyTypeId sets the type of view that is being created
  • XYZ parameter - coordinate to place the elevation
  • Integer parameter - the scale of the view

The document is just a variable that we will declare, we already found our XYZ parameter in Part 2, and for the initial build, I will hard-code the scale. That leaves us to find the ElementId parameter which needs to be the ViewFamilyTypeId used for the elevations that are hosted on the ElevationMarker.

You will need an interior elevation View Type within the Revit project you are working with. I recommend you set this up already in your template. Check the Autodesk Knowledge Network for instructions on how to create a new View Type. To gather our ViewFamilyTypeId, we can use our favorite, a FilteredElementCollector. We need to filter for ViewFamilyTypes and of those, we want the elevations where the name contains “interior”. If it returns null, we need to throw an exception so the program doesn’t crash and our user knows the error that occurred.

Now we can start putting together our method that will place our ElevationMarkers. We are not returning anything so we want a public void method. We will call it PlaceElevations and it will need a few parameters Document doc, XYZ center [which we found in Part 2], and a ViewPlan [which we will discuss next week]. We use the CreateElevationMarker method in the ElevationMarker class using the paramters we have now defined. This method returns a new object of type ElevationMarker.

resources

If you want to learn to code and don’t know where to start check out my posts about Steps to Learn to Code [for architects and designers] Part 1 and Part 2.

Revit API Docs

bullet pont

finding centroids & considering exceptions link

October 11, 2019

Laptop with code on screen, toy bird, toy rocket blue This week we continue on the path to automating interior elevations. As a reminder, I have been building a plug-in that automates various parts of creating interior elevations, and I will continue to develop it. Since this project will evolve as I continue, I have determined to set my primary goal for each stage. With this goal in mind, I will develop a functioning piece of software to meet the goal. Then I will discuss topics that cover key aspects for each step for building the plug-in. At the end of each stage, I will move the plug-in to a public repository on GitHub so you can use it too.

if you missed it:

Part 1: filtered element collector [c#]

primary goal #1

Create interior elevations for all placed rooms, place the tag at the center of the rooms, place the tag on the correct level when multiple levels exist, ensure the tag is visible on the interior elevation key plans (already in the project), and ensure the interior elevation tags have the proper phase settings

GetCenter

Today, we will write the method that finds the center of all of our rooms. We need to find the center because to place an ElevationMarker using the CreateElevationMarker method, we need an XYZ parameter (known to most of us as a coordinate). I have chosen the center of the room for this purpose.

The new public method needs to return an XYZ parameter, and we can call it GetCenter. The new method accepts one parameter, the list of rooms that we found in Part 1. Let’s find the center! Finding the center of the rooms would be perfectly fine if every room in all of our projects were rectangular. The truth is, they are probably not. If we think back to math class, what we are actually finding is the centroid. Thankfully, finding the centroid has a very simple formula, average the coordinates of the corners for a 2D shape.

From reviewing our math skills, we have determined that we need to get the corners of the room. First, we need to collect the BoundarySegments of each room and then we can get the start and end points of each BoundarySegment. When using the GetBoundarySegments method, the default value of the SpatialElementBoundaryLocation Enum is the finish surface boundary of the wall, for our case this is fine because we are just placing a tag. I specifically defined this parameter in the code so others looking at it would remember that the method is using the BoundarySegments at the finish surface location, especially if they aren’t as familiar with the Revit API.

Another item we need to remember from using Revit is that rooms can exist in your project even if they are not placed or are not bound. This is why we want to incorporate an “if statement” so that we only find the end points of the segments of the rooms that are bound, ei when the segments are not equal to null. If our program tries to find the endpoints of segments that are null, it will crash. Once we collect our endpoints, we can find the average for the X-, Y-, and Z-axis and create a new XYZ variable to store this coordinate. Thankfully, LINQ has a method for averages that we can use. You may have realized that we are double counting all the corners of the room since each segment overlaps endpoints with the adjacent segments. Because we are finding the average and each end point is counted twice, it does not affect our calculation.

exceptions

If you think about a few possible common shapes for rooms, one that comes to mind is an “L” shaped room. Depending on the proportions, it is possible for the centroid to end up on the edge of the room or very close to the edge. If the coordinates we use to place our ElevationMarker are outside of the room, our program will crash so we need to write in a few “if statements” to confirm the centroid is in the room, and if not we need to throw an exception. For our case, I choose to first check if the center we found is in the room using the IsPointInRoom method. If it is, perfect. If not, we move the coordinate one unit in the positive direction of the X-axis, and then check if it is now in the room. We repeat for the negative direction of the X-axis as well as the positive and negative directions of the Y-axis. This covers all our bases because a centroid will never fall outside of our room boundary, regardless of the shape. However, it is possible for the centroid to fall on or near the boundary line which Revit may not be happy with. If something went wrong and the centroid is still outside of the room, it will throw an exception so the user knows what happened.

When discussing “L” shaped rooms, we should also consider that they fall into a special category. We need to place two elevation markers to show all walls. For our Primary Goal #1, this aspect is too detailed. Software development is an iterative process and it is better to finish a functioning plug-in that covers 75-80% of your use cases, then to get caught up in every “what if” situation and never finish. For now, we will put this on the wishlist of features to add in the future.

And there we have it. We just found the centroid of all of our rooms. This is one method that can be used for many different applications, so I will likely pull it out into a utility class. [edited 10/16] Next week, we will take a look at the ViewFamilyTypeId which is the last parameter we need to place the ElevationMarker.

summary of code

resources

If you want to learn to code and don’t know where to start check out my posts about Steps to Learn to Code [for architects and designers] Part 1 and Part 2.

Revit API Docs

bullet pont

filtered element collector [c#] link

October 4, 2019

Laptop with code on screen, toy bird, toy rocket Whenever I start a new set of Construction Documents in Revit, there are certain tasks that I -and I’m sure many of my colleges and even many of you- despise. This is how my ‘Automation Wish List’ has developed. Every time I do something I dislike doing, I put it on the list. I have chosen one of these topics to cover first, interior elevations. Since I work primarily in the Civic sector we work on the interior design for our projects, all of our rooms have interior elevations, and the interior elevations often get quite detailed. I have been building a plug-in that automates various parts of creating interior elevations, and I will continue to develop it. Since this project will evolve as I continue, I have determined to set my primary goal for each stage. With this goal in mind, I will develop a functioning piece of software to meet the goal. Then I will discuss topics that cover key aspects for each step for building the plug-in. At the end of each stage, I will move the plug-in to a public repository on GitHub so you can use it too.

primary goal #1

Create interior elevations for all placed rooms, place the tag at the center of the rooms, place the tag on the correct level when multiple levels exist, ensure the tag is visible on the interior elevation key plans (already in the project), and ensure the interior elevation tags have the proper phase settings

getting started

To start, we need to collect all the rooms in the project. This is how we will find the center of the room and place the tags. To find the rooms, we will use what I have determined is, for myself, the most important and most used building block of the Revit API. I would describe the Filtered Element Collector class as a queryable collection of Revit objects. If you are new to programming, it takes all the elements in your Revit model and puts them in a bag. Then it allows you to filter out elements you do not want based on parameters you provide. After you filter, you have the elements you wanted left in the bag. In programming, you actually have to keep those elements somewhere and this will generally be a list or a single object, depending on what you need. For our case, we can very quickly collect all the rooms and store them in a list.

Next week, we will find the center of the rooms and take a look at some exceptions we need to consider so our program doesn't crash.

resources

If you want to learn to code and don’t know where to start check out my posts about Steps to Learn to Code [for architects and designers] Part 1 and Part 2.

Revit API Docs

bullet pont

back from break oct. 4 link

October 2, 2019

Poster with text back from break

Thank you for your patience. I had to take some time to finish up new content, and I am thrilled to announce that I will release it this week! Check back Friday to learn about my next series and to jump into the Revit API. See you then!

bullet pont

gone to the beach link

August 30, 2019

Watercolor paintings in frames with 'Gone to the Begach' sign

I'm enjoying a holiday at the moment but will be ready to jump into more content upon my return. See you September 14!

bullet pont

steps to learn to code [for architects & designers] part 2 link

August 23, 2019

Coding books, clock, and telephone Once you have identified which programming language to start with, it’s time to evaluate how you want to learn. For help with choosing a language, take a look at Steps to Learn to Code [for architects & designers] Part 1. Evaluate your learning style and figure out how you learn best. Some flexible options include online with set deadlines, online at your own pace, and in a classroom. Also, evaluate your budget for learning to code for both time and money.

community college

Community colleges offer both classroom and online classes and tend to have more flexible schedules including evening courses. If your local community college does not offer a class that fits your needs, you can look at any community college in your state to see if they offer an online class that works for you. Community college classes have the benefit of a verifiable curriculum, a transcript as proof of completing the course, a low cost, and a dedicated teacher with a smaller number of students. Even for the online classes, you will most likely be able to interact with your teacher and your classmates. Community college classes do have more regular homework assignments and tasks to complete and they are on a schedule so there are deadlines and final exam dates set for you. This works well if you appreciate the accountability.

My first coding class was through a community college, and I decided to take an online class that worked better for my schedule at the time. I appreciated the deadlines because it allowed me to make completing the class a priority for myself.

massive open online course (mooc)

There are many online options offered by both top universities around the world and by independent content developers. Some are free, some are paid, but generally, even those that are paid are a low price. I do want to advise that some online courses offer that you can pay for a certificate of completion. I would always be wary of this as you can easily prove your coding skill level and it is likely that the certificate of completion will not be necessary. MOOCs have the benefit that they are online, many of them are free or very low cost, they have reviews from others so you know what you are getting, and they can be completed on your own time with no deadlines. This can be great if you like to set your own goals and schedule.

I have participated in a few different MOOCs that ranged in hours of content and included both free and paid courses. I was able to find a handful of free classes that I enjoyed. I have, however, also found it useful to pursue some of the paid courses. These are usually offered for a very low fee. I have not had to pay more than $20 per class, and many times the courses contain 30+ hours of content. I would recommend you make sure to buy these courses on sale, as the sites have frequent sales.

bootcamp

Bootcamps are fast-paced, intensive coding camps. There is a much higher cost of attending a bootcamp and most are in-person classes. The benefits of a bootcamp are that you can learn a lot in a short time, you have professional teachers, and you learn a wide variety of skills and best practices. It is important to note that there are mixed reviews about bootcamps. I have not completed a coding bootcamp, but know individuals (even at tech companies) that do agree that the skills gained at a bootcamp can get you to a level that would even allow you to change careers if you are interested in pursuing development full-time.

From what I have researched when I was considering joining a bootcamp, you get out of it what you put in. I choose not to attend a bootcamp because I did not want to switch careers and I felt bootcamps were too high of a cost for what I wanted to learn. I started with online and community classes instead.

forge your path

There are countless routes you can take to becoming a developer. For every path, you have to put in the time, but it is rewarding to learn a new skill. Regardless of which path you take, I feel that it is most important to make it fun! For example, if you like computer games, take a C# class that teaches you to code while making computer games. Keep learning to code fun for you and you will be much more successful. It is important to remember, that coding is a new skill and you will not learn it overnight, but putting in the time will open many new possibilities.

bullet pont

steps to learn to code [for architects & designers] part 1 link

August 19, 2019

Since as architects and designers we have already spent many years at university or in architectural practice (or both), it is unlikely that we want to go earn a computer science degree. We need solutions that are flexible and can be implemented while continuing our career growth. The good news is that there are countless resources and the number of self-taught professionals has long been on the rise [1].

As I discussed in my series exploring Dynamo (Part 1 and Part 2) and custom Plug-Ins (Part 3 and Part 4), coding is a life skill. It can apply to many different areas of your life and work. Here are a few examples of some of the things you can do:

  • Search through or find-and-replace text in multiple word documents even within multiple levels of folders using Powershell (handy for specs)
  • Quickly mass download all resources after a conference
  • Explore the power of VBA in Microsoft Office
  • Create your custom website

Desk with computer, mouse, and books After I began scripting in Grasshopper in 2013, I realized that I loved it. At one of the internships I had while in university in 2016, I worked for a larger architecture firm that had a well established digital practice. While working with the urban design group, I was able to utilize and further develop my skills in Grasshopper for the projects they were working on. One week, I was faced with a problem that Grasshopper nodes couldn’t solve very smoothly and I decided to jump into Python. Soon after, I began looking at resources to continue to learn to code. I consider myself an amateur coder. I love coding to assist with repetitive tasks in my professional life, but I’m not writing software every day or even every week. I also recognize that there are so many areas that I can still grow and learn. I actively pursue becoming a better programmer. There are a few items to consider as you begin or continue your journey of learning to code.

establish your goals

I’m a huge fan of setting goals when you want to start something new. Based on conversations with other industry professionals, I have most frequently come across the following interests in programming:

  • Create custom nodes for Dynamo or Grasshopper graphs
  • Create new tools using resources like PyRevit
  • Research new technologies and dive into AI
  • Develop custom plug-ins
  • Become a software engineer

choosing a language

One aspect that I appreciate about learning to code is that once you grasp the overarching concepts, you can apply it to any language. There are many different paths you can take and many resources I love (and I’m sure just as many I haven’t yet discovered). The two most common languages used in our industry are Python and C#.

python

Main uses for our industry: custom nodes in Grasshopper and Dynamo, diving into AI, creating tools in resources like PyRevit. If you want to get into the weeds, the language you are using in Grasshopper and Dynamo is a version of IronPython 2.7 which basically is the same as Python but does have some limitations. (Caution, it does not support dictionaries or other Python 3.x features). The exact version of IronPython depends on your version of Dynamo. The Dynamo forum has lots of great discussions on the topic.

c#

Main uses for our industry: writing custom plug-ins, creating interactive environments in Unity, developing programs. C# is the standard used in many industries and is feature-rich. You won’t run into the same limitations as you will with Iron Python in Dynamo and Grasshopper.

Which language to start with depends on your goals, so once you’ve identified those, you can better outline your path. Evaluate the tools you are using now and where you want to progress to. As I mentioned, once you have learned one language, transitioning to another is easier as many concepts carry over. Check back next week for more informaton about where to look and how to get started. I will also discuss resources that allow you to learn to code while maintaining your current responsibilities.

[1] The Rise of the Self-Taught Programmer by Cory Althoff

bullet pont

dynamo vs plug-ins (part four) link

August 9, 2019

Explosive image with the words Dynamo vs Plug-Ins This topic has been tackled in four parts, check out my posts from July 31st and August 2nd for the overview of Dynamo and August 7th for the initial discussion of custom plug-ins.

testing and implementation

Apple computer with quote If you are developing plug-ins, you are developing software. With that, it is important to implement a development plan.

There are many resources covering agile software development that dive into best practices, but it’s pretty straight forward. In general you will need to:

  • Write the spec and determine your minimum viable product (MVP)
  • Manage the project (like any project) by setting milestones and sprints
  • Determine and implement a testing procedure (code and beta testing)
  • Iterate on the process until you meet your goals

You can use all the skills you already use to manage your projects or implement Dynamo scripts to develop plug-ins.

If you are willing to dive in to Dynamo and coding and establish script and plug-in libraries at your firm, it is likely that you are an eager adopter of new technology. You embrace change and new things and are willing to try and fail in order to work towards something bigger. Remember: change is scary for most and adopting new technology can be daunting. This is a challenge that is the same for plug-ins and Dynamo. For many people, if software doesn’t work, they may begin to loose trust in your implementation team and not use new plug-ins you develop in the future. A key way to prevent this is to implement a beta testing system. Identify users that will provide honest feedback for the software you develop and that will keep using your software despite running into bugs. As with scripts in Dynamo, just because a program runs on your machine without problems, doesn’t mean it will run on the machine of your co-worker.

adoption and use

The past few years, my firm has been tackling automation. Originally our journey started with Dynamo. Recently, we have decided to shift our focus, adjust our targets, and refocus our energy to develop custom plug-ins for our firm to use. It is a slow process, so we have not yet rolled out any plug-ins to the entire firm, but we hope to be beta-testing early next year.

I can let you know that based on implementing open source plug-ins created by 3rd parties, we have had more usage out of plug-ins than the Dynamo scripts. It is currently challenging to track statistics because we cannot accurately gather data. When we roll out our custom plug-ins, we plan to incorporate features to provide us with feedback on usage so we can evaluate each plug-in we develop. I’m looking forward to getting back telemetry data to evaluate teams usage of our tools, and I will keep you posted on our findings.

Custom Plug-In Pros:

  • No dependency on other users/content creators
  • More control over interface
  • Access to entire Revit API

Custom Plug-In Cons:

  • Requires knowing how to code using C#
  • Requires additional software to compile
  • Trouble shooting and testing can be a longer process

and the winner is...

When you have a complex problem, there are many solutions. For automation, there will always be the conversation of Dynamo versus custom plug-ins. There is no correct answer, and frequently the answer is both. Teams who want to quickly develop solutions for their project can jump into Dynamo and write a script to make their process more efficient. Those leading the firm’s digital practice can put together plug-ins for the most common tasks that benefit the entire firm. Currently, our firm has implemented goals for Revit plug-ins (custom, open source, and purchased) to assist with our process. Take a look at your process and where you want to see your firm going. There are many pros and cons for both methods of automation, but only your team can determine the best strategy for you.

Check back next week to find out how I learned to code and where you can go to start your journey to developing a workflow that’s right for you!

bullet pont

dynamo vs plug-ins (part three) link

August 7, 2019

Explosive image with the words Dynamo vs Plug-Ins This topic will be tackled in four parts, check out my posts from July 31st and August 2nd for the overview of Dynamo, and come back Friday, August 9th for the wrap up of custom plug-ins.

As we have covered, Dynamo for individuals is fantastic. Dynamo at a firm brings some challenges, but if you have a system in place, you can implement it successfully. In my opinion, Dynamo is best deployed when the firm is small enough that you don’t need full-time resources dedicated to package and script management or when it is large enough to have full-time resources dedicated to package and script management. So what if your firm is in the middle? There is an alternative, but it involves the c-word: coding.

custom plug-ins overview

Apple computer with quote I always get excited when I find out “there’s an algorithm for that”. You can create custom plug-ins that do exactly what you want to do and that jive with your company standards. Coding is a longer process than scripting in Dynamo, and you need to learn how to code, but it’s 2019, coding is a life skill. You will use these skills to write VBA scripts for Microsoft Office or to use Powershell to automate tasks. You will quickly realize that there are simple things your computer can do for you every day. Once you start coding, you’ll want to apply it to everything.

the learning curve

The barrier for entry to developing custom plug-ins is higher than for using Dynamo. To create custom plug-ins, you need to learn how to code. Thankfully, we are in the 21st century and countless resources allow you to learn on a flexible schedule. You don’t need to study computer science to become a programmer, and you don’t need to be a software engineer to write successful programs. It doesn’t mean it’s easy or that you can pick it up in a weekend. However, if you dedicate time to learning how to code, you can be successful.

fewer scripts, fewer functions

Once you get into it, you will quickly see the benefits of coding. To put it simply, the functionality provided by large Dynamo script libraries can be provided with fewer plug-ins. For example, one of the complicated items of Dynamo is that it is more challenging to set up a run order. You have to use nodes from packages like Clockwork, but even then it gets complicated quickly when you are trying to run five related functions in a specific order. At this point, I just separate the scripts and run them individually. This leads to five scripts in the library instead of one. When coding a plug-in, it is super easy to call functions in a specific order, trigger events using if statements, and provide all functionality related to a certain item in one single plug-in.

The second part of this is that because scripting in Dynamo is intended to allow designers access to programming tools, the nodes are simplified. This equates to you having to string together many different nodes to receive an outcome since these nodes need to work in many different ways. When it comes down to it, a Dynamo graph with 100+ nodes can most likely be written in a couple of dozen lines of code. If you’re willing to commit the extra time to develop plug-ins, you can accomplish more functionality with each plug-in and there are ways to reduce maintenance tasks versus keeping a Dynamo script library.

See you Friday, August 9, to read about strategies for testing and implementation and what our plans are for custom plug-ins.

bullet pont

dynamo vs plug-ins (part two) link

August 2, 2019

Explosive image with the words Dynamo vs Plug-Ins This topic will be tackled in four parts, check out my post from July 31st for the initial discussion about Dynamo and come back next week for the angle on custom plug-ins.

dynamo: no coding required*

Whenever I see an asterisk, I immediately look for the catch. Well here it is:

*Some coding required

The Dynamo community is indeed excellent. Thankfully there are a lot of people who are solving common problems by creating new nodes and releasing packages for all to use. However, it is possible that the problem you are trying to solve may not have been solved before or it may not have been solved exactly the way you needed it to be. This is especially true for items related to firm standards that may be unique to your office. Dynamo does allow you to code your nodes to increase customization, but now we’re back to ‘some coding required’. From personal experience, I found that after getting into Dynamo, I quickly wanted to do more and needed to apply my coding skills to tackle all the problems I wanted to. I’ll touch more on this when I discuss custom plug-ins next week.

our dynamo library launch

Rocket launching with quote For the past one and a half years, myself and two co-workers have worked to develop Dynamo standards, build up a script library, introduce scripts to the firm, and help people save time with Dynamo. We are a mid-sized firm with about 130 people using Revit across many different market sectors and four different offices. For our initial launch, the team and I were targeting scripts that would work for everyone. We wrote clean scripts that were clearly labeled but did not have any additional user interfaces or feedback incorporated into the scripts. About a year ago, we held one of our monthly Revit Forums, and we introduced the key scripts to everyone. It was one of our most attended meetings. People were so excited to start using Dynamo, and we were excited that everyone was ready to dive in. We were geared up to answer questions, help work through any problems that we were sure would arise, and keep everyone excited about Dynamo. The next day, I heard nothing. The next week, I heard nothing. The next month, crickets. People were not using the scripts.

One mistake we made was that we did not have a user interface in place. We made the scripts very clear and easy to understand. We highlighted all the inputs in blue and gave people clear directions on what they had to change. But, users had to open Dynamo when inputs were involved. They had to look at the scary graph, and it was too much. To have a successful user base, you need to provide a clean user interface. 

Another thing wasn't quite right. We did a poor job of timing the release. Not everyone had a project in a production stage in which the tools would be useful. When that time rolled around, they had forgotten. The only reference we had back to the education session was a video of the session itself. There were no handouts, no quick tips, no reminders. We did not provide enough education. Providing written information with visual aids about what each script does and how to use it will help adoption. People will have something to refer to next time they want to try it. People are more willing to try new things if there is support for them.

I think it is a challenge for mid-sized firms to implement Dynamo. At the firm I am at, we have agreed to not have an individual as a BIM Manager or Computational BIM Specialist. We do not have one individual who spends their entire time creating, updating, and managing a script library. From conversations with people at other firms, this is almost necessary to have success with Dynamo scripts in a firm larger than a couple of dozen people. It takes a significant amount of time to maintain existing scripts and even more time to create new ones and grow the library. In my opinion, implementing a Dynamo library at a firm for regular use is best suited for a firm that can dedicate full-time resources to the process or a firm that is small enough that they don’t have to dedicate full-time resources to the process. But don’t despair if your firm is not interested in dedicating full-time resources to Dynamo development and maintenance. Next week we’ll jump into custom plug-ins which provides an alternative with no packages to manage.

dynamo pros

  • Accessible
  • Fast
  • No coding required*
  • Large community for content and support

dynamo cons

  • User interface challanges
  • Tedious package management at a larger scale
  • More limited Revit API access

If you want to jump into Dynamo, I would recommend:

The Dynamo Primer
Learn Dynamo
Data Shapes for user interfaces