families

Don’t Have Dimensions in Families for COBie? Don’t Worry!

November 16, 2018Ryan LenihanDynamo, Revit General, Revit Standardsautomation, COBie, coordination, dynamo, families

So you’re new to COBie and a deadline is approaching, your favourite project BIM manager comes up to you a few hours before the deadline and tells you “We have to do dimensions.. on every element in the COBie drop. You have your dimensions ready right?”

Well there is no need to stress, as always there is potential for Dynamo to come to the rescue. I put this one together in Dynamo v1.3, but I have tested it in v2.x as well and it still works just fine, just a note though. If you save your old 1.3 graphs in 2.x, it’s now a 2.x graph forever.

The way that I approach the majority of my COBie work is through a 3D view and a schedule with a set of very hand filters, so I’ve continued down this route for my Dynamo graph and I start it off by getting all the elements in the active view – my 3D COBie view.

Just in case there is anything in the view that isn’t a family I’m getting the element type of each element, convert that value to a string and then filter the list based on the string “family”. This is because every family in the view will be prefixed with Family Type: whereas non-family objects will not.

Once we have the filtered list of families, we need to take the bounding box of each element, we do this with an Element.BoundingBox node. Using Spring Nodes, we next use Springs.Geometry.Extents to separate out each dimension individually.

The next step is a bit of simple math. I want to ensure that the length parameter is always longer than the width, so with a few if statements and some greater than and less than nodes, the top pair of nodes always provide the smaller number that will populate our width parameter and the lower set of nodes now provide the large number which will feed into our length.

Finally, we populate our parameters with the correct information. Note that your parameters must be set correctly to type parameters for this to work, if you have incorrectly made them instance parameters the script will not work but if you’re paying attention you’ll see that the hint is in the name of the parameter.

Now, don’t forget that with the COBie element data, you should be nominating dimensions inclusive of the maintenance requirements for that object, you could always add a little bit of extra fat to your dimensions, but I would highly recommend approaching COBie and BIM in general the right way and including spatial elements that indicate the overall dimensions including maintenance access similar to what is shown in the electrical switchboard below.

For those that want to get stared a bit quicker, I’ve provided my graph for download below

Step by Step Guide – Creating My Iplex FWG Family in Revit

March 16, 2018Ryan LenihanRevit Generalas3500, australian standards, families, family, hydraulics, mep, mep connectors, pipe fitting, plumbing, revit, revit families, revit mep, training

A lot of people ask me if I’ll give them my Iplex floor waste gully family. The answer is always no, not because I don’t want to share, but because I would rather people learn and understand for themselves rather than taking the easy way of “grabbing something from the internet”

I recorded a video on how to create the FWG a long time ago, but after a bit of back and forth discussion on Youtube, I have decided to pull that old video out and record some voice annotation so you can follow along.

I do apologise about the audio quality, I only had my junky work headset to record with.

Yes, this is how I spend my nights in hotels when travelling for work.

Titleblock Integers, Take 2 – Video Guide

February 27, 2018Ryan LenihanRevit Families, Revit Generalannotation, automation, families, family, revit, revit families

A quick follow up to my previous post on titleblock integers with a little more in depth explanation for new users to Revit.

Lookup Tables and You – Part 1 – Understanding Lookup Tables

September 5, 2017Ryan LenihanRevit Families, Revit General, Revit MEPfamilies, mep sizing, pipe fitting, revit, revit families, revit mep, shared parameters

Life isn’t just about Dynamo, so here is something a little different to mix things up.

Earlier this year I spoke at BiLT ANZ 2017, I had the opportunity to present two separate talks of which one was lookup tables. It’s a bit of a dry topic, so stick with me.

Lookup tables for pipe and conduit fittings provide an invaluable enhancement to the MEP workflow that we take for granted. On every project we work on, lookup tables save us countless hours in the modelling process. Without them, modelling a pipe system would require each individual pipe fitting to be sized as you go. It may be only a few seconds lost per fitting, but multiply that by hundreds or even thousands of times across a project. Then consider the revisions across the piping network. Those few seconds wasted quickly adds up.

At their core, lookup tables are simply comma separated value files (.csv) that are used in conjunction with Revit family files. Prior to Revit 2014, these files were stored on your hard drive or in a common network location and that location was referenced by the revit.ini file.

You might have had experience with tiny pipework fittings that wouldn’t size correctly in Revit if the lookup table location was not correctly configured. Nowadays, lookup tables are stored within the family themselves, provided your family content has been properly updated to 2014 or newer the new system with embedded lookup tables should eliminate those tiny fittings altogether.

Most commonly lookup tables are used for defining pipe and conduit fittings based on the nominal diameter of the fitting. Revit is then able to automatically size and resize fittings based on the size for the pipe the fitting is connected to by using the data contained within the lookup table.

The Lookup Table Format

Lookup tables can be created and edited in either a simple text editor such as Notepad or Notepad++ or in Microsoft Excel and it’s alternatives.

The first column is a reference column, the values in this column could be ‘Tom’ or ‘Jerry’ but it’s obviously more useful to give enter data that is relevant to the family being created.

Usually when dealing with pipe and conduit fittings this is the nominal diameter, when dealing with pipework branches, I like to format my references as Upstream x Downstream x Branch so for example, 100x100x65. You could however include product names, say if it was a 5000 litres grease arrestor, the reference could be GreasePit5000

The second column defines the lookup value which is typically the nominal diameter of the fitting. This is the column that Revit will look up to determine the remaining parameters for the element.

The formatting of the headers within the csv file is

ParameterName##ParameterType##ParameterUnits

which you can see in the example above. The formatting of the headers is critical for the lookup tables to work.

In column B of the example, we have ND##length##millimeters (note US spelling of millimetres) which in this to the nominal diameter, it’s a length parameter and the units are in millimetres.

If further lookup values are required, say for example in the instance of a pipework branch, more lookup columns can be added as needed, shifting the remaining columns to the right.

As you can see in the above example, we have three nominal diameter columns to determine the size of our fitting.

The remaining columns after our lookup columns contains the data that drives the modelled dimensions of the Revit family and you can have as many lookup columns as you need to generate your family.

How Lookup Tables Are Used in Revit Families

Lookup tables are stored within the family file itself through the Manage Lookup Tables dialogue. The lookup table is then referenced using a text based parameter and lookup formulas are used to retrieve these values from the lookup table.

Importing and Referencing the Lookup Table

To import the lookup table, you first must open the family file itself. In the family types dialogue box, click on the Manage Lookup Tables button.

Once in the Manage Lookup Tables dialogue, you have the option to either import or export the lookup tables contained within the family.

If you’re starting with a family that already has an associated lookup table, it’s always a good idea to start by exporting the original lookup table so you can use that as a base and then modify.

Once you have a completed lookup table, you can import it in the Manage Lookup Tables dialogue. You can have multiple lookup tables within your family files and chose whichever is required.

Once the lookup table has been imported, you need to add a text parameter to the family that references the lookup table name. Historically this parameter has been named Lookup Table Name although you can name this parameter anything that you like, it’s best to remain consistent with the out of the box parameter naming.

When filling out the parameter data, it needs to match the name of the .csv file that you are going to use, minus the .csv extension.

Lookup Table Formulas

The formula used to reference the lookup tables is

size_lookup (Lookup Table Name, “Lookup Column”, Default If Not Found, Lookup Value)

The format of the formula is similar to that of an if statement.

The first portion of the formula is telling Revit to find a value in the lookup table “Lookup Table Name” for a column named “Lookup Column” and then pull the value from the row that corresponds with the value from the “Lookup value”. If there is no match, Revit will provide the value from “Default If Not Found Value”.

In the example above, the formula is finding the value for the fitting outside diameter.

Stepping through the formula, Revit will lookup the table that has been defined in the parameter Lookup Table Name for a value in in the column named “FOD” that corresponds with the lookup value of the Nominal Diameter parameter (50mm). If no match is found for the nominal diameter in the lookup value column, a value equal to Nominal Diameter 1 + 9.1mm will be returned.

Note that the nominal diameter is currently set at 50mm. If we refer to our csv file we’ll see that our lookup value is ND1 which corresponds with Nominal Diameter 1 in our family.

When ND1 is 50mm we can see that the value of FOD is 56mm, this has set our family to have a fitting outside diameter of 56mm.

What About Multiple Lookup Values?

You may have noticed that the example family used is a DWV pipe branch fitting, so we need to deal with multiple lookup values. The fitting may be a reducing branch or it may have different variations in branch angles.

To achieve this, we simply need to add more lookup values to the end of the formula.

In this example we’re looking up the socket bottom to socket bottom run, we are again referencing the same lookup table however this time we’re looking for a match for Nominal Diameter 1, Nominal Diameter 2, Nominal Diameter 3 and Angle in a single row within the lookup table.

If a match is found, Revit will return the value from the column that corresponds with SBtSBR. If no match is found, Revit will return a value equal to that of Nominal Diameter 3 + 27.7mm.

This particular fitting we are working with is a 50x50x50 x 45° DWV branch

Referring to our csv file, we can see that when we look up the values 50, 50, 50 and 45 the corresponding value in the SBtSBR column is 81mm which is the value that has been set in our family.

Remember that the lookup columns need to be in order in columns from left to right to be able to lookup multiple values.

So that’s it for understanding how lookup tables work, stay tuned for Part 2 where we look at applying the use of lookup tables to improve our workflow.

Need Bulk Family Upgrades? You’ve Got Options!

June 27, 2016Ryan LenihanRevit Families, Revit Generalfamilies, family, revit, revit families

So, I’ve been asked maybe 4.. 5 times in the last week or so “How do I batch update Revit family files?” so for those that don’t know how, here is a run down of some of the options available to you

Bulk File Upgrader – US$99

Harry Mattison of Boost Your BIM has written a Bulk File Upgrader program which you can use to upgrade projects, families and templates in bulk. It costs US$99 and has a very simple to use graphical interface which basically consists of selecting the location of files in and files out.

It’s a pretty simple app, it’s built to do one thing and does it well. You can pick it up from the Autodesk App Exchange here

BIMWerx Bulk Upgrader – US$10

This is a relatively new file upgrade addin that was released just this last week.

The batch file upgrader will scan a user specified folder for project files and family files, upgrade them and save them in the same folder. All backup files are automatically removed afterwards in order not to clutter the folder that is being upgraded.

This application requires minimal input, and works great with multiple library file upgrades. You can grab it from the Autodesk App Store.

CADDaddy Tools – US$12.99

Another alternative is to think about what you want to do in reverse.

James LeVieux sells a great little addin called CADDaddy Tools, it doesn’t upgrade files, but it will export families to a folder location complete with sub-folders that reflect the element category. This is a fantastic solution if you keep all (or most) of your families in your base Revit template. Simply upgrade your Revit template or project and then use the CADDaddy Tools family exporter to export all your newly upgraded families.

You can pick and choose what categories are exported and away you go.

The best part is that CADDaddy Tools is only US$12.99 for the latest version (2017) and gets cheaper for previous releases and for that price, you also get a few other handy tools as well. Once you’ve exported your families, if you have the Revit version as a suffix to your file names, there are a number of free file name utilities out there that you can use you rename your files to reflect the correct version.

Journal File – Free!

If you’re up for something ever so slightly more complicated than the other two options, you can use a Revit journal script. I’ve tested this to work in both Revit 2015 and 2016 and it will bulk upgrade files with ease and what’s better is you can do it for free!

First download this file and extract the contents to the root directory of your family library. I suggest you take a copy of your family library to make the changes to so you don’t lose the previous version of your families.

Run the BatchUpgrade2016.bat file, this will start by cleaning out all of your old family backup files (i.e. family.0001.rfa) and then it will create a list named famlist_rfa.txt

Once you have the famlist_rfa.txt file, simply drag and drop the BatchUpgrade2016.txt file onto the Revit icon on the desktop. Make sure you drag it to the correct icon i.e. Revit 2016.

Now all that’s left to do is watch the magic!

13/10/16 – Script updated for Revit 2017 compatibility. Please re-download the file for the updated script.

Using Dynamo to Generate Mark Parameters from Information in Families

July 21, 2015Ryan LenihanDynamo, Revit Families, Revit General, Revit Standardsautomation, coordination, dynamo, excel, families, revit, revit schedule, shared parameters

I recently had a question as a follow up to my bi-direction Excel using Dynamo post

Hi Ryan,

I’m trying to use the same concepts to export all structural columns. The node you used (family types) only exports 1 type at the time.

Do you know if there’s a node that lets me export all types of the column family I use in the project?

The node that you want to use to do this is All Elements of Category which you need to feed with your selection from the Categories node.

I thought I would share an example of how I used this node to generate individual type marks for all the columns on the project based off the family name and the level that the column is located on.

Of course generating the mark parameter from the family name means that you need a fairly solid and consistent naming convention in place. You could also use other type parameters within the family, this is just the method that I chose as an example.

Before we get started, I have used the Revit 2015 Sample Structure Project.RVT file and renamed the family types like so

The overview of this particular example of the Dynamo Script looks something like this, so let’s step through what it is doing.

Getting started, we use our Categories node which we use to select our Structural Columns category. As mentioned earlier we feed that into the All Elements of Category node.

2015-07-13_11-12-25

Stepping through the top row, our elements feed into the Element.GetParameterValueByName node, and we’re picking up the Base Level parameter.

We then pass through to the Level.Name parameter which gives us the level name as you see it in the project browser as a string, which in this case is “01 – Entry Level”. Using the String.Split node we split the string in half using a Code Block node and entering ” “; into the code block to denote the space.

Think of this as the same as the Text to Columns command in Excel.

This gives us a list that splits the level name into

“01” “-” “Entry” “Level”

From here, run the data through the List.Transpose node and then finally into the List.GetItemAtIndex node, here we need the row at line 0 so we use a Number node to define the index.

You can alternatively use a Code Block node and enter “0”; as the code which works the same as the Number node.

On the bottom row we are taking our family type name and pulling out the type itself from the string that is returned. Even though when scheduling the Type parameter returns just the type, the string that is actually returned from Dynamo is in the format of Family Type: CRC 450, Family Name: STR_CONCRETE_ROUND_COLUMN.

So following a similar sequence to the top row, we split the string down to what we want which is “CRC 450”, to do this we need to split the string twice; first by the colon ( : ) and then by the comma ( , ). As you can see in the screenshot we need to transpose the list and pull the data at each row twice to get what we’re after.

At the lower right corner there is a number generator. It is simply stepping from 1 to 200 in increments of one. Make sure to run the Number.Sequence node through the List.Transpose otherwise you will cause Dynamo to lock up while generating incredibly long number strings if you feed the sequence directly into the mark parameter.

Finally, we use a Code.Block node to concatenate the data we have pulled into a single string. The code block is simply a+b+c+d; which gives as four variables of the same name that we can feed the rest of our data into.

I have then created another list which consists of the Element ID and the string, we then finish up by selecting our string and populating the mark parameter as per my bi-directional Excel post.

Of course there are other options where you can generate the mark parameter from other type parameters in the family, I just chose to use the type name as the example this time around as I could show how you could break down a long string and the data you need from it.

Using Integers for Tricky Titleblocks

July 7, 2015Ryan LenihanRevit Families, Revit General, Revit MEP, Revit Standardsautomation, families, family, mep, revit, revit families, revit mep, shared parameters

Have you ever come across a project with a keyplan in the titleblock and wondered how to go about managing the keyplan shading? The last thing you want to be doing is clicking every single check box across hundreds of drawings.

In this jumbled mess there are a total of 14 shaded areas on the keyplan. 3 for the basement, 3 for the roof and 8 for ground and first floor. So what is the most efficient way to manage it all?

The answer is integers.

An integer is simply a number that is not a fraction. It is a whole number. In the instance of our keyplan, integers can be used to control the shading for our titleblock by associating those values with an on/of visibility parameter.

In this example, I have used the following number sequences

Basement = 1 – 3 (you could use negatives here)
Ground & first floors = 21 – 28
Roof = 31 – 33

Each of the visibility parameters are then associated with the integer value by simply using the formula KEYPLAN_INT = x where x is the value associated with each level and zone. So for example, KEYPLAN_INT = 24 looks like this

But we don’t have to stop there. You would have notice we have two wings on the project that has resulted in the drawings being rotated at 10 degrees, this means on those 3 zones our north point will be different to the rest of the project. We can again use our integer parameter to solve this.

As these rotated views are only on ground and first floor, they are associated with the codes 25, 26 and 27, this means we can control our north point rotation with an and formula nested inside an if formula. The formula that I’ve used is if(and(KEYPLAN_INT > 24, KEYPLAN_INT < 28), 3.091°, 13.091°) so any drawings that have a keyplan integer of greater than 24 and less than 28 will have the north point rotated at 13.091 from north, the remaining drawings will have their north points rotated at 3.091 degrees.

But what about the drawings that we don’t want a northpoint, or a keyplan for that matter? Drawings like schematics, details and drawing lists. The shaded parts of the keyplan already only display if the correct code is used, so we can take advantage of this and simply create another visibility parameter that is associated with the building outline, the additional border line on the titleblock and the north point. In my example I’ve named this parameter NO_KEYPLAN with the formula of not(KEYPLAN_INT = 0). When the integer = 0, everything is switched off.

If you have people that don’t know how to read hydraulics drawings (I’m looking at you Sydney), you can also associate this parameter with Stratman and his sweet 70s style.

So on the left we have an integer value of 24 and on the right, the same titleblock with an integer value of 0.

You can then use your favourite bi-directional Excel option, be it Dynamo, BIMLink or some other alternative, export all the data to excel, set the integers for each sheet, re-import the data and you’re done.

Using C# Macros to Bulk Create New Family Types

June 23, 2015Ryan LenihanRevit APIs and API Developlment, Revit Families, Revit General, Revit Standardsautomation, BIMLink, families, family, revit, revit families, revit mep

If you have it, BIMLink is a great piece of software with many different uses, from project setup to managing the bi-directional flow of data, through to standards and overall process management.

One of the things I’ve used it for quite a bit is renaming family names and type names bringing family content into line with company naming conventions turning a mess like this

into something clean like this

If you’ve ever ventured down this path, you may have discovered a shortfall in the process due to BIMLink not being able include families in a ‘type link’ with families that don’t actually have a defined type like these ones highlighted below

This suddenly makes the standardisation process a whole lot more time consuming because if you have a lot of families without defined types, there is nothing BIMLink can do to help you. I even spoke with the Ideate team at the Australian Revit Technology Conference recently and they confirmed that this was the case and there wasn’t much they could do to help out as they are limited to what they can do by the Revit API.

I was determined to overcome the issue though, there had to be a way where I didn’t have to manually create a new type for every single family!

My first thought was to export all the families and then use journal files to batch process them, in concept it worked; each file in my list would have a new family type created but unfortunately it would fail after it created the new family type on the families without an existing type – the exact families I was trying to work with. I could continue to process the next file by restarting the batch but mindlessly restarting batch files until all the files were modified wasn’t the solution I was looking for.

In the end the solution was C#. BIMLink might be limited by the API because it is dealing with families within the open model, but I wasn’t limited to that as I’d already exported the family files to my local machine.

I came up with was a somewhat simple C# macro that processes a group of families in a predetermined folder, from there it creates a new family type for each simply named New_Family.

I had initially wanted to create family types named Standard but realised I’d likely run into issues with my macro due to it’s simplicity if I came across a family that already included the Standard type name.

public void ProcessNewTypes()
{
    Autodesk.Revit.ApplicationServices.Application application = this.Application;
    string directory = @"C:\INSERT\FILE\LOCATION";
    string s = "";

    // loop through all files in the directory
    foreach (string filename in Directory.GetFiles(directory))
    {
        s += "Family Name,Family Type,";
        Document doc = application.OpenDocumentFile(filename);

    // skip any files that are not family *.rfa files
        if (!doc.IsFamilyDocument)
            return; 

    // create the new family types
        using (Transaction t = new Transaction(doc, "Create New Family Type"))
            {
            t.Start();

        FamilyManager familyManager = doc.FamilyManager;

    // this is the new family type name
        {
            familyManager.NewType("New_Family");
        }

    // commit the changes and save the family *.rfa file
        t.Commit();
        doc.Save();

            }

      }
}

And it was that simple. For me, the macro processed around 350 families in a few seconds.

Once complete, you can reload the families into your template or project file and then process the files through BIMLink as per usual to rename the family and type names.

For any families that already had a determined type and have now ended up with two types, you can simply purge out the New_Family types from the model.

Navisworks Quick Tips

May 26, 2015Ryan LenihanNavisworks, Revit Generalclash, clash detection, coordination, families, mep, navisworks, revit, selection sets, shared parameters

I’ve been focusing a lot on documenting Navisworks procedures at work of late, for whatever reason Navisworks seems to be seen as some black magic witchcraft software package that no one wants to admit that they don’t entirely understand how to drive.

I sat in on a Navisworks session at the Revit Technology Conference last week just to see what others were up to and there was a surprisingly large turn out. The content presented was very much in line with my previous Navisworks articles and quite a few attendees seemed to be new to how Navis..works.

So based on that, I have two quick tips for Navisworks users, the first is selecting elements with a mouse click. When selecting elements in Navisworks, you might be selecting faces of elements or even the entire file rather than the whole element.

You can change what you select when clicking by heading to the Home tab on the ribbon and then heading to the Select & Search panel. Click on Select & Search and you will now see a drop down box.

You can then choose what you want to select with your mouse clicks. If you want to select individual elements, you will want to choose First Object.

The second tip is about the data that you export to Navisworks from Revit. You may remember in my Navisworks 101 series that I spoke about improving your clash detection with selection sets. To create really powerful selection sets, you need the data to drive them but you need to make sure that you’re exporting that data in the first place.

To correctly export Revit parameters to Navisworks you need to make sure you have the option Convert element properties checked – by default this setting is turned off.

You can find this option in two places. The first is Navisworks itself. Head to the application menu and select options.

In the options dialogue box, in the left hand sidebar find File Reader and then select Revit from the list, then from the options in the right hand window, check Convert element properties.

You can also find this setting in the Navisworks exporter addin within Revit itself. Simply head to the Addins tab on the ribbon, then from the External Tools list choose Navisworks 201xNavisworks Settings and then check Convert element properties

The difference between the information you get in Navisworks when you change this setting is chalk and cheese.

With the setting unchecked

With the setting checked

As you can see, checking this setting will export additional parameters and properties related to the element including material information, associated level, shared parameters and much more.

Having this information available within Navisworks will allow for more accurate selection sets to allow for better clash detection results as well as time lining and quantities.

Clean 2D Pipe Fitting Symbols

November 25, 2014Ryan LenihanRevit Families, Revit MEPannotation, families, family, mep, pipe fitting, revit

One of the gripes that a lot of hydraulic engineers and modellers have with Revit is the representation of pipework bends in 2D views. It’s something that I fixed up pretty early on, but I’ve come to realise when I come across drawings that look similar to the screenshot below that some may still not know how to fix this.

I’d a quick fix per fitting, the problem will be if you have a lot of fittings to modify, it becomes a long repetitive process.

The first thing that you want to do is to edit the family, and switch to the Ref. Level view, you will be greeted by something that looks like this:

In this instance I am modifying the out of the box Revit family Elbow – Soldered – CU.rfa. If you’re little overwhelmed by what you see on the screen, don’t worry; we’re not touching any of the dimensions or 3D elements. If you need to, you can adjust the scale of the view to change the size of the dimensions, or you can completely turn off the dimensions in Visibility/Graphics (VV / VG shorcuts).

What we are wanting to change is the 2D representation of the fitting, which are model likes of the pipe fitting subcategory. In the screenshot below, I’ve highlighted them in red with the dimensions turn off for clarity.

When modifying the pipe fittings, I like to keep the original linework in the family as a just in case. I usually change the linework to the <Invisible Lines> subcategory or turn the visibility off, you can however remove them if you wish.

To achieve the clean 2D representation that you’re used to, we’re going to create some new linework along with a reference line to control the angle.

First up, find the intersection of the Front/Back and Left/Right reference planes, from the intersection, draw a model line using the Pipe Fitting subcategory on a 45 degree angle (1) and then create an angular dimension between the Front/Back reference plane and your newly created reference line (2)

When you start drawing your line from the intersection of the two reference planes, Revit will automatically lock your line to the intersection point, this is also the point the the fitting is scaled around.

Next, apply the angle parameter to your dimension, the line will snap around to the same direction as the fitting.

You now need to align and lock the endpoint of your line to the reference plane for the outside edge of the fitting.

Now draw the other half of your fitting symbol. You don’t need to apply an angle in this case, just draw the line from the intersection of the Front/Back and Left/Right reference planes to the outer edge of the fitting. Don’t forget to align and lock the line to the outer reference plane.

Once you’re done, flex your fitting within the family editor, changing the diameter and angle. Make sure everything works as expected.

Now load your fitting back into your model or template and check out the difference

For the tee fitting, there is no need to recreate the symbology from scratch, all you really need to do is to remove the ticks by either making them invisible, or changing them to the <Invisible Lines> subcategory.