×

AutoCAD

A Parade of Precision Problems (Bug Watch AutoCAD Tutorial)

31 Dec, 2006 By: Steve Johnson

---

Are odd things happening in your 3D drawings? Is your LISP failing at math?

A Lack of Dialog Lives Again!
In previous months I've described the problem where various AutoCAD dialogs go AWOL. In November I said that Autodesk thought it had the problem fixed in 2007 SP1. As I've now had reports of this problem persisting in SP1, it appears that we haven't seen the backside of this little beastie yet.

Precision Problems
If you routinely work with objects a long way from 0,0,0 you will sometimes see CAD software (not just AutoCAD) do strange things. These abnormalities are caused by the software struggling to deal with accuracy at the limit of its range. A number used by a computer stored in the usual double-precision form can only hold a certain amount of precision and size. As the numbers get bigger, the precision decreases. You can have quality or quantity, or a compromise between the two, but you can't have lots of both at the same time.

Some of the problems that AutoCAD has had when dealing with large coordinates are:

• Hatch patterns go wild,
• AutoCAD fails to calculate a boundary when using the Pick Points option,
• Solid models fail to perform Boolean operations that should be possible,
• The Trim and Extend commands don't work properly and
• Offsets fail or produce odd results.

I won't go into great detail about this problem, as it has already been well covered by others in AutoCAD's Big Problem. Instead, I'll point out how AutoCAD 2007's new display engine has made matters worse, how you might want less precision and how your own LISP programs can suffer from precision bugs even when you are dealing with small numbers.

3D Space Oddities (2007 to 2007 SP1)
When dealing with objects a long way from 0,0,0 you may experience all sorts of funny things happening while using 3DOrbit. Although these look a lot like bugs, most of them are not actually AutoCAD's fault. The effects you see will vary depending on your graphics card and driver, but may include some or all of the following:

• A wild jerky movement in reaction to small mouse movements,
• Objects that should be circular display heavily stepped or even as a rectangle,
• Visual styles fail to correctly render all parts of the objects,
• Wireframe portions of the objects display mismatched from the rendered portions,
• Hidden wireframe portions of the objects incorrectly show through the rendered portions or vice-versa and
• Some rendered portions always display in front of other rendered portions, even though they should be behind.

The fundamental cause of these issues is AutoCAD 2007's shift to using the built-in hardware 3D facilities of the graphics card in hopes of increasing performance. Many graphics cards and drivers, even those on Autodesk's approved list, just don't do a very good job. You can look forward to them doing a better job in the future, as Autodesk works directly with graphics card companies for improvements. Unfortunately, some things are unlikely to ever work properly when using the graphics hardware to display objects a long way from the origin. This is because graphics cards generally perform their calculations using single precision numbers rather than AutoCAD's usual double precision. There just aren't enough digits in a single precision number to do the job correctly.

Workaround: Some of the above problems are fixable by moving the objects close to 0,0,0. I know that's not convenient, but it may be more convenient than dealing with the problems. Some are fixable by updating your graphics driver or buying a new graphics card. Some are fixable (albeit at the expense of performance) by turning off hardware acceleration in the 3DConfig command. Even if you do all this, some pain will persist if AutoCAD thinks its view target is a long way from the objects. You can check this out by inspecting the TARGET system variable. If it's full of wacky numbers, you can fix it using a sequence of commands that are sufficiently involved that you are better off setting up a menu macro such as this:

^C^C_.PERSPECTIVE 1 _.ZOOM _E _.PERSPECTIVE 0 _.VSCURRENT _2D _.VSCURRENT _C

Why You Want Chunky Circles (2007 to 2007 SP1)
Here's another 3D issue related to precision, but in an entirely different way. I have commented in the past that AutoCAD 2007's new 3D engine appears to use more memory than earlier releases for the same 3D model. Although this is true, I've discovered a trigger that causes it to use vastly more memory, to the point where moderately complex 3D drawings crash AutoCAD on a 4GB machine. I discovered in one case, with a drawing that works fine in AutoCAD 2006 and crashes AutoCAD 2007, that VIEWRES had been set to the maximum value of 20,000. This system variable determines how smoothly arcs and circles are displayed and is usually of most interest when working in 2D, so you would probably not suspect it of being the cause of your 3D woes.

Workaround: If you are having 3D performance or stability issues in AutoCAD 2007, check the setting of VIEWRES. If it's high, try a more reasonable number, such as 100. Your circles will look chunky if you zoom in, but that's a small price to pay. Sometimes, there really is such a thing as too much precision.

Computers Can't Add Up (v2.18 and later)
A client of mine recently asked for help with one of his LISP programs. Here is a simplified version of the problem:

(defun C:NUMTEST (/ counter)
  (setq counter 0.1)
  (repeat 10
    (print counter)
    (if (= counter 0.1) (princ "a"))
    (if (= counter 0.2) (princ "b"))
    (if (= counter 0.3) (princ "c"))
    (if (= counter 0.4) (princ "d"))
    (if (= counter 0.5) (princ "e"))
    (if (= counter 0.6) (princ "f"))
    (if (= counter 0.7) (princ "g"))
    (if (= counter 0.8) (princ "h"))
    (if (= counter 0.9) (princ "i"))
    (if (= counter 1.0) (princ "j"))
    (setq counter (+ counter 0.1))
  )
  (princ)
)

If you load that into AutoCAD and enter Numtest, you might expect to see this:

Command: NUMTEST
0.1 a
0.2 b
0.3 c
0.4 d
0.5 e
0.6 f
0.7 g
0.8 h
0.9 i
1.0 j

Instead, you see this:

Command: NUMTEST
0.1 a
0.2 b
0.3
0.4 d
0.5 e
0.6 f
0.7 g
0.8
0.9
1.0

That is, in 4 of the 10 cases, the computer fails a simple sum like 0.2 + 0.1 = 0.3. Why? Because of shortcomings in the binary math that computers use. You may be aware that the decimal system doesn't allow some numbers to be accurately represented. For example, 1/3 is 0.3333333 recurring. In binary, the same problem exists with other numbers, such as 1/10. When you start adding these numbers up, the inaccuracies build up and cause problems. For a more detailed explanation, see here.

This is not confined to LISP or even AutoCAD. Programmers like those at Autodesk have to look for this sort of thing all the time and allow for it where possible. How can you allow for it? Read on.

Workaround: In LISP, you can work around the problem by using the (equal) function to test for equality rather than the (=) function. The advantage of (equal) is that it allows the use of a fuzz factor:

  (if (equal counter 0.3 0.00000001) (princ "c"))

Watch out, though. The issue does not just apply to the (=) function, but also to other numeric comparison functions such as (>) and (<=).