Units accuracy

[Tom Krowka]

I'm having a discussion with my coworker about the accuracy of the units and the effect on the drawing. He likes to use three or four decimal places of accuracy; he feels that otherwise the drawing elements, walls, roofs, etc. don't really line up on top of each other, and this causes display problems with the model and elevations. Sometimes it seems that when the drawing is zoomed, you can't get points to line up right over each other. Or it's extremely difficult.

I think it has something to do with the pixels and where each point actually is.

I like to keep mine set to one decimal place or 1/8", but I don't seem to have as many problems. Or maybe I do but it's lousy drawing technique.

Anyway, which setting is commonly used, and does it make any difference?

As always, thanks

[Anonymous]

Hi Tom

I personally have my lenghth units set to 1 decimal place but my angles set to 3, I've noticed theres more room for error in rotation and don't seem to have many problems in plan lining objects up. The cartesian co-ordinates are also pretty handy, I use those guys to double check the really important stuff.
Thats just my preference, I assume you were after as many opinions as possible to try get a good of the most accurate system. I'm also curious about this.

[__archiben]

i always work to the maximum accuracy in both length and angle - 4 decimal places. dims are obviously defined in a different setting and the extra accuracy for working does help iron out ocassional errors.

as the 'lad' above said: there is usually more error in rotation and this is where i have had trouble in the past.

~/archiben

[Anonymous]

I agree with Ben. I prefer to have working units set at the highest accuracy of four decimal places (64ths of an inch on stateside projects).

This way I get clear feedback when things are a bit out of whack. There was also a time when mirrored elements would end up at 359.9996° instead of 0° (I think this has been fixed). Since I generally rationalize my designs to whole units (or large fractions) wherever possible, when I see 32nds or 64ths in the coordinates display then I know there is a problem.

Just in case anyone is not aware of this, it should be pointed out that the numbers in the coordinates palette are rounded from their actual values and do not constrain them to the numbers displayed. I have had clients (neophytes) who were using the rounded numbers in the coordinates as confirmation that they were drawing to the correct length rather than using numeric entry. Needless to say, the models were riddled with tiny inaccuracies.

[Tom Krowka]

Just in case anyone is not aware of this, it should be pointed out that the numbers in the coordinates palette are rounded from their actual values and do not constrain them to the numbers displayed. I have had clients (neophytes) who were using the rounded numbers in the coordinates as confirmation that they were drawing to the correct length rather than using numeric entry. Needless to say, the models were riddled with tiny inaccuracies

Let me see if I understand what's going on here. Are you saying that the coordinate information is not really accurate. That would mean that drawing to some distance shown in the coordinate palette is not really correct to the numbers shown, regardless of the accuracy setting.

Everything should be drawn using numeric entry? That means I have to find the distance for things that must be drawn. What happened to drawing from point to point? Shouldn't that be totally accurate? I think that is where our problem, and my question is. If I draw to a snap point, like a wall intersection, what difference does it make if I have one decimal place or four decimal places. It should still snap to that point, right?

Thanks.

[Anonymous]

Tom wrote:
Let me see if I understand what's going on here. Are you saying that the coordinate information is not really accurate. That would mean that drawing to some distance shown in the coordinate palette is not really correct to the numbers shown, regardless of the accuracy setting.

The coordinates display MAY be correct if the actual dimension can be expressed by the level of accuracy defined. If a wall is precisely 8'-0" long then it will display the correct value.

Everything should be drawn using numeric entry? That means I have to find the distance for things that must be drawn. What happened to drawing from point to point? Shouldn't that be totally accurate? I think that is where our problem, and my question is. If I draw to a snap point, like a wall intersection, what difference does it make if I have one decimal place or four decimal places. It should still snap to that point, right?

Snaps and constraints precisely accurate. I was referring to drawing a new element whose end point (or intermediate points) do not have a known point to snap to. In this case numeric entry is mandatory.

The example I was referring to was of someone drawing a new wall such that it LOOKED straight on the screen (no constraints) and the desired (rounded) value for the length appeared in the display. Naturally everything in the project was very slightly out of square and off of the intended dimensions.

Once elements are placed precisely using constraints and numeric entry they can then be relied upon to provide accurate references for snaps, dimensions, etc. This is why it is so important to make sure that things are laid out precisely to begin with.

[Tom Krowka]

We still have some snap problems. The pixel accuracy is set to one pixel. When it's zoomed in close, the actual points of the intersection of the lines or whatever it is do not stack up one on top of the other no matter what the settings are. This seems to be especially critical in roofs. Sometimes you just can't zoom in close enough to get two points to match. I think we must be doing something wrong here. Are we trying to be too accurate?

[Anonymous]

Tom wrote:
We still have some snap problems. The pixel accuracy is set to one pixel. When it's zoomed in close, the actual points of the intersection of the lines or whatever it is do not stack up one on top of the other no matter what the settings are. This seems to be especially critical in roofs. Sometimes you just can't zoom in close enough to get two points to match. I think we must be doing something wrong here. Are we trying to be too accurate?

As a rule elements should be stacked precisely on one another. Is there a reason that you need all these nodes and edges so close but not aligned?

It sounds like your lack of alignment (if unintentional) could be due to a lack of discipline in the use of snaps, locks, constraints and numeric entry.

[Anonymous]

I agree with Matthew and Ben, maximum accuracy should be the rule.
When i have to work on projects made by someone else,
it is often a nightmare, because of accuracy problems.
The point you think is at 10.00 is in fact at 10.0030 (i speak in meters),
the angle rotation of 30.00 degrees is in fact 30.0352, and so on.
Very difficult to correct everything, an incredible source of problems,
and a true vaste of time. It should be better to trash the project.
Precision is very important, and from my experience, i recommand
to always work with maximum accuracy. You will avoid a lot of errors

[Ralph Wessel]

Tom wrote:
We still have some snap problems. The pixel accuracy is set to one pixel. When it's zoomed in close, the actual points of the intersection of the lines or whatever it is do not stack up one on top of the other no matter what the settings are. This seems to be especially critical in roofs. Sometimes you just can't zoom in close enough to get two points to match. I think we must be doing something wrong here. Are we trying to be too accurate?

Matthew's advice regarding the use of snaps, guidelines, constraints, and numeric input is spot on. You should never draw 'by eye' on the computer unless you do not intend to measure anything from the drawing, i.e. you are producing a schematic illustration. Even then, it's often easier to use snaps.

Regarding accuracy and numeric input: ArchiCAD's numeric data representation is far more accurate than the 4 decimal places displayed on the screen. All such output is rounded for display purposes. You can enter numbers which have more than 4 decimal places, and the extra accuracy is actually used in many cases - you just won't be able to see evidence of it in the numeric output displayed by ArchiCAD.

You can strike this problem when scripting in GDL with statements like,
"IF (someNumber = 0) THEN ..."

If the value of someNumber is 0.00003, ArchiCAD will display the number as 0, but the above condition will evaluate to false because the number is not really 0.