An intermediate Revit user should be able to work with this add-in with little to none extra effort to figure out what is what, and many of the concepts below are pretty self-explanatory. There are also some tutorial videos that’s much intuitive to follow than pure texts.
However, there are always times when you are in double of what you are seeing in front of you, and these texts may help shedding some light. If you still have question, or some brilliant suggestion for improvement, feel free to reach out and I will be very happy to help.
Browsing through Revit Ideas forum, it is amazing to find that so many great ideas, or very often, complains, are all pointing to the same big issue: access and control of data. People are asking questions like why we cannot get the same amount of data, if not even more, into schedules as what’s showing on UI. Myself as both a user and an add-in developer, understands the needs and dilemmas of both sides. While Autodesk is constantly improving their product (this Revit Idea forum is a great idea by itself, and I can see that Autodesk is seriously improving Revit by adding what the users are asking for), it cannot possibly address every single demand from the users. That’s the reason we have Dynamo and Revit API, with which we can programmatically access model data and create specialized workflows that solves our individual problems. While Dynamo is a powerful tool, it’s interface and workflow requires learning and adaptation, making it hard to truly become part of daily routine for most users. Also, there are still lots of functions that are available in Revit API, but not yet in Dynamo. Therefore, if we want one simple tool that covers the basic needs of data access and control, Revit API is still the best place to go.
So here we are, we have this add-in called “123 Search” that set out to address this very problem with a simplistic approach of design. The goal is to allow us to get maximum flexibility in terms of ways to access and control data, with a relatively flat learning curve, and as few “clicks” as possible.
It is called 123 Search because “search” is the starting point of any data control, and quite often, a nicely filtered search is all we need. The add-in allows us to search the model database in various ways, show these data, and get them ready for further interaction.
Element vs Object
There are lots of “things” in a model, and we all know that the things we can put on a schedule are only a small part of all the things in a model. We can label them “schedulable” or “non-schedulable” if we want. Similarly, we can (roughly) put all the things into two groups decided by whether they are searchable using Revit API. Those that are searchable are called “elements”, and all the rests I would just call them “objects”. The good news is, elements contains all the schedulable things, as well as many others, such as texts, dimensions, detail items, etc. So that’s a good start of full access to data BUT (there is always one), those non-searchable objects also contains valuable data. We will know some of those objects soon when we look at how to get those data.
We all know that objects in a BIM model are inter-connected, and if we try to visualize a model, it will be more like a network with nodes and connections. If we want to get to some data out there in the model, we need to start from searchable 3D and 2D elements, and travel along a “path” with one or more “nodes”. For example, if we want to get the material of each layer inside a wall, we know how to do it in Revit UI: select one of the wall, get its wall type, then get its “structure” which contains all the layers, then finally we get the material for each layer. There is a similar, but not exactly the same “path” to get the same data use this add-in. I call it “data path”, it works like a set of navigation instructions. Once a path is established, it can be used on other elements, and retrieve the same type of data. The layer material is an example of a path with multiple “nodes”, at each node there is an instruction pointing to the next node, in that example the nodes are: wall -> wall type -> structure -> layer -> material. Very often what we need is only one node, which points from the element to one of its parameters.
Every Revit element has its parameters, which we are all familiar with in Revit UI. With Revit API, we can usually access the same or more data than Revit UI. In Revit API, each element has parameters, as well as “Methods” and “Properties” (these two words are programming terms). These methods and properties sometimes gives us data that’s not available from one of the parameters. I dubbed the word “feature” for all three: parameters, methods and properties, because they serve the same purpose when we navigate data out of the model. Those non-searchable objects also have their own features, and that’s how we get to the material information in the wall layers example.
We can setup our search in various ways, and save it for later use. One thing that worth noting in search setup is the difference between “category” and “class”. These are two ways to put elements in groups. Category is the way we are seeing on Revit UI: elements are put into groups like walls and windows, and Revit uses these same categories when setting up parameters and schedules. On the other hand, the concept of class is essential within the world of computer programs, and here it serves another way to start our search with defined groups of elements. Very often a category can find its counterpart class, e.g. category “walls” and class “wall”, and they point to the same group of elements. There are also cases when these two does not match. Depends on what we need to achieve, one way might be better than the other, we will need to try before we know.
Once finish setup and click “search”, the add-in will search for all elements inside model that meets all the criteria, and display all the feature values in a table view. Each row of this table is one element, and each cell of that row is one feature of that element. We can “explore” and get inside a feature value if that value is not just basic values like texts and numbers, and create data path to get the data we are after. Once we have our new data path ready, we hit “search” again, and each data path will create a new column that contains the data it brings, just like other object features. Refer to the tutorial video, since it is a much better way to demonstrate.
With all the features and data paths available, we can go to “interaction” tab, and the add-in will take a look at each of them, decide in which ways we could change its value. In this schedule-alike interface, we can batch-assign new values, or utilize the might of Excel spreadsheet to populate value the way we want. Note that for now, model interaction only supports changing values of parameters, not methods and properties.
Specialty Function Packages
The search and interaction function serves as the base interface for all other specialty function packages, such as “spell check” and “power key schedule”. These specialized packages are intended for those items that’s high on users’ wish-list. I am eager to hear your saying of what should be the next package, and we can work together to make this tool better.