On Land

We have several objects offer the user a group of roof slope selection parameters. You can select an n/12 slope from the list, or you can enter a custom slope angle. When you select a slope, the angle changes. When you put in an angle, the slope parameter will show n/12 if there is a match, and 'Custom' if not.

I use GLOB_MODPAR_NAME statements to keep such parameters in sync. In the code there are a bunch of IF/THEN statements associating the angles and the named slopes.

Since this lookup is used by several objects, I keep it in a macro and use RETURNED_PARAMETERS to get the data back to the calling object.

More»

Our title block is an object with hard-coded dimensions for each sheet size on our printers. The template has a worksheet for each sheet size, and within each worksheet is placed a title block object set to that size. Then there's a saved view of each worksheet, and the view is placed in each master of a given size.

One object -> A few worksheet views -> Several masters -> Many layouts.

Graphical changes to a given sheet type are made in the master. Changes to all the sheets are made in the worksheet. Changes to every sheet in the office are made in the code of the object. (Rare.) To change every future sheet in the office while leaving extant work alone, you need a new object and you need to update the template(s).

The text information in the title block object is a mixture of autotext tags in <angle brackets> and hard-coded text in quotation marks. The TEXT2 shape commands can use hard-coded text or string variables. Both of these will display the text 'Bar':

!! Display the text in the string variable named foo
foo='Bar'
TEXT2 0, 0, foo

!! Display the literal text 'Bar'
TEXT2 0, 0, 'Bar'

(In this usage, double and single quotation marks (and grave accent marks, on the ~ key) are interchangeable as long as the pairs match.)

Within each script of the object, you need to do a Find (Cmd+F) for all the text bits that need to be changed. If the company name has changed from Foo Architects to Bar Architects, you need to find each instance of 'Foo' and replace it with 'Bar'. Optional: Use the Replace button to find and replace in one go. I usually don't use Replace All unless it's a very straightforward case with a lot of instances. Also note the checkboxes.)

In the title block object, only the master script and 2D script need to be changed. But while I was in the neighborhood I added some years to the relevant values lists in the parameter script. (Values lists offer the user choices for a given parameter.) I did a Replace All of

'2010', 

with

'2010', '2011', '2012', 

taking care to remember that last comma.

Save as, not Save. Actually, you should save as before you make changes so you don't forget.

More: Structure of Objects, and the Object Editing Environment

Converting 2D elements for use in 3D.

Any 3D element(s) can be saved as an object with the Save Project As... menu command. (In Archicad 11, Save 3D Model As...) This technique is known as 'slabifying' since such models are often built from slabs. Objects saved in this way are dumb (not parametric), but it's still a useful trick.

2D elements can't be saved this way, because they never appear in the 3D window, where 3D object saving takes place. Despite the fact that GDL contains commands for 'flat' shapes in 3D, including LIN_ (a line) and PLANE (not a joinery implement). But there is a workaround for 'slabifying lines'. When you open a 2D DWG as an object, 2D lines are created as LIN_ statements in the 3D script. When you place the object in the model, you get the 2D geometry in 3D.

It's that simple at it's simplest, but real world applications need some tweaking. In this example, I'm converting an Archicad library 2D tree elevation symbol so I can use it in a sketch render image. Other applications might be a complex ornament in a hidden line elevation, or a busy glazing design placed in front of a conventional window.

More»

AC11 has a model view option to put the floor plan into reflected ceiling mode. It only works for objects, not regular elements (wish wish wish). I have several objects that take advantage of it.

This is the basic code you need to have a symbol draw itself differently in floor plan and RCP mode. The idea is that depending on the state of the switch, you set certain attributes, draw some things and not others, etc. Often, the shapes are the same, but the line switches from dashed to solid; stuff like that.

!! Parameters
!! plnPen : Plan Pen (0=Match)
!! plnLT : Plan Linetype (0=Match)
!! rcpPen : RCP Pen (0=Match)
!! rcpLT : RCP Linetype (0=Match)

!! If attributes are 0, set them to object settings
IF rcpPen=0 THEN rcpPen=L_
IF rcpLT=0 THEN rcpLT=SYMB_LINETYPE
IF plnPen=0 THEN plnPen=L_
IF plnLT=0 THEN plnLT=SYMB_LINETYPE

!! Request state of ceiling switch
rr=REQUEST("floor_plan_option","", storyViewpointType)
!storyViewpointType=1 !! testing

IF storyViewpointType=1 THEN !! ceiling
	!!Set ceiling attributes
	PEN rcpPen
	LINE_TYPE rcpLT
	!! Draw ceiling-only parts
ELSE !! floor plan
	!!Set floor plan attributes
	PEN plnPen
	LINE_TYPE plnLT
	!! Draw floor-plan-only parts
ENDIF

!! Draw parts common to both plans, using whichever attributes
LINE2 ...
RECT2 ...
POLY2 ...

Somebody asked why the flue object can't show a thickness for the flue liner itself.

The other reason: The flue is designed with SEOs in mind. You have to use it as a subtraction operator, or there's no point. It is a simple solid tube (EXTRUDE, actually) which we use to make a simple void. If the flue wall has a thickness, it becomes a solid ring with nothing in the middle.

Well, I could wireframe the layer in building section combinations and make it solid in wall section, and I could make the thickness option scale sensitive in the flue and the smoke chamber, but we're into serious inelegance now. It's a void, except when it's not and it's simulating a void, and it's scale- and layer combination-dependent, and do I 'really' subtract it to 'simulate' a void, I can't remember.

Once again we have met a limit in GDL object technology where the simplest solution is for Graphisoft to give us more power. There is a directive, MODEL, which allows you to build shapes in wireframe or surfaces-only mode in addition to the default, normal, solid mode. MODEL WIRE makes a wireframe shape that looks exactly like switching a layer to wireframe. MODEL SURFACE makes a shape that looks normal from the outside but is hollow. This sounds promising for our problem until we realize that only MODEL SOLID shapes can act as SEO operators.

Therefore, I want a new MODEL option which will make shapes wireframe, but which will allow the shapes to act as operators. So the flue wall would subtract, and the void within the flue would subtract, but the void would still be a void. My first stab at a name is MODEL OPERATOR, but I'm open to suggestions.

An object like the Foundation Drain is trying to offer total geometry and annotation for a particular detail. We want to pack this object with all the data we can think of. The geometry is in good shape, but we're missing the notes calling out all the parts. These will need to be added manually with labels or texts. Since these notes are standardized, they will be written down somewhere; if nowhere else, in the last place you drew the detail. Or in a module, or in a text file. Either way, it's remembering and typing or copy and paste.

How could the notes live in the object? You could script a series of 'labels', with leaders pointing to the detail parts, and editing hotspots to position the texts. I'm skeptical of this. It's sophisticated coding to get an interaction that, to the user, would never be as smooth as moving text elements and drawing arcs and labels. To me, placing the notes isn't the problem, it's remembering/locating the data to write into them.

Here's another idea that would let us keep the notes in the object. Create a switch in the settings to put the whole thing in 'note mode'. Instead of drawing the lines and fills, the object creates a series of text blocks. (These can be multi-line and arbitrarily styled, like text elements, using the TEXTBLOCK and RICHTEXT2 commands.) Then you could copy/explode the object, which would give you text elements you could stretch and arrange as needed.

Unfortunately it doesn't work. When a multi-line text object is exploded, you get multiple single-line text elements. Not helpful.

We need RICHTEXT2 that explodes into a single text element regardless of shape.

Something to think about, or maybe not. Not all objects have to be right in every way.

Plan symbol
Plan symbol on remote stories
3D hidden line
3D shaded
3D render
Elevation
Elevation in distant area
Section
Polygon efficiency
Scale sensitivity; which compounds the plan symbol, section, and polygon issues
Listing
Labeling
User interface
Parameter list
Parameter transfer management (Unique parameters)
2D graphical editing
3D graphical editing
Selectability
Code maintainability
Intra-library consistency

A frequently used, complicated, widely viewable object, such as a window, needs to be right in virtually every way.

The development environment gives very poor support for many of these requirements. As ArchiCAD adds features, items are added to this list. Irritatingly, the environment has not kept up, and is way overdue for a tear-down. There is no section window, no remote stories, no graphical editing. The full features of the current GDL architecture are not supported, so we can't even imagine modern development features such as syntax coloring and auto-completion.

One of those things that bothers some people more than others.

This is somewhat redundant with the GDL Syntax section (pg. 23) of the reference guide. I'm trying to make it a little clearer.

More»

An object consists mainly of parameters and scripts.

More»

• The GDL Reference Guide. They don't give us a printed version anymore. That's OK, the PDF is better. This guide is a really bad tutorial, because it's not a tutorial. It's more like a dictionary. Once you have the basic ideas, it's very clear, and indispensable.

• The GDL Cookbook 3, by David Nicholson-Cole. PDF. Out of print, out of date, but still useful. How to do lots of things. What most of the commands do. A bunch of tips. Handy references for binary arithmetic and circle geometry. Inspirational objects by people smarter than us, such as fountains, waving flags, ferris wheels. David is the primary evangelist for GDL and ArchiCAD culture in general, one of the pillars of the community, and also the author of...

• Object Making with ArchiCAD: GDL for Beginners, published by Graphisoft. PDF, or buy it at the link. It covers object making without GDL, and then GDL for beginners.

• The Libraries / Library Parts / GDL forum of ArchiCAD Talk. Like any question you might consider asking on ACTalk, ask me first, it's faster.

• GDL Talk on Yahoo Groups. Same advice as above, with the added caveat that issues in this forum tend to be of a higher level.

• The File -> GDL Objects -> Open Object command. GDL scripts are de facto open, and it's a good way to see applied examples. A word of advice: It's also a good way to see bad scripting, especially in the ArchiCAD library itself. Anyway, no one can stop you from reading a script and trying to figure it out.

• Your humble narrator. On a scale of 1 to 10, I'm a seven. I don't know everything, but I know of everything. I've done tons of it, over the course of five years. I've done a couple of things first, maybe. I can't teach you all I know due to time constraints, but I can give guidance on basic to intermediate questions.

All the PDFs mentioned here are available at 3 Resources : Documentation. Remember, PDFs in your local ArchiCAD 9 : Documentation folder will show up in the help menu within ArchiCAD. So handy.

I strongly, strongly, strongly recommend opening all PDFs in Preview, the reader by Apple that comes with OS X, rather than Acrobat Reader by Adobe. It's faster, simpler, launches quicker, and has better searching. No comparison.

You're mostly on your own. I can help with questions, but the way you learn is struggle. Once you get the basic ideas, the GDL manual actually makes sense. The code itself is not very hard; GDL is a lightweight in programming language terms. The hard part is design, and being perfect.

Yes, perfect, at least with regard to spelling and syntax. When you are working with code, errors really aren't tolerated very well. The machine has no idea you meant "PRISM_" when you typed "PRSM_". This is very different from high level software, where the developers of a program have written in the ability to cut the user some slack. For example, you can have MS Word switch that spelling error for you before you even see it. Another: A big part of ArchiCAD is detectability, which is a way of saying, once you're close enough, you're there.

Code doesn't work like this, and it can be frustrating, especially since some of the error messages you get are a little cryptic. It takes patience, which, it turns out, is more of a habit than a trait.

OK, end of parental advisory. What is GDL? It is the language of Objects, in all their types: doors, windows, lamps, labels, zone stamps, properties. It is a way of using words, logic and math to create drawing and model elements. In its simplest form, a GDL script says: "Go over there, make something, come back." (The coming back is technically optional, but do it anyway.) The complexity and power come in when the script can say: "Depending on what the user [that's you] does, or on conditions in the environment, make things a certain way, or in a certain quantity, or in a certain arrangement, and if the environment changes, adjust/change/rearrange the things as appropriate". And: "Remember that these things are usually particular building parts, so you should know something about them if anyone asks, which they will."

The ability of objects to change themselves on the fly in response to changes in the environment or decisions by the user is called "parametrics". You can have objects that aren't parametric, such as those saved from the plan or 3D window. Such objects are useful, but they're not flexible, so they tend to be one-offs. Parametric objects can act smart and follow rules, saving you a lot of time. This leads to an axiom:

It is impossible to professionally deploy ArchiCAD without customized, parametric, GDL objects. GDL is the way you get ArchiCAD to do exactly what you want.

From this, it follows that we make objects to solve problems, and we learn GDL so we can solve problems that ArchiCAD can't solve by itself. It also means we learn what we need to solve the problem we have, and leave the window library to someone else. This is because windows are hard, and a lot of people are way ahead of you. But you likely have some problem that no one has worked on yet, and chances are that even a little GDL can help.

GDL is arguably the single most powerful feature of ArchiCAD. That doesn't mean everyone has to do it, but it does mean that one person in each firm has to do it, or at least have access to the skills somewhere.

I would like to offer the opportunity to join an introduction to GDL, i.e., object scripting, for anyone who is interested. And, I would like to not offer it to anyone who is not. Interested.

I'm thinking of a map of the territory, a broad overview, with the goal of demystifying object making, so you can envision creating custom solutions yourself, with help. I'm not envisioning teaching you the whole thing, which no one has ever done for anyone.

I'm pulling together some preliminary reading here, under the category "GDL". If you are interested, browse this material, and then we can set up a meeting.

Let me know what you think.