On Land

The other day I had a puzzling problem with VR objects saved out of Archicad. Some files would open in QuickTime as conventional movie files rather than VR objects. (Press play and the building spins around once for each parallel. It runs about five seconds. It's not making any sales.)

As is often the case with puzzling intermittent problems, I was working too fast and not paying attention. After running a VR and viewing it in QuickTime, I would return to AC and run it again. Trouble is, sometimes I left the VR open. It took me an embarrassing while to figure out that those VRs were winding up corrupted on the second pass. In further testing, sometimes the VRs would be too corrupt even to open.

So the concrete tip is: Don't redo VR objects while they're open. Maybe this is 'duh', but there are filetypes that can be rewritten while open in other apps: Preview has no problem with me overwriting open image files, e.g. And it's common to let AC have most of the screen area, so who knows what else is open in the background.

The meta tip is: If a weird problem crops up when you're rushing, it's very likely a normal problem that either wouldn't happen or wouldn't seem weird if you weren't under deadline pressure. When you see something weird, slow down, pay attention, and fall back on the good workflows you practiced back when the wolves weren't at the door.

This has got to stop.

You know the one I mean. Three walls meet at a point, and the inline ones are different thicknesses. The corner formed with the inner wall simply must be expressed. We've had this one for-[stupid]-ever.

HCTPBWIW

Roundup of info on daily shutdown, backup, and power failures.

More»

Somewhere, a roof is unhappy. Most likely, the angles of nearby roof edges are causing the geometry to turn inside out. The report will say something like:

This is actually helpful! Use find and select to find a roof with that ID, and you can fix it. The trouble is that you probably have a lot of roofs with identical IDs, and you can't tell which of the n roofs is the problem.

If the IDs were unique, the report would lead directly to the bad guy. So you need to change the IDs of all the Roof 004 elements. You certainly can do this one at a time, and it will work.

Instead, use an Element Schedule to isolate the roofs, and correct the IDs.

Make a new schedule (Document -> Schedules and Lists -> Schedules -> Scheme Settings; Create New). The criteria:

For the fields, you just need 'ID', from the General heading:

This will give a schedule with all the roofs whose ID is not blank:

Make sure the 'Uniform Items' checkbox is off. If it's on, you'll get one line item for Roof 004, regardless of how many there are, defeating the purpose.

Now all you have to do is change all (but one) of the Roof 004 items to something unique. You can use numbers in the same pattern, as long as they aren't used elsewhere in the schedule, or you can add a, b, c, or something to the IDs.

Next time you run the 3D, section, or elevation window, you'll get the report again, but this time you can use the ID to find the specific element.

Heads up concerning the issue date in the title block. I'm getting very erratic results when publishing; sometimes the title block drawing (on the master layout) updates automatically, sometimes it doesn't. If that drawing doesn't update, your title block data will be wrong, including the date.

I have confirmed that the drawings on the master layouts are set to auto update. That should be all it takes, but it's not.

For example, I changed the date and then published a PDF. The dates on the resulting PDF sheets are not changed. I immediately published again, without making any changes anywhere in the project. Now the title block is right.

Erratic.

The title block drawing will always update if you open its master layout. It seems it will also update if you open a regular layout. But I have seen cases where the layouts of some masters are updated but not others; it probably depends on what regular layouts have been opened.

But, each layout automatically opens as the publication happens! Yes, and it skips updating the master drawings. Sometimes.

Once again, we have an output-related, liability-hazardous, supposedly-automatic behavior where Archicad can't quite get the door all the way shut. And once again we have to follow it around making sure it's using its litter box.

My recommendation: If you are publishing anything where the date is critical (that's anything you're giving to anyone else), before publishing, open each master layout that is in use. Essentially, that's all the masters of a given size, just to be safe. Opening the master should trigger the auto update of the title block drawing, and then you should be set.

We have had a handful of cases where ArchiCAD autosave recovery has failed when it should have succeeded. We have also had cases of human error where the autosave never had a chance.

Since ArchiCAD deletes the autosave data once it decides (right or wrong) that it's not needed, you don't get a second chance.

Unless you routinely back up the autosave folders.

More»

After I posted about the jellyfish a couple third-party observers commented, paraphrasing, 'Duh, of course you need to turn the hidden stuff off'. (Quick review: The issue there was clustered arrangements of elements, where AC was taking a long time to sort out the hidden lines.) Maybe so, but the last time we visited this issue, which was probably way, way back when, it didn't make much difference. But our projects today are more complex, with many more polygons, so we should look into it.

I tested the front elevation, with fills, of the hairiest project I could find. On the Quad G5, generating the SE from scratch took 2:45. This is with all the interior elements on.

I made a new layer combination and hid the interior elements. This includes:
• Structural columns, beams, footings. (Remember, we don't do joists or rafters.) (Also remember, architectural columns are layered as walls.)
• Interior walls (which shuts off the doors, natch)
• Interior trimwork
• Appliances, mechanical equipment, plumbing fixtures
• Stair parts
• Fireplace flues

Generation time: 2:15 (18% better) Noticeable, if not life-changing, improvement.

The question: Should the templates be equipped with such an LC?

• The improvement would only be noticeable on very complex models.

• A separate LC would mean a separate clone, making the view map more complex.

• SE generation will improve as we move to Intel hardware.

The dramatic slowdown in the jellyfish was caused by 'clumping' of elements in an unusual case. Such cases could be handled piecemeal, not burdening the template. Templates should be geared toward standards and typical usage.

I'm going to say the improvement isn't worth making the templates more complex. On a complex model, it might be worth forking the A2 LCs.

On a truly large, multistory building, I think it would be advisable. As you add lots of stories, it would seem you're adding interior polygons faster than exterior.

And I reserve the right to change my mind after another 8 years.

Smarter cleanup please.

Other dialogs here.

The source files of some Hotlinked Modules are missing

Sources of the following Drawings are unavailable!

If this item is part of a clone, its clone will also be deleted

Polygon boundary intersects itself!

More»

Kinda looks like a jellyfish

By themselves, it's not a lot of elements, or even a lot of polygons.

Yet these guys were found to be the cause of a severe and mysterious performance problem. An elevation containing the tower, which should generate in about 30 seconds, took four minutes to generate with these elements in the model.

The problem: AC has to figure out what's in front of what behind what in front of what, for all those overlapping elements. The calculations quickly become very complex and it takes time.

Here's the tricky part: The columns and objects weren't even visible in the elevation; they weren't going to be drawn at all. But apparently there's no way for AC to know that in advance, so you have to wait an extra 2-4 minutes for every section/elevation to generate.

It was hard to figure out, which took some time, but I'm afraid to wonder how much time was wasted over the weeks since those elements were put in.

BTW, it's not my project.

How I figured it out. I tried tearing out all the old objects, resolving the intermittent report errors, doing a forward merge, and opening the project as a dummy user, none of which worked.

There was a clue in the progress dialog as the elevations generated, but it took me a while to recognize it as such. The progress bar would hang up on 'Processing Objects' and 'Processing Columns'. The objects clue isn't much of a clue; of course there's a lot of objects. Hanging on columns is weirder, so weird that I figured it was a glitch; that was a mistake.

I still suspected mystical corruption, and it's my superstitious belief that corruption develops over time, so I tried deleting the whole first phase of the model, which is not in the current scope of work. (I used a heavy marquee for this.) That worked. I undid the delete.

Then I noticed the tower. I thought such a contraption probably has some funky geometry. I deleted the tower only, and that worked. Then I switched to the thin marquee and tried deleting one story at a time. This was disappointingly ineffective. Now I know that the reason is that the complexity was spread over several stories.

But when I trashed the top story, with all the beam objects, the 'Processing Objects' delay went away, leaving only the 'Columns' delay. I finally realize that the progress dialog wasn't totally off base. If losing objects helps, then we should look for some columns to lose. I did a select-all-columns within the marquee on each story, which finally coughed up the balusters.

Delete. End of slowness.

Tips:

• If you've ruled out file corruption, you need to look for 'heavy' conditions in the model itself.

• If you just did some weird complex modeling and suddenly it slows down, that's a big hint.

• You can tear the model in half and throw it away. Undo is your friend. Saving as is your friend. Start trashing stuff and see if the problem goes away. You can do a similar test by turning off half the layers, then the other half, etc.

• Watch the progress dialog. If it spends a long time on 'Objects' or 'Columns' or whatever, or the time estimate shoots up at a certain stage, that's a clue.

I thought we were supposed to model everything.

This is a good time to review this. We don't 'model everything'. We model what it is efficient to model, which, for a skilled ACer, is a lot of stuff. You model the major pieces of the project. You model stuff that shows up in a lot of views. You model enough to really understand the building. You model enough that annotations can be added easily.

You have to work within your own abilities and within the power of AC on your machine.

I hope it's obvious that you don't model things that cause AC to bog down and start wasting your time. We don't model joists, individual rafters, or other generic framing. Too much work for us, and, it turns out, for AC.

In the tower, some of the framing was intended to be exposed, but most of it was 'architecturally' insignificant and should have been skipped. The balusters are definitely nice to model, but there are situations where you need to compromise to keep the model running smoothly.

Maybe the tower section should be a drawing, or maybe a drawing elevation of the balusters should be pasted into the model SE window. Maybe the balusters should be on a layer that only shows in 3D views and not in section/elevation. That kind of lateral thinking.

Which is short for DisableCrossPlatformMountingFeatures.

Where to start. Let's just say, do this fix. It's a preferences modification which turns off a feature which, though of questionable value, causes a lot of problems. In other words, I don't know what it's supposed to fix, but it sure breaks a lot of stuff. The feature breaks stuff, that is. Not the fix, the fix is good. The fix that turns the feature off. Where to start.

These are the big issues that the fix fixes:

• In AC9, the infamous 'Connection Failed bla bla bla' warning, which pops up frequently while updating drawings in PM.

• In AC10, a long hang (rainbow ball) at startup, and various mysterious hangs here and there. (In an early beta of 10, this issue manifested itself as a two-minute hang every time I switched away from AC and then back. Awful.)

The issue has been implicated in many other intermittent problems. And the 'feature' which the fix turns off is of dubious value. In an office with no PCs, it's completely worthless. It should be off by default, but it's not, so we're going to turn it off.

How to:

• Close Archicad. Open Terminal. It's in Applications / Utilities.

• In Terminal, copy and paste the following:

defaults write com.graphisoft.AC\ 10.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

...and hit Return. It will appear that nothing has happened. This is a good thing. (If you get any message that something didn't work or doesn't exist, try it again, or try typing it manually. The thing to note about the typing is that there is a space after each backslash (\).)

• Close Terminal and relaunch AC.

That's the Terminal command for AC10. You can fix AC9 the same way, changing 10.0.0 to 9.0.0:

defaults write com.graphisoft.AC\ 9.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

And PM9 too:

defaults write com.graphisoft.PM\ 9.0.0\ USA\ v1 InputOutput -dict "DisableCrossPlatformMountingFeatures" "<true/>"

And you'll probably need it in 11...

Rest assured that this fix has no effect on project files; they are still cross-platform. The feature has to do with AC automatically mounting Windows servers in a cross-platform network.