Category Archives: Solid Element Operation

File Performance – Self Audits

Projects are routinely audited, or at least reviewed on the BIM Server to maintain a reasonable quality of model performance and accuracy. There are specific areas of the audit that are responsible for file performance. Some of these audit sections are worth paying attention to because they can affect file navigation, others can impact general teamwork performance. In any case, these areas of the audit are worth periodically reviewing, even between formal audits.

The areas that need to be self audited are:

  1. The Library Manager
  2. The Library Loading Report
  3. The “Error” Report
  4. The Drawing Manager
  5. Solid Element Operations
  6. Total Model Polygons
  7. Attributes

Library Manager

The Library Manager needs to be periodically reviewed for organization. A disorganized Embedded Library is difficult to maintain, manage, and review. More than the organization, the contents of the Embedded Library are a critical element to file performance. Because the E/L is part of the file, rather than linked to the file like a BIM Server Library, it directly impacts the overall file size; even if content is not placed in the model. Ideally, .gsm content embedded in the file should be less than 10 MB and images used for surfaces should be less than 1 MB. These should be the targeted max for embedded library content. The more frequently an object or image is going to be used in the model, the smaller the file size should be.

Library Loading Report

The library loading report will appear when first opening/joining a file if there are any library issues. These issues may include missing, duplicate, or substituted library content. It may seem like this is just something to close out of and ignore, but this palette is warning that your model may be suffering from poor performance and accuracy. For more on the Library Loading Report, see this WWABIM post here.

Error Report

The report tab will come up when there is processing error in any non-plan model Viewpoint. Like the library loading report, it may be tempting to ignore this tab, but this report is a warning that your model is suffering from invalid geometries, missing attributes, or other errors that can not be resolved. If there are too many errors in the model, the result can be beach balling, slow send/receive, and slow navigation between Views. To review how to clean up Error Report content, see this WWABIM post here.

Drawing Manager

The Drawing Manager often suffers from missing content. Although missing content here may not slow a file down noticeably, the drawing manager is a good place to review externally linked content such as .dwg & .pdf files that have been dropped onto layouts. The drawing manager is a good place to review the update status of content on layouts, which can speed up layout book navigation. This is also a good management tool for tracking external content’s paths to review linked content file size. Linked drawings with large file size can slow the model significantly, and even more so if large files are embedded in the drawing manager. Always review pdf/dwg file size before embedding in the drawing manager. For more information on the Drawing Manager see WWABIM posts here and here.

Solid Element Operations

Solid element operations have been reviewed in past WWABIM posts here, here, and especially here, as well as in a previous internal DD L&L. In running self audits, any element with more than 100 connections should be reviewed, with any unnecessary targets, operators, or other connections removed.

Total Model Polygons

The most important aspect of a model’s performance is often the number of visible polygons. But even if layer and view settings are carefully managed and reviewed, you may run into situations where the entire model needs to be viewed, or may be accidentally viewed. If there are too many polygons in the model, this may result in an slow file performance, beach balling, file or computer freeze up, or even a file crash. With our current hardware, we should be aiming for no more than 5,000,000 polygons for a standard file.

It may not always be a clear line, since the source of polygons as important a role in file performance as the total polygons. For example, in some basic tests and overall experience, 60,000 polygons from a single mesh can perform worse than 1,000,000 polygons from objects. Also, 3,000,000 polygons from a single library part (object tool) placed several times will perform significantly worse than 3,000,000 polygons from 50 different library parts. In general objects contribute to the most polygons, but GDL also handles polygons significantly better than other tools. Overly complex mesh elements and excessive use of morphs can be a bigger performance issue to a file than objects.

Attributes

Attributes can have a huge impact on file performance, as well as document and output file sizes. A large, complex, custom cut or drafting fill can result in an incredibly large pdf or dwg file; in some cases so much so that the files can not be emailed or, in many cases, even printed/plotted. Additionally, custom profiles can result in poor model performance if not properly applied to the model. Profiles applied to walls should be used sparingly, as the intersection between walls results in excessive polygons and slow model performance. Custom profiles are better applied to beams, instead of walls.

The last part of attributes that should be self audited is the naming and file size of the attributes. If surfaces are using large images, it can slow the file down (see Library Manager above). Beyond the image size, the image naming of surfaces is critical to BIMx output. See the WWABIM article here and here for more information on BIMx surface errors.

Advertisements

Roof Wall Connections

I feel like I have written this all somewhere before, but it begs repeating. Roof wall connections can be tricky, and solid element operations are not always the answer. In this example, we have an eave bearing wall running perpendicular to the roof slope.

The original model was built using SEO’s. This created a section error, showing the ceiling finish running through the wall structure:

screen-shot-2016-11-29-at-10-50-26-am

Also, notice the selected wall is taller than it should be, running above the roof plan. This wall height should be modeled to stop at the highest intersection of the bottom of the roof core. Then the roof and wall, while both selected, can be cleaned up with the Merge function (Design > Connect > Merge, or Right Click > Connect > Merge).

screen-shot-2016-11-29-at-10-55-42-am

The result is a properly cleaned up section view!

Smarter Modeling & Top Link Settings

In the wake of our office presentation on Solid Element Operations, I have been getting a lot of feed back, questions, comments and suggestions on use of SEO’s and methods of modeling without them.

I want to point out three scenarios that I came across this morning. One is SEO’s done correctly, the other are wrong. These deal specifically with walls, columns and beams and their relationship to the roof elements above.

Screen Shot 2016-04-28 at 9.39.51 AM.png

Wall perpendicular to roof slope trimmed to roofs with upward extrusion

Screen Shot 2016-04-28 at 9.40.13 AM.png

Wall parallel to roof slope, extended to ridge height and trimmed with upward extrusion

Screen Shot 2016-04-28 at 9.40.04 AM.png

Columns extended beyond roof plane and trimmed with upward extrusion

The basic idea here is that elements are all extended beyond the roof and then cleaned up by using SEO’s. This is wrong for several reasons:

  • First, this habit will cause more unnecessary SEO’s in the project. And we have already covered why that is problematic
  • Second, these elements can interact, intersect, create voids in elements above, such as dormer walls
  • Third, these walls do not clean up correctly with their roofs in section, wall section, details
  • Fourth, it runs a risk of saving out incorrect or inaccurate IFC or SKP files

The correct method for making these walls/columns/beams flexible to design adjustments is to set them to the correct height relative to the story above. Top link the wall, even if it is grossly below the story above, as in this case where the floor to roof height is 18′ in the story settings; so the top of wall is -9′ to story above.

Screen Shot 2016-04-28 at 11.12.55 AM.png

18′ floor to floor height for floor/roof stories

Screen Shot 2016-04-28 at 11.12.47 AM.png

Wall Top linked to Roof and set at -9′

Solid Element Operator Errors

Solid Element Operations and other trimming functions are helpful and even critical in generating the correct geometries and drawings in ARCHICAD. That being said, they should be avoided wherever possible! Overuse and misuse of SEO’s is one of the biggest contributing factors to a slow or glitchy file and can often be the cause of “beach balling”, freeze ups, and crashed files.

What Not to Do!

  • First, avoid dissociative trimming operations. That is, do not trim a wall, beam, column, to a roof, slab or wall that it is not actually associated with. The program beach balls when this is done excessively since it is looking for associations between elements that do not exist.
  • Second, do not repeat SEO’s. If elements do not trim to each other, do not simply “try again”. This will rack up the number of operators and targets and cause all kinds of file slow down. If elements do not trim to each other with an SEO, there may be a momentary glitch or something about the elements that are preventing them from trimming properly. I often see this error when walls are trimmed to roof in a group, then selected again and re-trimmed to another roof + the original roof (just for good measure).
  • Third, avoid creating a dedicated trimming element if a model element can be used in its place. For example, you do not need to carve out a site for the building if a basement slab is already in place. Redundant elements can cause elements to disappear in elevation/section/3d views.
  • Fourth, do not use an SEO if a simple geometry can create the same shape. I see this error most often for stair openings in slabs or clerestory openings in roofs. You do not need to trim these openings, you can simply generate them with a hole in the slab/roof (use the pet palette “-” button).

The File Failure Threshold Test

For this article I ran a quick test to assess the tolerance for the first (and most destructive) example of SEO misuse listed above. I took a simple collection of 4 walls, 1 roof, and 1 slab. I arrayed this collection into a 10×10 grid (14,800 polygons), 15×15 grid (30,600 polygons), and a 20×20 grid (54,400 polygons). None of these configurations should cause a slow and glitchy file based on complexity of model elements, since even the largest test is less than 2% of our average files polygon count.

Screen Shot 2016-03-22 at 1.49.17 PM

Test 1:

For each array size I then trimmed walls to their associated slab with downward with upward extrusion and their roof with upward extrusion, at a 1:1 ration. No wall was trimmed to a roof or slab it did not touch. The result was a smooth running and efficient file, even at the largest array of 400 roofs and slabs and 1600 walls. In the image below, notice the SEO fly out on the selected roof, only 4 associated targets to each roof/slab.

Screen Shot 2016-03-22 at 1.51.37 PM

Test 2:

Next I removed all operators and targets for each of the three tests. Then selected all walls and trimmed to all roofs with upward extrusion, and another SEO with all walls trimmed downward on all slabs. So the worst case is 1600 targets on 400 operators, performed twice.

Screen Shot 2016-03-22 at 2.01.57 PM

The results on the 10×10 array were acceptable, with minor, but noticeable performance and navigation slow down.

The 15×15 array had up to 10 second “beach ball” delays during basic navigation and editing, which is annoying but not inoperable.

The 20×20 array took over 15 minutes just to perform each solid element operation. After they were performed there were over 30 second delays to simply orbit or switch between plan and 3d views. The file crashed twice while performing basic navigation.

Final Thoughs

These tests were done in a file with no view map or layout book and no source markers of any type. This slow down will be noticeably pronounced in files with more total polygons, views in the view map that read these trimming/trimmed elements, and layouts with these views placed on them.

Again, I want to reemphasize, this test was done on a file with no complex content and only 54,400 polygons and only 2,400 total elements max. So be careful of how you use SEO’s! If your file is running slowly, this is the first place to look on regaining some speed and efficiency; even at the sacrifice of redoing most or all of the trimming elements, it could pay off in the file speed and efficiency of work. (Please speak with me before blowing out all your SEO’s though, it only makes sense if your file is inoperably bad or at an extremely early phase)

SEO & Element ID Warnings

Here is a cautionary tale for both Solid Element Operations and Element ID’s.

I was trying to determine why a roof was not showing up in section or 3d, but shows in plan view. This is normally because of a duplicated element and building material priorities canceling each other; but in this case it was due to redundant solid element operations.

When I removed all SEO’s it reappeared, but was not trimming any gable end walls. So I had to find the problematic operators or targets. There where 30 SEO’s on this roof, and in the SEO handle many of them showed as having the same ID. Using a combination of find & select & the ID manager, you can rename these elements for easy identification.

Typically elements should have unique ID’s, or at least groups of ID’s which accurately represent their function. In this project all slabs where started this way, but from a copy/paste workflow the ceiling slabs where called out as first floor slabs. Renaming them pointed to the problem.Screen Shot 2015-07-08 at 3.44.38 PM

In the image above you can see the elements set as the targets & operators of the selected roof. A ceiling slab is the target of this roof twice, roof deck twice, roof covering twice, wall 5 times (as both target & operator with multiple extrusion types…

So the warning is this; use SEO’s as sparingly as possible, avoid redundant and non-associative SEO’s. Meaning do not set a target or operator from one element that does not trim another. Do not use an element as a target multiple times to the same operator (there are a few exceptions to this). If an SEO does not appear trim properly undo before you try again. Where ever possible be aware of the automatically assigned element ID’s. These will often duplicate rather than adding a new ID, which is not always a bad thing. But elements with a specific function should have their own ID(s). Above I temporarily renamed ceiling slabs CLG Slab1, 2, 3… just to sort out what was going on with the SEO’s. This can be done before placing elements or immediately after via the Element ID Manager.

SEO GENERAL NOTES

Today a file had mysterious missing walls and floors after the site had been inserted and trimmed to the building. After looking into it, the operator for the site trim was a slab the height of the building.

Screen Shot 2014-11-13 at 4.19.03 PM

There are a few words of advice I will share with everyone regarding using solid element operators:

First, and most closely related to this issue is, that if you have a building element already in place (in this case the floor slab and basement walls) that can act as the operator, use it. It is not necessary to turn an operator off once the operation has been made, it can be part of the final building model and visible in all views.

Next, an operator that is not associated with a building element and is actually on the SEO layer should be as minimum as possible. As you may remember from the post on trimming door and window casings, we used a single plane morph object as the operator. The operator should be as simple as possible to perform its function.

The last note on using solid element operators is to use operators that relate only to their targets. As an example of this, we often see rafter tails trimmed by a profiled beam or wall. A rafter tail should never be associated as a target of an operator located on the other side of the building or along another wall line. In the image below Maggie has used a single operator for all rafters along each wall face, rather than selecting all rafter tails and all SEO beams and performing a single blanket operation.

Screen Shot 2014-11-13 at 4.39.43 PM

MITERED TRIM

If you have a complex profile applied to a beam and column to represent your trim, you may find it tricky to get them mitered properly. Notice the overlapping “square” boxes at the intersection in the image below.

Screen Shot 2014-10-16 at 8.23.23 AM

A solution was recently developed by Boyce which quickly resolves the lack of interaction between beams and columns. Insert a morph object as a single plane at a 45º angle through the intersection point. Using this plane as an operator with upward extrusion on the column, and with downward extrusion on the beam you will have a cleanly mitered trim in elevation, section and model views.

Screen Shot 2014-10-16 at 8.26.08 AM

Note the miter line shown in the image below due to different surfaces being applied to the beam and column. This is a bonus tip if you want to express the miter in your documents and model.

Screen Shot 2014-10-16 at 8.27.03 AM

In most cases we will want to see the miter “disappear”. If you apply identical building materials and surfaces to both beam and column the intersections clean up. You will see a line where two curves intersect, but this is due to the handling of curves vs planes. For most instances this profile could be altered to use a plane rather than curve to represent the coved portion of the trim; this wold give a clean intersection across the full miter.Screen Shot 2014-10-16 at 8.27.45 AM